Verständnisfrage Loopbackdevice [gelöst]

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
Benutzeravatar
Felix
Beiträge: 453
Registriert: 17.02.2003 10:26:57
Lizenz eigener Beiträge: MIT Lizenz

Verständnisfrage Loopbackdevice [gelöst]

Beitrag von Felix » 13.01.2019 21:16:02

Moin,

ich habe auf meinem Laptop Debian stable in der aktuellen Version laufen. Mein Notebook ist manchmal über WLAN, manchmal über Ethernet und manchmal gar nicht mit dem Internet verbunden. Weiterhin habe in einer VirtualBox ein Windows 7 Guest laufen. Dieser Guest darf keinfalls mit dem Internet verbunden sein (ich habe keine Lust mich mit Virenscannern etc. zu beschäftigen). Auf meinem Host System läuft ein Server, welcher egal wie und ob ich mit dem Internet verbunden bin, jederzeit sowohl vom Linux Host-System als auch vom Windows Guest-System aus identisch erreichbar sein soll. Daher habe ich in VirtualBox ein Host-Only Netzwerk eingerichtet, welches auch soweit funktioniert. Der Host bekommt dazu beim Start der VM ein virtuelles Netzwerk-Interface mit der IP 192.168.56.1 hinzugefügt. VirtualBox vergibt per DHCP dem Guest dann die IP 192.168.56.3. Zwischen diesem internen Netzwerk und dem Internet wird nicht geroutet - alles bestens. Solange meine VM läuft kann ich nun meinen Server über die 192.168.56.1 von beiden Systemen aus erreichen. Das ist schon fast das was ich haben will. Läuft die VM nicht, existiert natürlich auch das virtuelle Netzwerk-Interface mit der IP 192.168.56.1 nicht und ich kann meinen Server so nicht erreichen.

Nun komme ich zu meiner eigentlichen Frage: Ich habe mir zur Lösung dieses Problems gedacht, einfach ein Loopbackdevice im internen Subnet zu installieren. Ich habe dazu der /etc/network/interfaces folgende Zeilen hinzugefügt:

Code: Alles auswählen

iface lo:1 inet static
  address 192.168.56.42
  network 192.168.56.0
  netmask 255.255.255.0
Ich dachte nun eigentlich über die 192.168.56.42 von beiden Systemen aus meinen Server auf dem Host erreichen zu können. Für den Host trifft dies auch zu. Ich kann meinen Server egal ob die VM läuft oder nicht immer auf dieser IP erreichen. Sobald dieses Loopbackdevice jedoch aktiv ist, bekommt mein Windows Guest aber permant IP-Konflikte. Die Netzwerkverbindung funktioniert nicht mehr, manchmal kommt die Warnung, dass die IP dieses Computers im Netzwerk bereits vergeben ist und eine IP bekommt Windows per DHCP scheinbar auch nicht mehr zugewiesen.

Habe ich da irgend etwas mit dem Loopbackdevice falsch verstanden? Oder habe ich die Konfiguration des Loopbackdevices falsch vorgenommen? Erkennt jemand wo mein Denkfehler liegt? Hat jemand einen eleganteren Vorschlag mein Anliegen umzusetzen?

Gruß, Felix
Zuletzt geändert von Felix am 15.01.2019 19:33:21, insgesamt 1-mal geändert.

mat6937
Beiträge: 2927
Registriert: 09.12.2014 10:44:00

Re: Verständnisfrage Loopbackdevice

Beitrag von mat6937 » 14.01.2019 09:46:49

Felix hat geschrieben: ↑ zum Beitrag ↑
13.01.2019 21:16:02
Habe ich da irgend etwas mit dem Loopbackdevice falsch verstanden?
Ich denke, ja. Die Loopback-Schnittstelle ist da, damit das Gerät bzw. das System mit sich selber kommuniziert.
D. h., Client und Server sind auf demselben Rechner.

Benutzeravatar
Felix
Beiträge: 453
Registriert: 17.02.2003 10:26:57
Lizenz eigener Beiträge: MIT Lizenz

Re: Verständnisfrage Loopbackdevice

Beitrag von Felix » 14.01.2019 10:54:39

Ist ja im Grunde auch so bei mir.

Benutzeravatar
Felix
Beiträge: 453
Registriert: 17.02.2003 10:26:57
Lizenz eigener Beiträge: MIT Lizenz

Re: Verständnisfrage Loopbackdevice

Beitrag von Felix » 14.01.2019 14:42:30

Moin,

wenn ich statt des Loopbackdevices folgendes mache:

Code: Alles auswählen

ifconfig dummy0 192.168.56.42/24
FUnktioniert alles so wie ich mir das vorgestellt habe. Aber was ist denn nun der Unterschied zum Loopbackdevice?

Leider bekomme ich diese Lösung auch nicht persistent hin. Wenn ich in /etc/network/interfaces folgendes eintrage:

Code: Alles auswählen

auto dummy0
iface dummy0 inet static
  address 192.168.56.4
  netmask 255.255.255.0
und dann ifup dummy0 teste, bekomme ich folgende Fehlermeldung:

Code: Alles auswählen

root@grobi:/home/felix# ifup dummy0
RTNETLINK answers: File exists
ifup: failed to bring up dummy0
Was mache ich da nun falsch?

Gruß, Felix

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: Verständnisfrage Loopbackdevice

Beitrag von ReturnToSender » 14.01.2019 15:17:59

Felix hat geschrieben: ↑ zum Beitrag ↑
13.01.2019 21:16:02
Oder habe ich die Konfiguration des Loopbackdevices falsch vorgenommen?
Das kann ich Dir leider nicht beantworten, weil ich trotz 3 maligen Lesen die Problembeschreibung und die Zielsetzung nicht verstanden habe. Nur soviel zum Loopback-Device: Das ist ein virtuelles Netzwerk-Device für eine IP-Adresse aus dem reservierten Bereich von 127.0.0.1 bis 127.255.255.254. Im Regelfall hat das LO-Device die Static-IP 127.0.0.1. Gebraucht wird dieses Device zur Kommunikation lokal (!) laufender Dienste/Programme untereinader, ohne auf ein physisch vorhandenes Netzwerk-Gerät zugreifen zu müssen. Also z.B. wenn der lokale Browser auf der gleichen Maschine lokal eine Webseite mit der Adresse 127.0.0.1 öffnet... wie z.B. das Cups-Web-Interface mit http ://localhost:631/

Ich weiss nicht, ob VirtualBox einen Modus zur Verfügung stellt, mit der aus der VM das Loopdevice des physischen Hosts angesprochen werden kann. Aber eigentlich ist das ja unsinning, weil ja dann das Loopdevice der VM nicht mehr erreichbar wäre. Ich weiss auch nicht, ob man Pakete von anderen Systemen (die VM) auf das lokale Loopdevice umbiegen kann. Möglich ist das vielleicht mit dem Paketfilter, aber ob man sowas machen sollte... ich glaube eher nicht. :roll: Aber wenn man das Problem nicht verstanden hat, wird das auch nix gescheites mit Lösungsvorschlägen... sorry....

dufty2
Beiträge: 1709
Registriert: 22.12.2013 16:41:16

Re: Verständnisfrage Loopbackdevice

Beitrag von dufty2 » 14.01.2019 18:02:36

Mittels

Code: Alles auswählen

auto dummy0
iface dummy0 inet manual
	pre-up /sbin/ip link add dummy0 type dummy
	up /sbin/ip address add 192.168.56.4/24 dev dummy0
	post-down /sbin/ip link delete dummy0
sollte
ifup dummy0
bzw.
ifdown dummy0
funktionieren.

Benutzeravatar
Felix
Beiträge: 453
Registriert: 17.02.2003 10:26:57
Lizenz eigener Beiträge: MIT Lizenz

Re: Verständnisfrage Loopbackdevice

Beitrag von Felix » 14.01.2019 20:22:08

Moin,

vielen Dank für eure Antworten!
dufty2 hat geschrieben: ↑ zum Beitrag ↑
14.01.2019 18:02:36
Mittels

Code: Alles auswählen

auto dummy0
iface dummy0 inet manual
	pre-up /sbin/ip link add dummy0 type dummy
	up /sbin/ip address add 192.168.56.4/24 dev dummy0
	post-down /sbin/ip link delete dummy0
sollte
ifup dummy0
bzw.
ifdown dummy0
funktionieren.
Leider funktioniert es nicht. Ich bekomme exakt die gleiche Ausgabe wie schon bei meinem vorherigen Post.
ReturnToSender hat geschrieben: ↑ zum Beitrag ↑
14.01.2019 15:17:59
Felix hat geschrieben: ↑ zum Beitrag ↑
13.01.2019 21:16:02
Oder habe ich die Konfiguration des Loopbackdevices falsch vorgenommen?
Das kann ich Dir leider nicht beantworten, weil ich trotz 3 maligen Lesen die Problembeschreibung und die Zielsetzung nicht verstanden habe. ...
Ohje und ich dachte, ich hätte es ganz treffend beschrieben. Na ich versuchs nochmal: Auf meinem Laptop läuft Debian stable (im Folgenden Host bezeichnet) und in einer virtuellen Maschine Windows 7 (im Folgenden Guest bezeichnet). Der Guest hat eine virtuelle Netzwerkverbindung zum Host, welche es ihm nicht ermöglichen darf auf andere Netze zuzugreifen. Dazu bietet VirtualBox ein sogenanntes Host-Only Netzwerk an. Das besteht aus einem Virtuellen Netzwerkadapter für den Host (192.168.56.1), einem virtuellen DHCP-Server für den Guest (192.168.56.2) und eben dem virtuellen Netzwerkadapter für den Guest, welcher vom DHCP-Server seine IP bezeiht (192.168.56.3).

Auf meinem Host läuft nun eine Serveranwendung, welche vom Host und vom Guest auf exakt der gleichen URL erreichbar sein soll. Ich benötige also eine IP auf dem Host, die sowohl vom Host als auch vom Guest aus erreichbar ist (z.B. 192.168.56.4) und Nachrichten an die Serveranwendung auf dem Host weiterreicht. Ich dachte mir nun, dass diesen Zweck ein Loopbackdevice erfüllen könnte. Ich habe das Loopbackdevice so verstanden, dass es ein virtueller Netzwerkadapter ist, der nur auf dem lokalen System sichtbar ist und sämtliche Anfragen (die ja nur vom lokalen System kommen können) an eben dieses wieder zurückschickt. Ein Standard Loopbackdevice wird von jedem Betriebssystem auf 127.0.0.1 eingerichtet, worauf sich so manche Anwendung verlässt. Da ein Loopbackdevice mit dieser IP natürlich auch unter Windows 7 existiert, kann man es nicht für meinen Zweck verwenden. Ich dachte nun, dass ein zweites Loopbackdevice mit der IP 192.168.56.4 auf dem Host System meine Anforderungen erfüllen würde. Anfragen auf diese IP würden vom Host direkt an sich selbst gehen und vom Guest aus über das Host-Only Netzwerk ja zum Host weitergeleitet werden, wo die Anfrage wieder auf den Host aufgelöst werden würde (zumindest nach meinem Verständnis).

Scheinbar klappt das aber nicht so wie ich mir das denke. Zumindest bezieht mein Guest dann keine IP mehr korrekt. Mit einem Dummy-device geht es allerdings, nur leider bekomme ich das noch nicht persistent eingetragen. Worin der Unterschied zwischen Loopback und Dummy besteht, ist mir leider nicht bewusst. Ich würde mich über jeden konstruktiven Beitrag freuen, der meine Wissenslücken diesbezüglich schließt bzw. mein Problem abschließend löst.

Gruß, Felix

Benutzeravatar
Felix
Beiträge: 453
Registriert: 17.02.2003 10:26:57
Lizenz eigener Beiträge: MIT Lizenz

Re: Verständnisfrage Loopbackdevice

Beitrag von Felix » 14.01.2019 20:45:32

So, jetzt hab ich noch ein bisschen rumprobiert und in meiner /etc/network/interfaces Folgendes stehen:

Code: Alles auswählen

auto dummy0
iface dummy0 inet manual
  up /sbin/ifconfig dummy0 192.168.56.4/24
Nun tut's wie's soll. Wenn mir jetzt noch jemand erklärt, warum das geht und alle anderen Varianten nicht gingen würde ich mich freuen. Aber grundsätzlich ist damit mein Problem erstmal gelöst. Danke an alle Mitwirkenden. :)

Gruß, Felix

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: Verständnisfrage Loopbackdevice

Beitrag von ReturnToSender » 14.01.2019 20:56:57

VirtualBox richtet meiner Erinnerung nach alle Guest-VMs als NAT-Netzwerk ein. Damit hat der VM-Guest natürlich ein anderes Netzwerk als der Gastgeber-Host und dessen LAN und kann deswegen nicht so einfach die anderen Geräte im Heimnetz erreichen. Wenn das notwendig wäre, hätte ich das Netz des VM-Guests als Bridge eingerichtet, wodurch es eine reguläre LAN-IP bekommt und damit natürlich auch den Web-Server auf dem Gastgeber-Host erreichen kann.

Aber wenn das mit dem Dummy-NIC auch geht, scheint das ja eine praktikable Lösung zu sein.

Benutzeravatar
Felix
Beiträge: 453
Registriert: 17.02.2003 10:26:57
Lizenz eigener Beiträge: MIT Lizenz

Re: Verständnisfrage Loopbackdevice

Beitrag von Felix » 14.01.2019 21:01:44

Ja, das tut VirtualBox standardmäßig so. Aber ich wollte eben genau so ein Host-Only Netzwerk, also ein kleines lokales Netzwerk nur zwischen Guest und Host, damit Windows 7 nicht irgendwelche Dinge tut die ich dann mit anderer Software wieder verhindern muss, aber trotzdem der Guest auf den Host zugreifen kann. Leider funktioniert meine Lösung nach einem Neustart nicht. Also bin ich doch noch nicht fertig. :/

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: Verständnisfrage Loopbackdevice

Beitrag von ReturnToSender » 14.01.2019 21:14:10

Ja, und ich habe auch Quatsch erzählt. Trotz anderem Guest-Netzwerk sorgt NAT ja dafür, dass die VM quasi doch im Heimnetz ist... bei mir klappt das also ... aus der VM sind reguläre LAN-IPs und auch deren Web-Interfaces im Heimnetz erreichbar.

Benutzeravatar
unitra
Beiträge: 638
Registriert: 15.06.2002 21:09:38
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.128.129.130

Re: Verständnisfrage Loopbackdevice

Beitrag von unitra » 14.01.2019 23:00:31

Hallo, auch wenn das initiale Problem bereits gelöst is,. Ich möchte die hier getätigten Aussagen über das Loopback Interface hier korrigieren.

Ein Loopback Interface ist ein virutelle Schnittstelle. Das Loopback Interface hat auf PC Systemen (Rechner, Server) in der default Einstellung immer die IP Adresse aus dem Netz 127.0.0.0/8. Fast immer die 127.0.0.1, aber es kann auch die 127.126.125.124 sein.

Führt folgendes durch auf euren Linux hosts:

Code: Alles auswählen

user@host # ping 127.126.125.124
PING 127.126.125.124 (127.126.125.124) 56(84) bytes of data.
64 bytes from 127.126.125.124: icmp_seq=1 ttl=64 time=0.031 ms
Andere Betriebsysteme verhalten sich bei genau diesem Test manchmal anders, z.B. MacOS oder Windows, da der TCP/IP Stack unterschiedlich implementiert ist.

Das Loopback Interface kann aber jede belibige IP Adresse haben wie z.B. auch die die auf der Schnittstelle eth0 ist (RFC1918) oder auch eine andere die im Internet geroutet wird. Man kann auch viele Loopback Interaces auf einem Rechner konfigurieren. So viele man möchte, mit unterschiedlichen IP Adressen.

Gebraucht wird es auf Rechnern und Servern zur lokalen Kommunikation aber nicht weil es das Loopback ist, sondern weil es eine IP Adresse aus dem Netz 127.0.0.0/8 hat. Die IP Adresse macht es dass es zur Schnitttelle für die lokale Kommunikation, nicht das Loopback interface an sich.

Das Loopback Interface kann auch zum Troubleshooting herangezogen werden. Wenn man auf einem Rechner das Loopbackinterface nicht anpingen kann, oder es antwortet nicht, oder ähnliches, dann ist das ein Hinweis auf eine defekten TCP/IP Stack.

Der letzte Punkt zum Loopback Interace und auch die wirklich wichtigste Eigenschaft ist daß das Loopback Interace immer up/up ist. Wogegen physiche Schnittstellen wie eth0, eth1, ethN immer nur dann up/up sind wenn eine aktive Komponente auf der gegenseite verbunden ist (Switch, Router, Host).
Somit kann man z.B. daemons die auf das physiche "Netzwerk" warten müssen, stattdessen auf eine lokal konfigurierte Loopback IP Adresse binden. Jedem Dienst eine eigene Loopback IP Adresse zuweisen. Es gibt viele Einsatzmöglichkeiten.
Proffessionelle Router (richtige Router, ich meine keine FritzBox) haben oft unzählige Loopback Schnittstellen, mit unterschiedlichen IP Adressen für unterschiedliche Einsatzzwecke.
ReturnToSender hat geschrieben: ↑ zum Beitrag ↑
14.01.2019 15:17:59
Felix hat geschrieben: ↑ zum Beitrag ↑
13.01.2019 21:16:02
Oder habe ich die Konfiguration des Loopbackdevices falsch vorgenommen?
... Das ist ein virtuelles Netzwerk-Device für eine IP-Adresse aus dem reservierten Bereich von 127.0.0.1 bis 127.255.255.254. Im Regelfall hat das LO-Device die Static-IP 127.0.0.1. Gebraucht wird dieses Device zur Kommunikation lokal (!) laufender Dienste/Programme untereinader, ohne auf ein physisch vorhandenes Netzwerk-Gerät zugreifen zu müssen. Also z.B. wenn der lokale Browser auf der gleichen Maschine lokal eine Webseite mit der Adresse 127.0.0.1 öffnet... wie z.B. das Cups-Web-Interface mit http ://localhost:631/
...

mat6937
Beiträge: 2927
Registriert: 09.12.2014 10:44:00

Re: Verständnisfrage Loopbackdevice

Beitrag von mat6937 » 15.01.2019 09:58:17

unitra hat geschrieben: ↑ zum Beitrag ↑
14.01.2019 23:00:31
Wogegen physiche Schnittstellen wie eth0, eth1, ethN immer nur dann up/up sind wenn eine aktive Komponente auf der gegenseite verbunden ist (Switch, Router, Host).
Das stimmt so nicht, denn der daemon kann auch mit der IP-Adresse einer physichen Schnittstelle (hier eth0) lauschen, die nicht "LOWER_UP" ist (d. h. es ist _kein_ Kabel an der NIC angeschlossen: "NO-CARRIER"). Nach dem das Kabel angeschlossen wird, ist der daemon sofort erreichbar. Z. B.:

Code: Alles auswählen

:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether##:##:##:fd:3f:31 brd ff:ff:ff:ff:ff:ff
    inet 192.168.177.23/24 brd 192.168.177.255 scope global eth0
       valid_lft forever preferred_lft forever

Code: Alles auswählen

:~ $ netstat -tlpena | grep -i 192.168.177.23
tcp        0      0 192.168.177.23:3356     0.0.0.0:*               LISTEN      0          9086        520/sshd   

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: Verständnisfrage Loopbackdevice

Beitrag von ReturnToSender » 15.01.2019 10:33:06

In Ergänzung an das, was mat6937 bereits festgestellt hat, gilt das gleiche auch für wlan-Interfaces, die immer vollständig funktionieren, auch ohne mit einer aktiven Komponente auf der Gegenseite verbunden zu sein. Wäre das anders, könnten sie gar nicht nach verfügbaren SSIDs scannen und sich ggf. verbinden. Das heisst, jedes Interface funktioniert erst mal grundsätzlich allein dadurch, dass es UP ist.
unitra hat geschrieben: ↑ zum Beitrag ↑
14.01.2019 23:00:31
Der letzte Punkt zum Loopback Interace und auch die wirklich wichtigste Eigenschaft ist daß das Loopback Interace immer up/up ist.
Das ist leider auch nicht richtig. Man kann ein lo-Device wie jedes andere Netzwerk-Interface einfach ab- oder einschalten. Systemisch ist da nichts verhindert... wabei es mir jetzt hierbei nicht um die Folgen geht, sondern nur darum, was geht.

Code: Alles auswählen

ifconfig lo down
ip a
    1: lo: <LOOPBACK> mtu 65536 qdisc noqueue state DOWN group default qlen 1
ifconfig lo up
ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
unitra hat geschrieben: ↑ zum Beitrag ↑
14.01.2019 23:00:31
Ich möchte die hier getätigten Aussagen über das Loopback Interface hier korrigieren.
Weil Du dabei explizit meine Aussage zitierst würde ich doch gerne wissen, was korrigiert wurde, damit ich später an anderer Stelle nicht dummerweise erneut falsche Aussagen mache. Trotz mehrmaligen Lesens finde ich leider keine Korrekturen, sondern nur fast exakte Wiederholungen dessen, was ich in dem Absatz zuvor auch geschrieben habe.

Benutzeravatar
Felix
Beiträge: 453
Registriert: 17.02.2003 10:26:57
Lizenz eigener Beiträge: MIT Lizenz

Re: Verständnisfrage Loopbackdevice

Beitrag von Felix » 15.01.2019 11:10:03

Moin,

vielen Dank für eure Ausführungen. Leider lese ich da nicht raus, ob das was ich mir bisher dazu gedacht habe irgendwie falsch ist und ich ganz grundsätzliche Fehler gemacht habe. Vielleicht ist mein Wissen über Netzwerke aber auch nicht ausreichend dafür - obwohl ich das eigentlich mal studiert habe. ;)

Nachdem nun auch das Dummydevice nicht ganz so gearbeitet hat wie ich das gern wollte, habe ich nun eine wirklich funktionierende Lösung gefunden, die ganz auf Loopback und Dummy verzichtet. Ich starte nun einfach beim Systemstart mit:

Code: Alles auswählen

vboxmanage hostonlyif ipconfig vboxnet0 --ip 192.168.56.1 --netmask 255.255.255.0
den Host-seitigen virtuellen Adapter des internen Host-Guest Netzwerkes und nutze für meinen lokalen Server dessen IP. Meine Serveranwendung ist nun immer vom Host aus auf dieser IP erreichbar, egal ob die VM läuft oder nicht. Aus der VM heraus ist er ebenfalls immer über diese IP erreichbar. Simpler gehts wohl nicht mehr. Nur den virtuellen DHCP-Server hab ich so nicht ganz zum Laufen bekommen, aber ich habe dem Guest nun einfach eine statische IP gegeben. Find ich sogar noch besser. Vielen Dank noch mal an alle die mich bei der Lösung inspiriert haben und an alle die versucht haben mir das zu erklären - auch wenn ich leider immer noch nicht wirklich schlauer geworden bin.

Gruß, Felix

Benutzeravatar
unitra
Beiträge: 638
Registriert: 15.06.2002 21:09:38
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.128.129.130

Re: Verständnisfrage Loopbackdevice

Beitrag von unitra » 15.01.2019 14:38:42

Weißt Du, wenn jemand versucht was zu erklären, und das Gegenüber sich persönlich angegriffen fühlt, dann kommen eben solche Aussagen ans Licht.

Ich will Dir nichts und es ist mir auch egal ob Du es verstehen möchtest oder nicht, es gibt noch andere die den Thread eventuell irgendwann mal lesen werden.
Es geht hier nicht um Dich sondern um die Technologie.
ReturnToSender hat geschrieben: ↑ zum Beitrag ↑
15.01.2019 10:33:06
In Ergänzung an das, was mat6937 bereits festgestellt hat, gilt das gleiche auch für wlan-Interfaces, die immer vollständig funktionieren, auch ohne mit einer aktiven Komponente auf der Gegenseite verbunden zu sein. Wäre das anders, könnten sie gar nicht nach verfügbaren SSIDs scannen und sich ggf. verbinden. Das heisst, jedes Interface funktioniert erst mal grundsätzlich allein dadurch, dass es UP ist.
unitra hat geschrieben: ↑ zum Beitrag ↑
14.01.2019 23:00:31
Der letzte Punkt zum Loopback Interace und auch die wirklich wichtigste Eigenschaft ist daß das Loopback Interace immer up/up ist.
Das ist leider auch nicht richtig. Man kann ein lo-Device wie jedes andere Netzwerk-Interface einfach ab- oder einschalten. Systemisch ist da nichts verhindert... wabei es mir jetzt hierbei nicht um die Folgen geht, sondern nur darum, was geht.

Code: Alles auswählen

ifconfig lo down
ip a
    1: lo: <LOOPBACK> mtu 65536 qdisc noqueue state DOWN group default qlen 1
ifconfig lo up
ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
unitra hat geschrieben: ↑ zum Beitrag ↑
14.01.2019 23:00:31
Ich möchte die hier getätigten Aussagen über das Loopback Interface hier korrigieren.
Weil Du dabei explizit meine Aussage zitierst würde ich doch gerne wissen, was korrigiert wurde, damit ich später an anderer Stelle nicht dummerweise erneut falsche Aussagen mache. Trotz mehrmaligen Lesens finde ich leider keine Korrekturen, sondern nur fast exakte Wiederholungen dessen, was ich in dem Absatz zuvor auch geschrieben habe.
Zuletzt geändert von unitra am 15.01.2019 14:42:44, insgesamt 1-mal geändert.

Benutzeravatar
Felix
Beiträge: 453
Registriert: 17.02.2003 10:26:57
Lizenz eigener Beiträge: MIT Lizenz

Re: Verständnisfrage Loopbackdevice

Beitrag von Felix » 15.01.2019 14:41:50

Meinst du jetzt mich?

Benutzeravatar
unitra
Beiträge: 638
Registriert: 15.06.2002 21:09:38
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.128.129.130

Re: Verständnisfrage Loopbackdevice

Beitrag von unitra » 15.01.2019 14:44:15

Nein, ich meine den anderen den ich zitiert habe.
Felix hat geschrieben: ↑ zum Beitrag ↑
15.01.2019 14:41:50
Meinst du jetzt mich?

Benutzeravatar
unitra
Beiträge: 638
Registriert: 15.06.2002 21:09:38
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.128.129.130

Re: Verständnisfrage Loopbackdevice

Beitrag von unitra » 15.01.2019 17:55:45

Zitieren ist nicht Deine Stärke, einen Teil der Aussage rausschneiden, den Kontext zerreißen und dann negieren.
UP/UP heisst Status -> UP, Protocol -> UP.

Normalerweise ist das so, wenn der Träger da ist:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>

Kein Träger heisst nicht UP, oder auch NO_CARRIER genannt.
mat6937 hat geschrieben: ↑ zum Beitrag ↑
15.01.2019 09:58:17
unitra hat geschrieben: ↑ zum Beitrag ↑
14.01.2019 23:00:31
Wogegen physiche Schnittstellen wie eth0, eth1, ethN immer nur dann up/up sind wenn eine aktive Komponente auf der gegenseite verbunden ist (Switch, Router, Host).
Das stimmt so nicht, denn der daemon kann auch mit der IP-Adresse einer physichen Schnittstelle (hier eth0) lauschen, die nicht "LOWER_UP" ist (d. h. es ist _kein_ Kabel an der NIC angeschlossen: "NO-CARRIER"). Nach dem das Kabel angeschlossen wird, ist der daemon sofort erreichbar. Z. B.:

Code: Alles auswählen

:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether##:##:##:fd:3f:31 brd ff:ff:ff:ff:ff:ff
    inet 192.168.177.23/24 brd 192.168.177.255 scope global eth0
       valid_lft forever preferred_lft forever

Code: Alles auswählen

:~ $ netstat -tlpena | grep -i 192.168.177.23
tcp        0      0 192.168.177.23:3356     0.0.0.0:*               LISTEN      0          9086        520/sshd   

mat6937
Beiträge: 2927
Registriert: 09.12.2014 10:44:00

Re: Verständnisfrage Loopbackdevice

Beitrag von mat6937 » 15.01.2019 18:26:49

unitra hat geschrieben: ↑ zum Beitrag ↑
15.01.2019 17:55:45
Zitieren ist nicht Deine Stärke,...
Und erklären ist nicht deine Stärke. Ich habe das relevante zitiert, denn "NO_CARRIER" heißt nicht, dass der daemon an diesem Interface bzw. an der IP-Adresse des Interface, nicht lauschen kann, ... so wie Du das behauptet hast.

Benutzeravatar
unitra
Beiträge: 638
Registriert: 15.06.2002 21:09:38
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.128.129.130

Re: Verständnisfrage Loopbackdevice

Beitrag von unitra » 15.01.2019 19:06:02

Im welchen Status befindet sich die Schnittstelle ETH0 überwiegend wenn kein Träger da ist?
mat6937 hat geschrieben: ↑ zum Beitrag ↑
15.01.2019 18:26:49
unitra hat geschrieben: ↑ zum Beitrag ↑
15.01.2019 17:55:45
Zitieren ist nicht Deine Stärke,...
Und erklären ist nicht deine Stärke. Ich habe das relevante zitiert, denn "NO_CARRIER" heißt nicht, dass der daemon an diesem Interface bzw. an der IP-Adresse des Interface, nicht lauschen kann, ... so wie Du das behauptet hast.

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: Verständnisfrage Loopbackdevice

Beitrag von ReturnToSender » 15.01.2019 19:51:11

unitra hat geschrieben: ↑ zum Beitrag ↑
15.01.2019 14:38:42
Weißt Du, wenn jemand versucht was zu erklären, und das Gegenüber sich persönlich angegriffen fühlt, dann kommen eben solche Aussagen ans Licht.
Ja, richtig, ich habe versucht etwas (im groben Überblick) zu erklären, worauf Du dann meintest, das korrigieren zu müssen. Die Erklärung, was Du an meinen Aussagen korrigiert hast, bezogen auf den ursprünglich zitierten Absatz, fehlt allerdings immer noch. Ich finde es nur merkwürdig, dass Du Dich weniger mit dem ursprünglichen Problem befasst, sondern mit denen, die helfen wollen. Das ist m.M.n. im wesentlichen kontraproduktiv. Allerdings bin ich immer noch der Meinung, dass Du meine Aussagen tatsächlich nur wiederholt hast, also muss ich wohl irgendwas übersehen haben. Aber das klarzustellen müsste Dir doch leicht fallen.... und schon habe ich gelernt und alles ist in Ordnung. Es wäre auch nicht das schlechteste, ganz einfach sachlich zu bleiben und auf Angriffe oder sich angegriffen zu fühlen zu verzichten. Mich interessiert wirklich nur die angebliche Korrektur, sofern meinen Aussagen wirklich falsch waren... einfach nur deshalb, damit ich das künftig vermeiden kann.

Antworten