Per quanto tempo OpenConnect deve continuare a riprovare una VPN interrotta?

--reconnect-timeout risponde a una domanda ristretta: quando il tunnel cade, per quanto tempo questo processo client continua a provare prima di arrendersi e uscire. La pagina del manuale di OpenConnect registra quell’opzione con un valore predefinito documentato di 300 secondi per i tentativi che seguono un collegamento perso o un peer che ha smesso di rispondere, e il numero è una scadenza per un solo client in esecuzione, non una prova che la VPN resti raggiungibile. Non è nemmeno una politica per tenere vivo il processo, ed è lì che comincia la maggior parte della confusione.

La confusione cresce quando sopra si siede un secondo meccanismo. Un supervisore che riavvia il client, un sonda che fa ping al gateway e la finestra di tentativi integrata possono tutti reagire a un solo guasto, e l’incidente produce allora tre cronologie che nessuno riesce a conciliare.

Cosa limita davvero la finestra di riconnessione

Immaginate che la rete di accesso scompaia per qualche secondo. Il client vede cadere il collegamento, o smette di sentire le risposte del peer morto, e inizia a ristabilire la sessione trattenendo lo stato che può. I tentativi proseguono finché il gateway accetta di nuovo o finché la finestra si esaurisce, e una finestra esaurita termina con un’uscita diversa da zero. È quell’uscita, non il valore del timeout, il punto in cui la proprietà del ciclo di vita passa a chiunque supervisioni il processo.

La finestra non dice nulla sulla frequenza con cui viene eseguita una sonda e non può prolungare l’autenticazione. Se il gateway ha revocato la sessione, o l’account ora richiede un secondo fattore nuovo, aspettare di più non renderà di nuovo valida la vecchia sessione. Un nuovo tentativo riesce solo quando il percorso torna, il gateway riconosce ancora la sessione e le credenziali richieste restano utilizzabili, quindi leggete il numero come una scadenza e non come un intervallo di vitalità.

La finestra non governa nemmeno ciò che fanno le applicazioni mentre è in corso. A seconda della piattaforma e di quanto è andato avanti il guasto, il client può riconnettersi con le rotte ancora installate, o dopo che sono state rimosse. Per questo una richiesta emessa a metà interruzione tende a restare appesa fino alla scadenza invece di fallire subito.

Riavvii del supervisore e tentativi del client sono due livelli

Lasciate che il client in esecuzione consumi la propria finestra, e lasciate che il gestore dei servizi reagisca all’uscita. Un client in primo piano sotto systemd con una politica di riavvio dà esattamente questa separazione: tentativi per un periodo limitato, poi una sola decisione di riavvio. Il risultato è una sola cronologia che potete ancora ricostruire in seguito.

Un client in background più un sonda indipendente che avvia un’altra copia quando non vede un’interfaccia è lo schema che va storto. I due processi si contendono allora lo stesso nodo di dispositivo, le rotte e le impostazioni del resolver. Se volete davvero un demone, mettete l’opzione sulla riga di comando con cui il client parte realmente:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Due dettagli di quella riga pesano. --background stacca il processo, così il file pid diventa l’unica presa affidabile su di esso, e il timeout viene consumato solo finché quello stesso processo vive; un supervisore che lo uccide non lascia alcun budget per continuare.

Le disconnessioni intenzionali hanno bisogno di un proprio segnale. Una pausa pianificata e un’interruzione reale sembrano identiche a un osservatore ingenuo, ed entrambe si leggono come «non connesso». Guidate la pausa tramite l’operazione di arresto del supervisore, o un marcatore che il wrapper comprende, così che un arresto deliberato non faccia scattare un riavvio che nessuno ha chiesto.

Evitare che il passaggio di consegne corra contro il ciclo dei tentativi

Il recupero non presidiato dipende da credenziali che si rinnovano senza una persona presente. Un portachiavi che si sblocca solo dentro una sessione desktop interattiva, o un token che richiede sempre un codice digitato, lasceranno il client bloccato alla fase di autenticazione quando il percorso torna. Risolvete quel flusso prima di allungare la finestra, perché una finestra più lunga dà solo alla stessa richiesta bloccata più tempo per fallire.

La verifica del server non va allentata per ridurre le richieste. Proprio il pin o l’ancora di fiducia che convalida il gateway è ciò che rende sicura una riconnessione automatica, e disattivarlo per evitare una domanda sul certificato scambia un’interruzione visibile con una invisibile. Mantenete l’identità verificata e riparate invece la richiesta; un client disposto a connettersi a qualsiasi gateway è peggiore di uno che si ferma e aspetta.

Nemmeno la presenza dell’interfaccia è un segnale di salute. Un dispositivo di tunnel può esistere con una sessione morta dietro, e un processo di avvio può esistere senza alcun tunnel. Nessuna di queste osservazioni resiste a una richiesta reale. La salute deve venire da ciò che serve all’utente, come una richiesta che attraversa il tunnel verso un servizio interno noto.

Cosa verificare durante e dopo un’interruzione

Eseguite quattro eventi come test separati: un’interruzione più breve della finestra, un guasto più lungo di essa, un errore di autenticazione e un arresto intenzionale. Ognuno deve finire in uno stato diverso e prevedibile, e il confine tra i primi due è l’intera ragione per scegliere un valore.

Tenete i controlli rivolti verso l’esterno, perché la tabella dei processi da sola dimostra molto poco. Osservate che il pid resti stabile durante il taglio breve, poi confermate che è sparito e che è stato sostituito una volta dopo quello lungo:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Durante l’interruzione breve, confermate che il client abbia davvero ritentato invece di uscire presto, e che rotte e voci del resolver siano tornate senza duplicati. Per il guasto più lungo, confermate un’uscita pulita e esattamente un riavvio dopo. Per l’errore di autenticazione, confermate che il client non giri contro un gateway che continuerà a rifiutarlo. Aggiungete un controllo che il pid torni a un solo valore invece di accumularsi.

Per l’arresto deliberato, l’URL di salute deve restare irraggiungibile e il processo deve restare giù. Poi chiudete il ciclo dal lato applicativo: la stessa richiesta deve fallire mentre il tunnel manca e deve riuscire dopo il suo ritorno, dall’indirizzo di origine che la vostra politica si aspetta. Un’icona verde del tunnel non è una prova, ma una richiesta completata sì.