Warum eine VPN-Route in der Ausgabe von ip route kein Gateway zeigt

Routingtabellen werden als kaputt fehlgelesen, sobald die Gateway-Spalte leer bleibt, obwohl die Zeile für sich genommen meist vollständig ist. Das Feld via erscheint nur, wenn der Kernel das Paket an eine Next-Hop-Adresse übergibt; eine an eine Schnittstelle gebundene Route erreicht ihre Ziele stattdessen über Link-Layer-Auflösung oder über einen Punkt-zu-Punkt-Peer. Die Spalten von links nach rechts zu lesen sagt dir, welcher Fall vorliegt, und dieses Lesen sollte geschehen, bevor jemand eine Default-Route ändert. Die meisten Tickets über ein fehlendes Gateway enden bei dieser Unterscheidung.

Eine Routenzeile Spalte für Spalte lesen

Jeder Eintrag beginnt mit dem Ziel und seiner Präfixlänge und fügt dann Modifikatoren in einem festen Vokabular hinzu: via, dev, proto, scope, src und metric. Eine Zeile wie 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 ist dicht, aber vollständig spezifiziert. Ihr fehlt nichts, und es wird keine Routeradresse impliziert.

Das Fehlen von via ist der interessante Teil. Ohne einen nächsten Hop löst der Kernel das Ziel direkt auf der genannten Schnittstelle auf, was bei einem Tunnel bedeutet, den Frame an das Tunnelgerät zu übergeben und die Kapselung von dort übernehmen zu lassen. proto kernel hält fest, dass der Eintrag automatisch installiert wurde, als eine Adresse zugewiesen wurde, nicht von einem Administrator eingetippt. scope link sagt, dass das Ziel auf diesem Link erreichbar ist, ohne einen Router zu passieren, und src nennt die Adresse, die der Kernel als Quelle für passenden Verkehr bevorzugen wird.

Lies nun eine Default-Route genauso: default via 192.0.2.254 dev eth0 proto static metric 100. Hier ist via vorhanden, weil das Paket einen nächsten Hop tatsächlich braucht, und dieser Hop muss selbst auf eth0 erreichbar sein. Die beiden Zeilen sind keine Varianten voneinander; sie beantworten verschiedene Fragen dazu, wohin der Verkehr geht.

Zwei Routenformen, die miteinander verwechselt werden

Eine Tunnel-Subnetzroute und eine Default-Route sehen auf einem Screenshot ähnlich aus und verhalten sich völlig unterschiedlich. Nutze die Tabelle unten als Lesehilfe für die Felder und bestätige dann die tatsächlichen Zahlen auf der Maschine, die du debuggst, statt einem Beispiel aus einer Anleitung zu vertrauen.

Was die Tabelle dir nicht sagen kann, ist die Absicht. Eine direkte Route in einen privaten Bereich durch einen Tunnel ist ein bewusstes Split-Tunnel-Design; dieselbe Form auf einem Host, der alles über das VPN senden sollte, ist ein Symptom. Absicht lebt in der Konfiguration, die den Eintrag erzeugt hat, also schau dir das Werkzeug an, das ihn installiert hat, bevor du schließt, dass der Kernel etwas falsch gemacht hat.

Ebenso ist ein fehlendes Gateway keine Erlaubnis, eines zu erfinden. Wenn eine Route wirklich einen nächsten Hop braucht, muss dieser Hop auf der Schnittstelle erreichbar sein, die ihn trägt, und bei einem Punkt-zu-Punkt-Tunnel ist die Peer-Adresse nicht dasselbe Objekt wie die lokale Adresse. Die lokale Tunneladresse als Ethernet-Router zu behandeln ist ein häufiger Weg, eine Route zu erzeugen, die korrekt aussieht und nichts weiterleitet.

Frag den Kernel, welche Zeile er tatsächlich verwenden wird

Die Tabelle zu lesen ist nicht dasselbe wie die Suche auszuführen, weil der Kernel politische Regeln, mehrere Tabellen und gecachte Einträge konsultiert, bevor er antwortet. Das Verb, das die echte Suche ausführt, ist ip route get, und es gibt die Route aus, die ein Paket mit diesen Eigenschaften nehmen würde.

ip route get 203.0.113.37 from 198.51.100.2 iif tun0

Setze das Ziel ein, das dich wirklich interessiert, und füge dann from oder iif hinzu, wenn der Verkehr quellenbasiert ausgewählt oder weitergeleitet wird, weil eine gewöhnliche lokale Suche einen anderen Pfad wählen kann als ein weitergeleiteter Client. Die Antwort nennt die Schnittstelle, die gewählte Quelladresse und jeden nächsten Hop, was dieselben Informationen sind, mit denen ein Paket in diesem Moment geroutet würde.

Wenn dich die Antwort überrascht, gib die Regeln aus, bevor du etwas änderst: ip -4 rule show listet sie in Prioritätsreihenfolge auf, und ein VPN-Client, der seine eigene Tabelle oder eine Regel für markierte Pakete installiert, taucht in der Haupttabelle überhaupt nicht auf. Alle Tabellen aufzulisten schließt diese Lücke.

ip -4 route show table all | grep -E 'tun|default'

Prüfe das Underlay, bevor du die Default-Route ersetzt

Die eigenen Pakete des Tunnels müssen den entfernten Endpunkt erreichen, und das tun sie über die physische Schnittstelle mit der Route, die vor dem Start des VPN existierte. Die gesamte Default-Route zu ersetzen, ohne diesen Endpunkt festzunageln, schickt die gekapselten Pakete in den Tunnel, den sie aufbauen sollen, und die Verbindung bricht zusammen. Bestätige zuerst den Endpunktpfad mit einer Suche allein nach der Endpunktadresse.

Halte drei Dinge getrennt, wenn du die Änderung vornimmst: die Endpunktroute, die auf der physischen Schnittstelle bleiben muss, die privaten Bereiche, die in den Tunnel sollen, und die Default-Route, die alles andere entscheidet. Trenne sie in dieser Reihenfolge, wende eine nach der anderen an und führe die Suche nach jedem Schritt erneut aus. Ein fehlgeschlagener Ping danach beweist für sich genommen sehr wenig, da Berechtigungen, Antwort-Routing, DNS und der Dienst selbst alle hinter einer korrekten Route liegen.

Notiere die vier Werte, die dir die Zeile vor der Änderung gegeben hat: Ziel, nächster Hop oder dessen Fehlen, Gerät und gewählte Quelle. Wenn eine spätere Änderung einen davon verschiebt, weißt du, welche Entscheidung tatsächlich verändert wurde, und kannst einen Eintrag wiederherstellen, statt die ganze Tabelle zu erraten.