Come mandare OpenConnect in background dopo un accesso interattivo

Completi la richiesta MFA, il tunnel sale e chiudere il terminale porta giù anche la connessione. È un problema di supervisione, non di autenticazione, e OpenConnect include già l’opzione che lo risolve. La soluzione è lasciare che il client si biforchi in background al termine dell’avvio, quando la parte interattiva è davvero finita. Segue una serie di controlli: seguili in ordine e fermati al primo che non vale per il tuo gateway.

Verifica cosa richiede il gateway all’accesso

Prima di digitare un comando, annota il percorso delle credenziali imposto dalla distribuzione. Solo certificato, password più token, e un giro nel browser tramite un provider SAML si comportano diversamente, e la modalità background non può saltarne nessuno. L’opzione cambia ciò che accade dopo l’avvio, mai durante.

La tentazione è automatizzare la richiesta. Un wrapper che digita una risposta fissa quando riconosce una richiesta di password si rompe appena il gateway chiede un codice monouso e lascia una credenziale in un file leggibile da altri account. Se una persona deve approvare la sessione, tieni la persona nel ciclo.

Esegui la prima sessione in primo piano e leggi l’output

Connettiti una volta normalmente e lascia stampare tutta la stretta di mano. Annota il protocollo in uso, il percorso del certificato o del token, l’indirizzo del tunnel assegnato dal server e ogni avviso prima dell’accettazione. Quella trascrizione è la tua linea di base e l’unico modo economico per distinguere in seguito un problema del client da un cambiamento del gateway. Salvala fuori dal buffer del terminale.

Poi ripeti la stessa invocazione con la modalità background e un file PID aggiunto, per esempio openconnect --background --pid-file /run/openconnect.pid vpn.example.net, mantenendo il protocollo e le opzioni di autenticazione richiesti dal gateway sulla stessa riga. Il manuale di OpenConnect descrive l’opzione come prosecuzione in background dopo l’avvio, ed è proprio per questo che la fase interattiva deve essere conclusa prima.

Rendi individuabile e arrestabile il processo in esecuzione

Un file PID è prova solo finché corrisponde a un processo vivo. Mettilo in una directory di proprietà dell’account di servizio e confronta il numero registrato con la tabella dei processi prima di inviare un segnale. Riavvii e crash lasciano il file, e un file obsoleto è la ragione abituale per cui uno script di arresto segnala successo mentre il tunnel è ancora attivo. Tratta il controllo come parte della procedura di arresto, non come passo facoltativo.

Invia il segnale al PID verificato, poi conferma che l’interfaccia del tunnel è davvero scomparsa invece di fidarti del codice di uscita. Se il client richiede privilegi elevati per configurare l’interfaccia, il segnale deve venire da un account autorizzato a inviarlo.

Non impilare la modalità background sotto un supervisore

systemd e supervisori simili si aspettano di possedere il processo avviato, ed è per questo che un client che si biforca li confonde. Il supervisore vede uscire un launcher mentre la connessione reale continua, quindi logica di riavvio, report di stato e timeout di arresto descrivono qualcosa che non è più vero. Scrivi l’unità nella disposizione in primo piano supportata e lascia al supervisore il lavoro di demone.

Riserva --background alle sessioni avviate da una persona e poi abbandonate. Se il requisito è un tunnel esistente prima che qualcuno acceda, manca un’identità non interattiva approvata e un piano per rinnovarla, e nessun flag da riga di comando fornisce né l’una né l’altro. Aggiungere il flag a uno script di avvio produce un tunnel che fallisce in silenzio alla prima credenziale scaduta.

Tratta il cookie di sessione come una credenziale

OpenConnect documenta una fase di autenticazione separata tramite --authenticate, e il materiale risultante può essere restituito con --cookie-on-stdin. Quella coppia serve al lavoro di integrazione, e ciò che produce è sensibile quanto la password che l’ha creata.

Tieni il valore fuori dalla cronologia della shell, dai log e da qualsiasi ticket apri. Uno script di consegna deve anche preservare le informazioni verificate sull@endpoint ricevute dal client insieme al cookie; se le perdi, un’esecuzione successiva può connettersi a un host mai autenticato, peggio di una connessione che semplicemente fallisce.

Percorri la lista prima di chiudere il terminale

Quattro cose devono essere vere: l’accesso interattivo è terminato in primo piano, il file PID punta a un processo verificato, la questione del supervisore è risolta in un senso o nell’altro e il cookie ha un piano di archiviazione che non è un file di testo in chiaro. Quando tutte e quattro valgono, allontanarsi dal terminale è sicuro e il tunnel continua.

Se una fallisce, correggi quel punto prima di toccare gli altri, perché i controlli restanti non possono compensarla. Conserva anche la trascrizione in primo piano della prima esecuzione: la prossima volta che il tunnel cade senza avviso, quella linea di base separa un cambiamento lato gateway da uno lato client.