OpenVPN continua a ritentare dopo un errore TLS: come fermarlo

Il client si connette, fallisce durante la negoziazione TLS, attende e riprova lo stesso server con lo stesso risultato. Sotto un supervisore che riavvia un processo fallito, quei tentativi diventano un ciclo infinito nel registro, e la prima riga diagnostica esce dalla visuale. OpenVPN offre un’opzione che trasforma quel fallimento di negoziazione in un’uscita visibile invece di un altro tentativo. È un’impostazione di diagnostica e supervisione, non una riparazione, quindi abbinatela a una politica che lasci davvero il processo fermo.

Il ciclo che nasconde il primo errore

Quello che vedete è un blocco ripetuto e non un singolo guasto: un tentativo di connessione, un errore TLS, una pausa e poi la stessa sequenza. Ogni ripetizione spinge la riga originale più su nel registro. Se l’unità si riavvia in caso di guasto, il ciclo può durare ore senza che nessuno legga la causa. Il sintomo è il ciclo, anche se il difetto sottostante è un solo problema di negoziazione.

Le sessioni interattive lo tollerano perché un guasto transitorio può sparire al tentativo successivo. Le connessioni automatiche non possono permettersi lo stesso ottimismo: il processo deve fermarsi perché una persona o un monitor veda lo stato.

Prima di cambiare qualcosa, catturate un ciclo completo. Annotate l’indirizzo remoto, lo stadio TLS indicato nell’errore e se il processo esce del tutto.

Il meccanismo di ripetizione dietro il ciclo

Riprovare è il comportamento predefinito perché diversi timeout non correlati condividono lo stesso meccanismo. connect-retry imposta l’intervallo tra i tentativi di connessione, connect-retry-max può limitare quanto spesso viene provata ogni voce remota, e resolv-retry governa le ricerche ripetute dei nomi. Un fallimento della negoziazione TLS raggiunge quel meccanismo come evento di trasporto, quindi il client pianifica un altro tentativo invece di segnalare. Il valore predefinito aiuta su un collegamento instabile e nuoce a un difetto che non può guarire.

L’opzione --tls-exit cambia solo il caso della negoziazione. Il manuale la descrive come uscita in caso di fallimento della negoziazione TLS, che è più stretto dell’uscita su ogni errore. I timeout, i guasti del resolver e i rifiuti di autenticazione mantengono il proprio comportamento.

Far uscire il client in caso di errore TLS

Mettete tls-exit nel profilo che il client carica davvero, oppure passate --tls-exit all’avvio, ed eseguitelo una volta in primo piano. Leggete lo stato di uscita e l’ultima riga del registro, perché è sullo stato che agisce un supervisore. Un’uscita diversa da zero dopo un fallimento di negoziazione è il risultato previsto. Se il processo continua a riprovare invece di terminare, l’opzione non è nel profilo che il client carica davvero.

Il supervisore decide se quell’uscita è visibile. Un’unità systemd con Restart=always o Restart=on-failure avvia di nuovo il client, quindi il ciclo continua e l’opzione sembra non fare nulla. Controllate la politica prima di dare la colpa al client:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no lascia il processo fermo, e Restart=on-failure riavvia comunque dopo uno stato diverso da zero. Se volete che il guasto sia visibile ma che il servizio si riprenda da crash non correlati, impostate Restart=on-failure e usate StartLimitBurst e StartLimitIntervalSec per fermare la tempesta di riavvii. Poi leggete lo stato dell’unità per confermare l’ultimo codice di uscita: systemctl status lo riporta, e il registro conserva il primo errore sopra i riavvii.

Scrivete la decisione nell’unità o nelle note del profilo. Un profilo che esce in caso di errore TLS sembra un incidente alla persona successiva, a meno che il motivo sia registrato. Indicate quali guasti devono fermare il processo e quali vanno ritentati.

Dimostrarlo con un endpoint usa e getta

Per vedere il comportamento prima di fidarvene, copiate il profilo e puntate la copia a un endpoint che accetta una connessione TCP ma non parla mai OpenVPN. Basta un listener che risponde e poi tace. Con tls-exit, il client dovrebbe terminare quando la stretta di mano fallisce; senza, lo stesso profilo dovrebbe continuare a girare. Usate la copia, mai il profilo funzionante.

Confrontate le due esecuzioni per stato di uscita e per la prima riga di errore, non per quanto è durata ciascuna. Lo stato dice se l’opzione è scattata, e la prima riga dice quale stadio ha fallito.

Rimuovete il profilo di prova quando avete finito. Una copia con un endpoint volutamente sbagliato è una trappola per chiunque avvii in seguito ogni profilo della cartella.

Stadi che questa opzione non raggiunge mai

Un rifiuto di autenticazione è uno stadio successivo. Se il server valuta l’account e lo rifiuta, il TLS è già stato negoziato, quindi tls-exit non scatta. Le impostazioni di ripetizione dell’autenticazione sono il prossimo posto da guardare, e il motivo del server conta più dell’ultima riga del client. Una password sbagliata e un certificato mancante possono produrre messaggi simili lato client.

Una rotta mancante, un resolver sbagliato o un gateway irraggiungibile sono anch’essi fuori dall’opzione, perché non sono fallimenti di negoziazione. La perdita silenziosa di pacchetti è il caso meno evidente: a seconda di quanto è avanzato lo scambio, il client può segnalare un fallimento di negoziazione o semplicemente andare in timeout.

Mantenete la distinzione nelle vostre note. L’impostazione serve alla diagnostica e alla supervisione più che alla riparazione, quindi non corregge una discrepanza di cifratura, un problema di certificato o una porta sbagliata. Riparate prima la causa della negoziazione fallita, poi decidete se l’uscita immediata si adatta ancora alla distribuzione.