openconnect abgeschossen: Routen und DNS zeigen weiter in den Tunnel

Der Tunnel ist unten, aber die Maschine verhält sich weiter, als wäre er oben: eine Namensauflösung hängt, bis sie in einen Timeout läuft, und eine Route zeigt in eine Schnittstelle, die es nicht mehr gibt. Das ist die Signatur eines openconnect-Prozesses, der starb, ohne seinen Trennhelfer auszuführen. Der Netzwerkzustand, den er erzeugt hat, ist weiterhin installiert, und nichts sonst im System weiß, wie er zu entfernen ist.

Gehen Sie die Maschine in der Reihenfolge durch, in der der Zustand entstanden ist: Prozess, Link, Route, Resolver. Jeder Schritt sagt Ihnen, ob der Client wirklich weg ist oder nur von Ihrem Terminal abgekoppelt wurde, und diese Unterscheidung entscheidet, ob Sie überhaupt etwas reparieren.

Beginnen Sie beim Prozess, nicht bei der Konfiguration

Öffnen Sie ein Terminal und fragen Sie, was noch läuft, bevor Sie eine Route anfassen. pgrep -a openconnect listet jede Instanz mit ihren Argumenten auf, was die pid-Datei und das Skript zeigt, das ihr mitgegeben wurde. Ein Prozess, den Sie nicht erwartet haben, erklärt den Phantomtunnel schneller als jedes Log.

Wenn nichts läuft, sehen Sie sich den Link an. ip link show tun0 sagt Ihnen, ob die Schnittstelle überlebt hat, und ip route show dev tun0 listet Routen auf, die noch an sie gebunden sind. Prüfen Sie dann den Resolver mit resolvectl status. Notieren Sie alle drei Ausgaben, bevor Sie sie ändern, denn genau diese Aufzeichnung ist es, mit der Sie später einen veralteten Eintrag von einem neuen unterscheiden.

Eine Schnittstelle, die verschwindet, nimmt ihre Routen normalerweise mit. Routen, die den Link überleben, bedeuten meist, dass der Prozess noch lebt oder ein zweiter Client das Gerät besitzt.

Das Hilfsskript ist das, was die Änderungen rückgängig macht

openconnect entfernt die Schnittstelle, die Routen und die Resolver-Einträge nicht selbst. Es ruft einen externen Helfer auf, /etc/vpnc/vpnc-script in einem Upstream-Build und /usr/share/vpnc-scripts/vpnc-script in den Debian- und Ubuntu-Paketen, gewählt mit -s. Dasselbe Skript, das den Tunnel aufbaut, ist das, das ihn abbaut.

Wenn der Prozess endet, ohne diesen Helfer aufzurufen, bleibt der Zustand bestehen. OpenConnect-Handbuch sagt ausdrücklich, dass Routing und Namensdienst ohne das Skript nicht korrekt funktionieren, und beschreibt den Helfer als die Komponente, die den Schnittstellenzustand beim Beenden abbaut. Deshalb ist der Pfad wichtig, wenn Sie den Client mit -s.

Welches Signal diesen Pfad erreicht, hat sich zwischen Versionen geändert. Das Handbuch zu 7.06 behandelt SIGTERM als sofortiges Beenden, das das Skript überspringt. Aktuelle Builds dokumentieren INT und TERM als sauberes Stoppen, bei dem die Sitzung abgemeldet wird und der Helfer läuft. Lesen Sie den Abschnitt SIGNALS der Binärdatei, die Sie tatsächlich haben, statt eines der beiden Verhalten anzunehmen.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

Senden Sie das Signal, das Ihr Build dokumentiert

Wenn Sie das Signal kennen, stoppen Sie den Prozess über die pid statt über ein Muster.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

Wiederholen Sie dann die drei Prüfungen aus dem ersten Abschnitt, statt dem Exit-Status zu vertrauen. ip link show tun0 sollte fehlschlagen, ip route show dev tun0 sollte nichts ausgeben, und resolvectl status sollte den VPN-Link nicht mehr auflisten.

SIGHUP ist kein Stoppknopf: es trennt die Verbindung, führt das Skript aus und lässt die Sitzung wiederaufnehmbar mit --cookie. SIGUSR2 erzwingt eine sofortige Wiederverbindung. SIGKILL überspringt die Aufräumarbeit vollständig, und genau das ist der Zustand, um den es in diesem Artikel geht.

Reparieren Sie den Resolver, ohne resolv.conf zu ersetzen

Auf den meisten Ubuntu-Systemen ist /etc/resolv.conf ein symbolischer Link in systemd-resolved, keine Datei, die Sie bearbeiten sollten. Ihn zu ersetzen bricht die Namensauflösung für jedes Netzwerk, nicht nur für das VPN. Entfernen Sie stattdessen die Registrierung des Tunnels:

resolvectl revert tun0
resolvectl query example.com

Wenn das System resolvconf statt systemd-resolved verwendet, bleibt der Eintrag pro Schnittstelle bestehen, bis ihm gesagt wird, den Link fallen zu lassen, und resolvconf -d tun0 ist die entsprechende Aktion. Prüfen Sie, welcher Resolver verwendet wird, bevor Sie den Befehl wählen.

Eine Auflösung, die noch auf einen Server hinter dem toten Link zielt, hängt, bis sie in einen Timeout läuft, und diese Verzögerung sieht eher wie ein kaputter DNS-Server aus als wie eine übrig gebliebene Route.

Machen Sie das nächste Trennen langweilig

Halten Sie den Pfad der pid-Datei beim Start und beim Beenden identisch, indem Sie --pid-file jedes Mal übergeben, oder führen Sie openconnect unter einer Unit aus deren KillSignal zu dem Signal passt, das Ihre Version dokumentiert. Ein Test im Vordergrund zeigt Ihnen zuerst die Abschaltmeldungen, die der Helfer ausgibt.

Verbinden, trennen und die drei Prüfungen einmal ausführen. Ein sauberes Beenden hinterlässt keinen VPN-Link, keine VPN-Route und keinen VPN-Resolver-Eintrag. Überlebt eine der drei, wissen Sie jetzt, welche Komponente nicht aufgeräumt hat. Die nächste Untersuchung beginnt dann bei dieser Antwort statt bei einer hängenden Auflösung.