Wie man VPN-gesetzte Routen von statischen unter Linux unterscheidet

Ein Präfix erscheint auf dem Laptop, wenn der Tunnel hochkommt, also fühlt es sich an, als hätte die VPN es installiert. Vielleicht hat sie das, aber dasselbe Ergebnis kann von einem Client-Skript stammen, das beim Verbinden läuft, von einem Verbindungsprofil, das das Subnetz auflistet, oder von einer statischen Route, die die ganze Zeit da war und erst zu funktionieren begann, als die Schnittstelle existierte. Den falschen Urheber zu wählen bedeutet, dass die Route nach jeder Bereinigung zurückkommt und die nächste Person dieselbe Korrektur wiederholt. Die folgende Reihenfolge trennt die drei, bevor irgendetwas geändert wird.

Schritt 1: den Mechanismus benennen, der Präfixe installiert

Verschiedene Protokolle liefern Erreichbarkeit auf verschiedene Weise, und alles davon eine Ankündigung zu nennen verdeckt den Unterschied. Ein OpenVPN-Server schiebt eine Routendirektive über den Steuerkanal, und der Client installiert sie, sofern kein Pull-Filter sie blockiert. Eine WireGuard-Konfiguration listet erlaubte Präfixe lokal auf, die der Client sowohl für Kryptoschlüssel-Routing als auch für die Routen verwendet, die er hinzufügt. Ein IPsec-Tunnel handelt Verkehrsselektoren mit dem Peer aus, und der Kernel installiert Routen aus diesen Selektoren.

Bestimmen Sie, welchen davon Ihr Tunnel nutzt, bevor Sie irgendeine Tabelle lesen. Eine beim Verbinden gesetzte Route ist keine Ankündigung eines Routingprotokolls und verspricht nicht, dass das Präfix hinter dem fernen Ende erreichbar ist. Notieren Sie den Mechanismus neben dem Präfix, denn er entscheidet, wohin die Korrektur gehört.

Schritt 2: die Tabelle über eine Verbindung hinweg vergleichen

Speichern Sie die Haupttabelle bei unten liegendem Tunnel, bringen Sie ihn hoch, speichern Sie erneut und vergleichen Sie die beiden Aufzeichnungen. Alles, was erschienen ist, gehört zum Verbindungslebenszyklus, und alles, was geblieben ist, gehört zur lokalen Konfiguration.

Zeichnen Sie sie mit ip route show table main > /tmp/route-down.txt auf, verbinden Sie sich und zeichnen Sie erneut auf. Tun Sie dasselbe für ip -6 route, wenn der Standort IPv6 nutzt, denn ein dort fehlendes Präfix erzeugt Fehler, die nichts mit Routing zu tun zu haben scheinen.

Schritt 3: die Metrik lesen, nicht nur die Anwesenheit

Zwei Einträge für dasselbe Präfix können nebeneinander bestehen, und der Kernel wählt die niedrigere Metrik. Eine statische Route mit Metrik 50 gewinnt weiterhin gegen eine gesetzte Route mit 100, obwohl beide sichtbar sind, weshalb „die Route ist da“ und „der Verkehr nutzt sie“ verschiedene Aussagen sind.

Fragen Sie den Kernel direkt mit ip route get 10.20.5.7 und lesen Sie die Schnittstelle, die er meldet. Wenn der Verkehr über den physischen Adapter hinausgeht, während eine Tunnelroute in der Tabelle steht, erklärt die Metrik oder die Präfixlänge das, nicht der VPN-Client. Wiederholen Sie die Abfrage für einen Host, von dem Sie wissen, dass er hinter dem Tunnel liegt, und für einen, von dem Sie wissen, dass er es nicht tut, und der Unterschied zeigt, ob die Aufteilung wie beabsichtigt funktioniert.

Schritt 4: die Einträge finden, die den Tunnel überleben

Statische Routen überleben eine Trennung konstruktionsbedingt, und daher stammen veraltete Einträge. Eine persistente Route auf eine Schnittstelle, die nicht mehr existiert, kann ein Subnetz still verschlucken, und eine auf einen wiederverwendeten Schnittstellennamen kann nach einem Neustart privaten Verkehr durch die falsche Tür schicken.

Prüfen Sie die persistente Seite an der Stelle, die Ihre Distribution nutzt, sei es eine systemd-networkd-Unit, ein NetworkManager-Profil oder ein Skript im up-Verzeichnis des Clients. Die Live-Tabelle mit ip route del zu korrigieren hält nur bis zur nächsten Verbindung. Behandeln Sie dieses Löschen als Test der Hypothese und nicht als die Reparatur.

Wo das ferne Ende die falsche Abdeckung liefert, sprechen Sie den Betreiber an, statt alles zu filtern. Alle gesetzten Einstellungen zu verwerfen wirft auch DNS und Split-Tunnel-Richtlinie weg, auf die das Profil angewiesen ist.

Schritt 5: den Rückweg bestätigen, bevor der Client beschuldigt wird

Für Site-to-Site oder ein Subnetz hinter dem Tunnel braucht die ferne Seite eine Route zurück zu Ihrer Client-Adresse und aktivierte Weiterleitung auf dem Gateway. Ein Einbahnweg sieht genau wie ein Client-Routingfehler aus, nur dass der Handshake und das ausgehende Paket beide erfolgreich sind.

Reverse-Path-Filtering fügt auf Linux-Gateways eine zweite Falle hinzu. Eine Antwort, die auf einer anderen Schnittstelle ankommt als die Route vorhersagt, wird im strikten Modus verworfen, und asymmetrische Wege über zwei Anbieter lösen das zuverlässig aus. Die Drop-Zähler auf dem Gateway, nicht auf dem Client, sagen Ihnen, ob die Filterung die Ursache ist.

Schritt 6: die Ressource testen, nicht den Ping

Sobald die gewählte Route korrekt ist, öffnen Sie die eigentliche Ressource und bestätigen Sie den Rückverkehr. Eine Ping-Antwort beweist den Weg in eine Richtung und nichts über den Dienst, und ein Dienst, der auf einer gecachten Verbindung antwortet, beweist noch weniger.

Wiederholen Sie dann die ganze Prüfung nach einem erneuten Verbinden. Der Wert der Reihenfolge liegt darin, dass sie vorhersagt, was die nächste Verbindung tun wird, weshalb sowohl der Vergleich als auch die Metrik ins Ticket gehören.