☰

Warum funktioniert dieses Routing-Setup nicht?

tag-icon • tag-icon linux routing linux-networking
Warum funktioniert dieses Routing-Setup nicht?

Ich habe zwei Schnittstellen auf dem Server-Rechner. Die Ausgabe ip routeist folgende:

default via 192.168.100.1 dev enp1s0 proto static metric 100
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.1
192.168.100.0/24 dev enp1s0 proto kernel scope link src 192.168.100.201 metric 100

und ip addresskommt als nächstes (MACs sind ausgeblendet):

...
1: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.201/24 brd 192.168.100.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::1409:66c6:eb0d:22a1/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::85:5fff:fe98:6cb7/64 scope link
       valid_lft forever preferred_lft forever

Der /proc/sys/net/ipv4/ip_forwardWert ist 1; die Firewall ist deaktiviert.

Ich möchte auf192.168.100.1aus10.8.0.100. Der Zugriff auf den Webserver (der alle Ports auf diesem Rechner überwacht) curl --interface 10.8.0.100 http://10.8.0.1funktioniert einwandfrei. Aber curl --interface 10.8.0.100 http://192.168.100.201die Ausgabe ist Network unreachable.

Curl initiiert einen TCP-Handshake und sendet ein Paket an10.8.0.100Schnittstelle. Das Paket erreicht dann den Servercomputer auf10.8.0.1. Der Server schaut in das Paketziel und sieht, dass es192.168.100.201. Dann schaut es in die Routing-Tabelle und sieht, dass192.168.100.201ist lokal. Jetzt geht die Antwort zurück. Der Absender war10.8.0.100. Wenn wir uns die Routing-Tabelle ansehen, können wir feststellen, dass es über erreichbar ist tap0, was lokal ist. Jetzt gelangt es also zu tap010.8.0.100 und erreicht es.

Aber in Wirklichkeit -es ist nicht. Liegt das daran, dass mein Gedankengang falsch ist? Ich dachte, dass die in der beschriebenen Tabelle bereitgestellten Informationen ausreichen, um zu bestimmen, wie Pakete weitergeleitet werden. Ist dies tatsächlich unvollständig?

Antwort1

Zunächst einmal pingist die Angabe von IP-Adresse und Schnittstelle mit dem Parameter -I nicht gleichbedeutend. Zuerst wird angegeben, welche source IPausgewählt werden soll. Das Routing erfolgt gemäß dem Netzfluss, einschließlich lokaler Adressen und Routingtabellen. Zweitens wird angegeben, dass direkt die Schnittstelle ausgewählt werden soll, an die das Paket gesendet werden soll (und es wird die erste zugewiesene IP als Quelle ausgewählt).

Was Sie als Nächstes tun, hat nichts mit der Paketweiterleitung zu tun. Weiterleitung bedeutet, dass das Paket tatsächlich von „außen“ ankommen muss. Da Sie ein Paket von diesem Host aus generieren, ist keine Weiterleitung erforderlich. Es ist ein lokal generiertes Paket. Da Ihre Ziel-IP eine der lokal zugewiesenen Adressen ist, -I interfaceverarbeitet der Kernel diesen Paketfluss intern, wenn Sie Ping nicht zwingen, ein Paket an eine bestimmte Schnittstelle „außen“ zu senden (mit Option). Er versucht nur nicht, es an eine echte Schnittstelle auszugeben, da sein Ziel „bereits hier“ ist. Das ist also, was passiert und warum es in einem Fall funktioniert und in einem anderen nicht.

PS: Sehen Sie sich auch die -rOption des pingTools an, wenn Sie wissen, was Sie tun und beide Schnittstellen an dieselbe Broadcast-Domäne angeschlossen sind (bei der TAP-Schnittstelle bezweifle ich dies).

Antwort2

Das Problem war ein Missverständnis des Unterschieds zwischen --interface IPund --interface dev. Der erste verwendet eine Routing-Tabelle:

mit --interface 10.8.0.100dem Paket wird nicht an die Schnittstelle (zu der diese IP gehört) weitergeleitet tap0. Stattdessen wird es gemäß der Routing-Tabelle an 192.168.100.58(die LAN-Schnittstelle) weitergeleitet. Die Route lautet also 10.8.0.100 -> 192.168.100.58 -> 192.168.100.201. Obwohl SYN übermittelt wurde, antwortet der Server seltsamerweise nicht mit SYN-ACK – das ist der Grund für den Curl-Fehler.

Mithilfe --interface tap0der Link-Layer-Adresse funktioniert es wie vorgesehen: 10.8.0.100 -> 10.8.0.1 -> 192.168.100.201. Das SYN-ACK wird über dieselbe Route zurückgesendet.

verwandte Informationen