VPN meldet verbunden, aber nichts wird geroutet: zwei Stellen zum Nachsehen

Ein Tunnel kann „verbunden“ melden, während nichts ihn erreicht, und die beiden Fakten liegen an verschiedenen Stellen. Eines ist die Routentabelle, die Pakete noch an ein Gerät schicken kann, das niemandem gehört. Das andere ist der Resolver, der noch einen Server auf einem Link führen kann, der verschwunden ist. Die Netzwerkänderung hat das Profil nicht beschädigt, sie hat den Zustand der vorherigen Verbindung verwaist, und die Reparatur hängt davon ab, welche der beiden Stellen du gerade ansiehst.

Zuerst den Kernel fragen, welches Gerät er nutzen würde

Eine Routenauflistung zeigt, was existiert; ein Routen-Lookup zeigt, was passieren würde. Frage nach einer öffentlichen Adresse und lies den Gerätenamen in der Antwort, denn dieses eine Feld entscheidet, ob das Paket irgendwo Nützliches ankommt. Nennt die Antwort ein Tunnelgerät, gibt der Kernel die Pakete dorthin, selbst wenn hinter dieser Schnittstelle kein Client-Prozess mehr läuft. Nennt die Antwort den physischen Adapter, während der Client Verbindung behauptet, ist der Tunnel oben und lediglich nicht der gewählte Pfad.

Der zweite Fall ist der übliche, nachdem ein Kabel das WLAN ersetzt, und er stellt sich als kaputtes VPN dar.

ip route show default
ip route get 203.0.113.9

Lies als Nächstes die Default-Einträge, denn eine Route aus der vorherigen Basisverbindung kann einen Linkwechsel überleben und vor der neuen stehen. Eine Default-Route durch ein Gerät, das ausgefallen ist, ist schlimmer als keine Default-Route, weil der Kernel sie trotzdem bevorzugt. Achte auf die Metrik neben jedem Eintrag, denn diese Reihenfolge erklärt die Präferenz schneller als die Schnittstellennamen.

Dann den Resolver pro Link lesen, nicht pro Datei

Namensauflösung trägt ihren eigenen Zustand und ihre eigene Veraltung. Ein Resolver, der DNS-Server pro Link auflistet, behält die Server eines Tunnel-Links, der ausgefallen, aber noch registriert ist, und jede Abfrage wartet dann auf einen Server, der nicht antworten wird. Das Symptom ist ein Netzwerk, das tot wirkt, während die Routentabelle perfekt aussieht.

Prüfe den Zustand pro Link statt die Datei, denn auf vielen Distributionen ist diese Datei ein Symlink in den Resolver und ein Bearbeiten bewirkt entweder nichts oder wird schnell überschrieben. Sieh nach, welcher Link welche Server und welche Suchdomain besitzt, und frage dann, ob der Tunnel-Link überhaupt noch registriert sein sollte. Wenn nicht, deaktiviere die Verbindung, der er gehört, statt generierten Zustand von Hand zu bearbeiten. Ein Name, der auflöst, während der Routen-Lookup Pakete woandershin schickt, ist ein dritter und eigener Fehler.

resolvectl status
resolvectl query app.internal.example

Wenn Adressen auflösen und Verbindungen scheitern, ist der Resolver in Ordnung und die Route nicht. Wenn Adressen überhaupt nicht auflösen, ist dies der richtige Ort zum Anfangen.

Wie eine veraltete Route die Änderung überlebt

Der Client besitzt das Netzwerk nicht allein. Auf einem NetworkManager-Host wird ein VPN-Profil über einer Basisverbindung aktiviert, und die Verbindungseinstellungen erlauben dieser Basis, das VPN zu benennen, das ihr folgen soll. Wenn die Basis wechselt, weil ein anderes Profil bevorzugt wird, folgt der Tunnel auf die neue Basis oder bleibt ohne eine.

Ein VPN-Profil bringt sich nicht selbst hoch, deshalb ist die Paarung weit wichtiger als die Autoconnect-Einstellung des Profils selbst.

Lies die aktive Liste und notiere, welche Basis oben ist, bevor du den Tunnel anfasst. Ist die Basis gelistet und der Tunnel nicht, fehlt die Route statt veraltet zu sein, und die Reparatur ist Aktivierung. Wenn das Aktivieren des Tunnels beklagt, es existiere keine Quellverbindung, ist die Basis verschwunden, mit der er gepaart war, also bringe diese zuerst hoch oder repariere die Paarung, statt den Tunnel erneut zu versuchen. Ein Profil ohne Elternteil erneut zu versuchen erzeugt jedes Mal denselben Fehler, was ein nützliches Signal und keine Plage ist.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Veralteten Zustand von einem fehlenden Elternteil unterscheiden

Drei Zustände erklären fast jeden Bericht, und jeder braucht eine andere Reparatur. Eine Default-Route durch ein Gerät, das noch existiert, aber den Tunnel nicht mehr trägt, ist veralteter Zustand, beseitigt entweder durch Löschen des Eintrags oder durch Neustarten des verantwortlichen Profils. Ein Tunnelgerät, dessen Client-Prozess verschwunden ist, ist ein Aufräumfehler, also verdient der Trennweg die Aufmerksamkeit statt der Routentabelle. Gar kein Tunnelgerät bedeutet, dass der Elternteil oder die Paarung fehlt und die Routentabelle nie beteiligt war.

Ein Neustart verdeckt, welchen der drei du hattest, und genau deshalb wirkt er wie eine Reparatur.

Frage nach der Reparatur den Kernel nach einer öffentlichen und einer internen Adresse und frage dann einen internen Namen ab. Wenn die Adresse funktioniert und der Name nicht, hast du ein Domain-Scope-Problem im Resolver gefunden und kein Routing-Problem. Notiere, welchen Zustand du gefunden hast, denn die nächste Netzwerkänderung wird den reproduzieren, den du in Ruhe gelassen hast.