Warum eine gelöschte VPN-Route nach dem Neuverbinden zurückkommt

Eine Route, die du von Hand gelöscht hast, ist nach dem nächsten Verbindungsaufbau wieder da, und die Tabelle sieht genauso aus wie zuvor. Das ist kein Routing-Fehler: Etwas legt den Eintrag aus der Konfiguration oder aus einer Aktion im Verbindungslebenszyklus neu an. Die meisten Runbooks enden bei der Live-Tabelle, weshalb das Löschen eine Minute lang zu funktionieren scheint und dann scheitert. Finde den Verursacher, ändere ihn und beweise es bei einem erneuten Verbindungsaufbau.

Wer die Route angelegt hat

Beginne mit einer Liste möglicher Quellen statt mit einer Reparatur. Ein VPN-Profil kann eigene Routen mitbringen, ein Server kann sie beim Verbindungsaufbau pushen, ein NetworkManager-Profil kann sie deklarieren, eine Boot-Unit oder ein Skript kann sie hinzufügen, und IPsec-Implementierungen legen Routen für die ausgehandelten Traffic Selectors an. Auch Policy-Routing-Regeln können den Verkehr vollständig in eine andere Tabelle umleiten.

Die zeitliche Abfolge trennt die Quellen schneller als Konfigurationsforensik. Ein Eintrag, der in dem Moment erscheint, in dem die Schnittstelle hochkommt, gehört zum Client; einer, der eine Sekunde später auftaucht, kam meist von einem Server-Push; einer, der beim Booten vorhanden ist, gehört zur gespeicherten Konfiguration. Erfasse die Tabelle vor und nach einem Verbindungsaufbau, einem Trennen und einem Neustart, und das Muster benennt den Verursacher. Eine Route, die nur bei einem Neustart des Dienstes zurückkehrt, deutet auf eine Unit und nicht auf das VPN hin.

Tabelle lesen, bevor du sie bearbeitest

Sieh dir die Sicht des Kernels an statt einer gespeicherten Datei. Die Protokoll-Spalte zeigt, wodurch der jeweilige Eintrag angelegt wurde:

ip route show
ip route show table all
ip rule show

Das Protokollfeld, die Metrik und die Tabellennummer sagen dir, ob du einen statischen Eintrag, einen vom Kernel erzeugten oder etwas von einem Daemon Hinzugefügtes vor dir hast. Die Regelauflistung ist wichtig, weil eine Suche die Haupttabelle vollständig verlassen kann, wodurch eine Änderung dort für die Anwendung unsichtbar wird, die du gerade untersuchst. Lies die Zeile von links nach rechts: Ziel, Gateway, Gerät, Protokoll und Metrik.

Frage dann den Kernel, welche Route er tatsächlich verwenden würde. Eine geschützte Adresse ist eine bessere Sonde als eine öffentliche:

ip route get 10.20.5.7

Ändere den Verursacher, nicht das Symptom

Sobald der Verursacher bekannt ist, gehört die Änderung dorthin. Entferne die Route aus dem Client-Profil, korrigiere die gepushte Route auf dem Server oder bearbeite die NetworkManager-Verbindung, statt eine konkurrierende persistente Route hinzuzufügen, die per Metrik gewinnt. Zwei Regeln, die gegeneinander kämpfen, erzeugen eine Tabelle, die später niemand mehr erklären kann.

Behalte den Endpunkt-Ausschluss bei. Eine Host-Route, die die eigene öffentliche Adresse des VPN-Servers über das physische Gateway schickt, hält die äußeren Tunnelpakete am Fließen; lösche sie, und der Tunnel versucht, sich selbst zu tragen. Bei einem Split-Tunnel-Profil gilt dieselbe Sorgfalt für die lokalen Subnetze, die den Tunnel umgehen sollen.

Neu verbinden und beide Pfade prüfen

Verbinde dich erneut und prüfe beide Ziele in einem Durchgang. Die geschützte Adresse und der ausgeschlossene Endpunkt beantworten unterschiedliche Fragen:

ip route get 10.20.5.7
ip route get 198.51.100.20

Die erste sollte über die Tunnel-Schnittstelle aufgelöst werden und die zweite über das physische Gateway. Wenn beide über den Tunnel laufen, fehlt der Ausschluss; wenn keines das tut, hat die Profiländerung nicht gegriffen und du siehst einen anderen Verursacher als gedacht.

Notiere den Zweck der Route, ihren Verursacher und wie lange sie leben soll. Diese Notiz verhindert, dass die nächste Person denselben Zyklus aus Löschen und Neuverbinden wiederholt.