AnyConnect trennt bei geschlossenem Terminal: Sitzungsprüfungen

Der Tunnel steht, Sie schließen ein überzähliges Terminal, und das VPN bricht ohne einen einzigen Tastendruck im Client zusammen. Beim Linux-Client von AnyConnect ist die gemeldete Ursache die Sitzungsbuchhaltung und nicht das Routing: Der Client merkt sich, welche Anmeldesitzungen beim Aufbau des Tunnels existierten, und wertet das Ende jeder einzelnen davon als Grund, ihn abzubauen. Die folgenden Prüfungen laufen der Reihe nach, und die erste, die scheitert, sagt Ihnen, ob Sie überhaupt dieses Verhalten vor sich haben. Nichts in der üblichen Ausgabe des Clients erwähnt ein Terminal, weshalb der erste Reflex, den Konzentrator zu beschuldigen, meist verschwendete Mühe ist.

Fangen Sie nicht damit an, Systemdateien zu bearbeiten. Jeder Schritt erklärt entweder den Abbruch oder entfernt einen Kandidaten, und die billigen Schritte kommen zuerst.

Einen Sitzungsabbruch von einem Abbruch der darunterliegenden Verbindung trennen

Verbinden Sie sich sofort nach der Trennung erneut. Ein Tunnel, der innerhalb von Sekunden zurückkommt, im selben Netz, ohne neue Zugangsdaten, deutet auf einen lokalen Auslöser wie eine geschlossene Sitzung hin und nicht auf eine tote Uplink-Verbindung, Wi-Fi-Roaming oder ein Leerlauf-Timeout am Konzentrator. Ein Tunnel, der bei Connecting hängt oder erst nach einem Netzwerkwechsel zustande kommt, ist ein anderer Artikel.

Notieren Sie, was offen war, als der Tunnel aufgebaut wurde: das Terminal, aus dem Sie den Client gestartet haben, jede zweite Shell, die grafische Anmeldung und jede SSH-Sitzung von einem anderen Rechner. Sie brauchen diese Liste gleich, und sie nach dem nächsten Abbruch aus dem Gedächtnis zu rekonstruieren, ist unzuverlässig.

Prüfen, was der Client beim Verbindungsaufbau festgehalten hat

Der Client untersucht keine Prozess-Eltern oder Terminal-Eigentümerschaft. Er macht eine Momentaufnahme der Menge der beim Verbindungsaufbau vorhandenen Anmeldesitzungen und vergleicht diese Menge später; verschwindet ein Mitglied, scheitert der Vergleich und der Tunnel geht mit. Deshalb kann das Schließen des Fensters, aus dem Sie verbunden haben, harmlos sein, während das Schließen eines unbeteiligten überzähligen Terminals die Verbindung tötet: Entscheidend ist, ob diese Sitzung in der ursprünglichen Menge war. Die Prüfung ist ein Mengenvergleich und keine Zählung, weshalb das Ersetzen einer Sitzung so fatal sein kann wie der Verlust einer Sitzung.

Listen Sie auf, was der Client sehen konnte, bevor Sie etwas ändern:

who
w
last -n 10
sudo ls -l /run/utmp

Jede Zeile von who ist ein Benutzerprozess-Eintrag in utmp. Erscheint Ihre Sitzung zweimal, einmal für die grafische Anmeldung und einmal für das Terminal, dann existierten beim Verbindungsaufbau beide Einträge, und beide sind Kandidaten.

Nur den eigenen Eintrag aus utmp entfernen

Der veröffentlichte Workaround macht die Sitzung, die Sie gleich verwenden wollen, in utmp unsichtbar, bevor der Client startet. Ein kleines C-Programm läuft getutent() durch, findet den Datensatz, dessen ut_line dem TTY der Standardeingabe entspricht, und schreibt diesen Datensatz dann um. Die Reihenfolge ist beabsichtigt: setutent(), den Eintrag lesen, seine ut_id kopieren, ut_type auf DEAD_PROCESS setzen, die Felder für Benutzer und Zeile leeren, ihn mit pututline() zurückschreiben, dann endutent().

Kompilieren Sie es und führen Sie es dann als root aus der Shell aus, die den Client starten wird:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

Zwei Fehlerarten erklären die meisten Berichte, dass das Werkzeug nichts tue. Es wirkt auf das TTY, das an der Standardeingabe hängt; ein Start aus einem Skript oder einem Cron-Job ohne Terminal lässt ihm also nichts zum Abgleichen. Und /run/utmp ist für normale Benutzer nicht beschreibbar, weshalb ein Lauf ohne root still scheitert, sofern Sie den Exit-Status nicht prüfen.

Prüfen, ob der Tunnel das Schließen übersteht

Testen Sie den Mechanismus, statt ihn anzunehmen. Verbinden Sie sich aus einer Sitzung, die Sie behalten wollen, öffnen Sie ein zweites Terminal, schließen Sie das zweite und bestätigen Sie dann mit vpn state und einem Blick auf die Schnittstellenliste, dass der Tunnel noch steht. Übersteht er es, war der Auslöser ein bestimmter Sitzungstyp und nicht jede Sitzung, und Sie haben die Sitzung gefunden, die offen bleiben muss.

Bricht er trotzdem ab, lag die beobachtete Sitzung woanders, meist in der grafischen Anmeldung, die Ihr Terminal erzeugt hat, und einen TTY-Eintrag herauszuschneiden hilft dann nicht. Wiederholen Sie die Beobachtung mit der vollständigen Liste aus dem ersten Schritt, statt weitere Operationen hinzuzufügen.

Wann das Umschreiben von utmp die falsche Antwort ist

utmp ist gemeinsame Buchhaltung, keine private Tabelle. Den Eintrag einer noch lebenden Sitzung umzuschreiben, führt dazu, dass who, w und manche Audit-Werkzeuge sie zu niedrig ausweisen, und ein Programm, das denselben Eintrag später schließt, kann ganz scheitern. Halten Sie das Werkzeug auf Ihre eigene Sitzung beschränkt, bewahren Sie eine Kopie der Originaldatei auf und machen Sie daraus keinen Boot-Dienst, der jeden Datensatz entfernt.

Wenn Ihre Organisation Sitzungsbuchhaltung für die Compliance sammelt, steht der Workaround im Widerspruch zu dieser Anforderung, und die unterstützte Antwort ist eine andere Client-Version oder ein anderer Zugriffsweg, nicht ein gepatchtes utmp. Für die meisten Leute ist die am wenigsten invasive Lösung, den Client einfach aus einer Sitzung zu starten, die den ganzen Tag offen bleibt, und dieses Fenster in Ruhe zu lassen.

Bevor Sie das Ticket schließen, halten Sie fest, welche Sitzung der Client beobachtet hat, als der Tunnel aufgebaut wurde. Genau diese eine Zeile macht aus einer rätselhaften Trennung eine reproduzierbare Bedingung für die nächste Person an der Maschine.