OpenConnect nach interaktivem Login im Hintergrund weiterlaufen lassen

Sie beenden die MFA-Abfrage, der Tunnel steht, und das Schließen des Terminals reißt die Verbindung mit. Das ist ein Aufsichtsproblem, kein Authentifizierungsproblem, und OpenConnect bringt den Schalter bereits mit, der es löst. Die Lösung besteht darin, den Client nach Abschluss des Starts in den Hintergrund abzweigen zu lassen, wenn der interaktive Teil wirklich vorbei ist. Es folgt eine Reihe von Prüfungen: Arbeiten Sie sie der Reihe nach ab und halten Sie bei der ersten an, die für Ihr Gateway nicht zutrifft.

Bestätigen Sie, was das Gateway beim Login verlangt

Bevor Sie einen Befehl eintippen, notieren Sie den Anmeldeinformationspfad, den die Bereitstellung erzwingt. Nur Zertifikat, Passwort plus Token und eine Browserrunde über einen SAML-Anbieter verhalten sich unterschiedlich, und der Hintergrundmodus kann keinen davon überspringen. Die Option ändert, was nach dem Start geschieht, nie, was währenddessen geschieht.

Der verlockende Ausweg ist, die Abfrage zu automatisieren. Ein Wrapper, der eine feste Antwort tippt, sobald er eine Passwortabfrage erkennt, bricht in dem Moment, in dem das Gateway einen Einmalcode verlangt, und hinterlässt Anmeldeinformationen in einer Datei, die andere Konten lesen können. Wenn ein Mensch die Sitzung freigeben muss, halten Sie den Menschen im Ablauf.

Führen Sie die erste Sitzung im Vordergrund aus und lesen Sie die Ausgabe

Verbinden Sie sich einmal normal und lassen Sie den gesamten Handshake ausgeben. Notieren Sie das verwendete Protokoll, den Zertifikat- oder Tokenpfad, die Tunneladresse, die der Server zuweist, und jede Warnung, die vor dem Annehmen der Verbindung erscheint. Dieses Protokoll ist Ihre Basislinie und der einzige billige Weg, später ein Clientproblem von einer Gateway-Änderung zu unterscheiden. Speichern Sie es außerhalb des Terminalpuffers.

Wiederholen Sie dann denselben Aufruf mit Hintergrundmodus und einer PID-Datei, zum Beispiel openconnect --background --pid-file /run/openconnect.pid vpn.example.net, und behalten Sie die Protokoll- und Authentifizierungsoptionen, die Ihr Gateway verlangt, in derselben Zeile. Das OpenConnect-Handbuch beschreibt diese Option als Fortsetzung im Hintergrund nach Abschluss des Starts, und genau deshalb muss die interaktive Phase zuerst beendet sein.

Machen Sie den laufenden Prozess auffindbar und stoppbar

Eine PID-Datei ist nur so lange ein Beleg, wie sie zu einem lebenden Prozess passt. Legen Sie sie in ein Verzeichnis, das dem Dienstkonto gehört, und vergleichen Sie die aufgezeichnete Nummer mit der Prozesstabelle, bevor Sie irgendetwas signalisieren. Neustarts und Abstürze lassen die Datei zurück, und eine veraltete Datei ist der übliche Grund, warum ein Stoppskript Erfolg meldet, während der Tunnel noch steht. Behandeln Sie die Prüfung als Teil des Stoppverfahrens, nicht als optionalen Schritt.

Signalisieren Sie die verifizierte PID und bestätigen Sie dann, dass die Tunnelschnittstelle tatsächlich verschwunden ist, statt dem Exit-Status zu vertrauen. Wenn der Client erhöhte Rechte benötigt, um die Schnittstelle zu konfigurieren, muss das Signal von einem Konto kommen, das es senden darf.

Stapeln Sie den Hintergrundmodus nicht unter einen Supervisor

systemd und ähnliche Supervisoren erwarten, den von ihnen gestarteten Prozess zu besitzen, weshalb ein Client, der abzweigt, sie verwirrt. Der Supervisor sieht einen Starter beenden, während die echte Verbindung weiterlebt, sodass Neustartlogik, Statusmeldungen und Stopp-Timeouts etwas beschreiben, das nicht mehr stimmt. Schreiben Sie die Unit in der unterstützten Vordergrundanordnung und lassen Sie den Supervisor die Daemonarbeit tun.

Halten Sie --background für Sitzungen zurück, die ein Mensch startet und dann weggeht. Wenn die Anforderung ein Tunnel ist, der existiert, bevor sich jemand anmeldet, fehlt eine genehmigte nichtinteraktive Identität plus ein Plan zu ihrer Erneuerung, und kein Kommandozeilenschalter liefert eines von beidem. Das Flag einem Bootskript hinzuzufügen erzeugt einen Tunnel, der beim ersten abgelaufenen Anmeldeinformationssatz still scheitert.

Behandeln Sie das Sitzungscookie als Anmeldeinformation

OpenConnect dokumentiert eine separate Authentifizierungsphase über --authenticate, und das entstehende Material kann mit --cookie-on-stdin zurückgegeben werden. Dieses Paar existiert für Integrationsarbeit, und was es erzeugt, ist so sensibel wie das Passwort, das es erzeugt hat.

Halten Sie den Wert aus der Shell-Historie, aus Protokollen und aus jedem Ticket heraus, das Sie öffnen. Ein Übergabeskript muss außerdem die verifizierten Endpunktinformationen bewahren, die der Client zusammen mit dem Cookie erhalten hat; geht das verloren, kann ein späterer Lauf sich mit einem Host verbinden, den Sie nie authentifiziert haben, was schlimmer ist als eine Verbindung, die einfach scheitert.

Arbeiten Sie die Liste ab, bevor Sie das Terminal schließen

Vier Dinge sollten zutreffen: Der interaktive Login wurde im Vordergrund abgeschlossen, die PID-Datei zeigt auf einen von Ihnen verifizierten Prozess, die Supervisor-Frage ist in die eine oder andere Richtung geklärt, und das Cookie hat einen Speicherplan, der keine Klartextdatei ist. Wenn alle vier gelten, ist das Weggehen vom Terminal sicher und der Tunnel läuft weiter.

Wenn eines davon scheitert, beheben Sie diesen Punkt, bevor Sie die anderen anfassen, denn die übrigen Prüfungen können ihn nicht ausgleichen. Bewahren Sie auch das Vordergrundprotokoll Ihres ersten Laufs auf: Wenn der Tunnel das nächste Mal ohne Vorwarnung abfällt, trennt genau diese Basislinie eine Änderung auf der Gateway-Seite von einer auf der Client-Seite.