Nächster Hop in einer VPN-Route: Warum das Gateway lokal erreichbar sein muss

Eine Route in ein VPN-Netz trägt zwei Adressen, die leicht zu verwechseln sind: das Zielpräfix, das das Paket zu erreichen versucht, und den nächsten Hop, der es einen Schritt näher bringt. Auf einem LAN-Host muss dieser nächste Hop ein Router sein, den Sie tatsächlich auf demselben Link erreichen. Die entfernte VPN-Adresse ist kein nächster Hop, so sauber sie auch zu dem Ziel passen mag, das Sie im Sinn haben.

Dieses Runbook deckt den Normalfall ab: ein Laptop in 192.168.20.0/24, ein VPN-Gateway mit der LAN-Adresse 192.168.20.5 und ein entferntes Netz 10.70.0.0/24 hinter diesem Gateway. Alle Befehle unten gehen davon aus, dass Sie auf dem Laptop arbeiten, sofern nicht anders angegeben.

Zwei Adressen, eine Route

Der beabsichtigte Eintrag ist 10.70.0.0/24 via 192.168.20.5. Das Präfix sagt, wohin das Paket geht; die via-Adresse sagt, wer es dorthin trägt. Der Kernel weigert sich, eine Route zu installieren, deren Gateway er über die von Ihnen genannte Schnittstelle nicht erreichen kann, und diese Weigerung ist der ganze Punkt: ein nächster Hop, der den Tunnel braucht, um erreichbar zu sein, kann nicht der nächste Hop sein, der den Tunnel aufbaut.

Die erste Prüfung lautet also nicht «läuft das Gateway», sondern «liegt das Gateway auf diesem Link». Das eigene Subnetz des Laptops, sein ARP- oder Nachbareintrag und die Schnittstelle in der Route müssen übereinstimmen. Eine Adresse, die nur innerhalb von 10.70.0.0/24 existiert, kann Ziel einer zweiten Route sein, niemals via der ersten.

Wozu der nächste Hop das Gateway verpflichtet

Die Route auf dem Laptop zu installieren entscheidet nur die erste Übergabe. Danach braucht das Gateway seinen eigenen Weg: aktivierte Weiterleitung, eine Tunnelroute für 10.70.0.0/24 und jede Zugriffsrichtlinie, die regelt, wer sie nutzen darf. Unter Linux ist das net.ipv4.ip_forward=1 plus eine Tunnelroute; eine Firewall davor braucht eine Regel, die den weitergeleiteten Fluss erlaubt.

Die Rückrichtung ist der Teil, den Leute vergessen. Die entfernte Seite braucht eine Route zurück zu 192.168.20.0/24, oder das Design muss die Quelle des Laptops in etwas übersetzen, das die entfernte Seite kennt. Ein funktionierender Ping vom Gateway beweist, dass das Gateway das entfernte Netz erreicht; er sagt nichts darüber, ob die Pakete des Laptops den Rückweg überstehen.

Prüfen Sie die Suche vom Host, der sendet

Fragen Sie den Kernel, welchen nächsten Hop er wählen würde, und lesen Sie die Schnittstelle in der Antwort:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Wenn die Suche das Gateway und die LAN-Schnittstelle meldet, ist der erste Abschnitt wie beabsichtigt konfiguriert. Wenn sie das Tunnelgerät meldet, ist etwas früher in der Tabelle spezifischer und gewinnt. Wenn die Route gar nicht installiert wird, sagt Ihnen der Kernel, dass das Gateway nicht erreichbar ist, und diese Meldung ist nützlicher als jeder Paketmitschnitt.

Wiederholen Sie den Test dann vom richtigen Ort. Eine auf dem Gateway erzeugte Anfrage nutzt die eigene Quelladresse des Gateways, was eine fehlende Rückroute oder eine Richtlinie verbergen kann, die nur bestimmte Quellen zulässt. Das ip-route-Handbuch trennt Ziel, Gateway und die onlink-Überschreibung, und die Überschreibung lohnt sich zu verstehen, bevor Sie sie einsetzen.

Nutzen Sie onlink nicht, um Erreichbarkeit vorzutäuschen

onlink weist den Kernel an, die Erreichbarkeitsprüfung für ein Gateway zu überspringen und trotzdem dorthin zu senden. Es schafft keinen Pfad, löst kein ARP für eine Adresse auf, die nicht da ist, und bringt einen entfernten Router nicht dazu, auf Ihrem Ethernet-Segment zu antworten. Es ist legitim für Gateways, die antworten, aber nicht in einem verbundenen Subnetz liegen, und es ist eine Falle, wenn es benutzt wird, um einen Fehler zu übertünchen, den Sie nicht erklärt haben.

Wenn die Route nur mit onlink installiert wird, lautet die nächste Frage, warum das Gateway nicht dort ist, wo Sie es vermuten. Ein falsches VLAN, eine zweite Adresse auf der falschen Schnittstelle oder ein Tippfehler im letzten Oktett erzeugen das alle, und jeder davon bricht auch den Rückweg, sobald Verkehr zu fließen beginnt.

Punkt-zu-Punkt-Tunnel sind kein Ethernet

Ein Tunnelgerät macht kein ARP und hat oft kein sinnvolles Subnetz von Nachbarn. Seine Routen sehen häufig wie 10.70.0.0/24 dev tun0 aus, ganz ohne via, weil der Peer der einzige andere Endpunkt ist. Ein via im LAN-Stil in diese Tabelle zu kopieren erzeugt eine Route, die der Kernel ablehnen kann oder, schlimmer, eine, die auf eine Adresse zeigt, die der Peer nie beantwortet.

Halten Sie die beiden Modelle im Runbook getrennt: Eine LAN-Route hat ein erreichbares Gateway, eine Tunnelroute hat eine Schnittstelle und einen Peer. WireGuard, OpenVPN und IPsec zeigen alle etwas andere Formen, also notieren Sie die Form, die Sie tatsächlich verwendet haben, statt von einem Host zu verallgemeinern.

Hinzufügen, bestätigen, zurückrollen

Die ganze Änderung sind drei Befehle und eine Prüfung, und sie sollte in dieser Reihenfolge notiert werden:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Bestätigen Sie den Pfad, bestätigen Sie ein Ziel, und halten Sie dann die Löschzeile bereit, falls die Änderung den Host auf eine Weise unerreichbar macht, die Sie nicht vorhergesehen haben. Wenn die Route einen Neustart überleben soll, legen Sie sie in der Netzwerkkonfiguration des Hosts ab statt in einem Shell-Profil, und testen Sie den Neustart, bevor Sie sich darauf verlassen. Eine Route, die nur in der Shell existiert, die sie hinzugefügt hat, ist eine Route, die Sie zweimal debuggen werden.