VPN meldet verbunden, aber die Standardroute ist tot

Der Client meldet verbunden, das Symbol im Infobereich sieht normal aus, und nichts lädt. Es begann direkt nach dem Wechsel von WLAN auf Kabel oder direkt nach dem Abschluss eines Distributions-Upgrades. Kaputt ist nicht das Profil, sondern der Zustand, der für die vorherige Basisverbindung aufgebaut wurde. Der Kernel hat noch eine Standardroute, die auf ein Tunnelgerät zeigt, das niemand besitzt, oder der Resolver listet weiterhin Server auf einem Link, der verschwunden ist. Beide Fehler sehen wie ein totes Netzwerk aus, und beide lassen sich an Ort und Stelle reparieren.

Die veralteten Teile waren schon falsch, bevor Sie es bemerkten. Das Ziehen eines Kabels machte sie nur sichtbar.

Fragen Sie den Kernel, wohin ein Paket gehen würde

Routenauflistungen sind schwer zu lesen, weil sie alles aufzählen, was das System kennt, einschließlich Einträgen, die nicht mehr gelten. Eine Routensuche beantwortet die einzige Frage, die sich lohnt: Welches Gerät trägt genau dieses Paket gerade jetzt. Nennt die Antwort ein Tunnelgerät, wird der Kernel es benutzen, obwohl dahinter kein laufender Client-Prozess steht, und das Paket fällt in eine Schnittstelle, die niemand pflegt. Nennt die Antwort den Ethernet-Adapter, während der Client darauf besteht, dass er aktiv ist, existiert der Tunnel, hat aber die Auswahl verloren — das übliche Ergebnis eines Wechsels von drahtlos auf kabelgebunden.

Führen Sie die Suche zweimal aus, einmal für eine öffentliche Adresse und einmal für eine interne, denn eine Split-Tunnel-Richtlinie kann die eine ehrlich routen und die andere fallen lassen.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

Der Resolver behält den toten Link ebenfalls

Auf einem Host mit systemd-resolved gehören DNS-Server zu Links und nicht zu einer globalen Liste. Ein VPN-Link, der ausgefallen ist, kann eine Weile mit seinen Servern registriert bleiben, und jede Suche wartet dann auf eine Adresse, die nie antworten wird. Diese Verzögerung fühlt sich wie ein totes Netzwerk an und schickt Leute zu den Routen, obwohl die Route in Ordnung ist.

resolvectl status
resolvectl query intranet.example.com

Lesen Sie die Blöcke pro Link und stellen Sie fest, welcher Link die betreffende Domain besitzt. Ein Tunnel, der aktiv ist, aber nicht Eigentümer der internen Domain ist, leitet interne Namen an den öffentlichen Resolver weiter, und das Symptom ist von einem Routingfehler nicht zu unterscheiden.

Reparieren Sie die Registrierung und nicht die Datei /etc/resolv.conf. Bei aktuellen Ubuntu- und Fedora-Installationen ist dieser Pfad ein symbolischer Link in den Laufzeitzustand des Resolvers, sodass eine Änderung entweder ignoriert oder beim nächsten Netzwerkereignis überschrieben wird.

Ein VPN startet nie von selbst

NetworkManager bringt ein VPN über einer Basisverbindung hoch und erfährt, welcher es folgen soll, aus connection.secondaries auf dieser Basis. Die Referenz für Verbindungseinstellungen stellt ausdrücklich fest, dass Autoconnect für VPN-Profile nicht implementiert ist. Das ist der ganze Mechanismus hinter dieser Fehlerklasse: Ändern Sie die Basis, und das VPN muss von Hand neu gepaart oder reaktiviert werden.

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

Wenn die aktive Liste die Basis ohne das VPN zeigt, ist der Tunnel überhaupt nicht aktiv, und die Route wurde nie installiert, statt veraltet liegen zu bleiben. Wenn sich die Aktivierung beschwert, dass keine Quellverbindung existiert, ist die Basis, mit der sie gepaart war, verschwunden, also reparieren Sie zuerst die Basis oder die Paarung und hören Sie auf, das VPN erneut zu versuchen.

Ein Upgrade kann Einstellungen ohne Meldung fallen lassen

Ein Distributions-Upgrade ersetzt den Client und oft sein NetworkManager-Plugin, während das gespeicherte Profil die Eigenschaftsnamen behält, mit denen es geschrieben wurde. Alles, was das neue Plugin nicht mehr erkennt, wird stillschweigend übersprungen. Das Profil aktiviert sich weiterhin, und das Gerät erscheint weiterhin, aber die Route, die früher damit kam, kommt nie mehr.

Handgeschriebene Hooks verschieben sich ebenfalls. Ein Skript, das an einem vorhersehbaren Punkt der alten Reihenfolge eine Route installierte, läuft jetzt vielleicht, bevor die Schnittstelle existiert, oder nachdem der Client bereits in einen Timeout gelaufen ist.

Vergleichen Sie das laufende Profil mit dem Plugin, das Sie tatsächlich haben, und nicht mit dem Verhalten, an das Sie sich erinnern. Wenn ein Schlüssel aus der Dokumentation verschwunden ist, verlagern Sie die Arbeit in ein Dispatcher-Skript oder einen unterstützten Ersatz, statt die alte Eigenschaft wiederherzustellen.

Drei Zustände, drei verschiedene Reparaturen

Entscheiden Sie, in welchem Zustand Sie sind, bevor Sie etwas anfassen, denn ein Neustart zerstört die Beweise, und der Fehler kehrt bei der nächsten Netzwerkänderung zurück.

Schließen Sie mit einer Suche für eine öffentliche Adresse, einer für eine interne Adresse und einer Namensabfrage ab. Wenn die Adressen funktionieren und der Name nicht, ist der verbleibende Fehler der Domainbereich im Resolver, und die Routentabelle war nie das Problem.