Perché il tuo client OpenVPN resta fermo dopo un solo timeout

Lunedì mattina: il tunnel salito venerdì è sparito, l’interfaccia è ancora elencata e nulla nel registro dice che qualcuno se ne sia accorto. L’host è online, il pannello è verde e tutto ciò che ha inviato nel fine settimana è uscito dall’interfaccia fisica. Qui mancano due decisioni indipendenti: una sulla sopravvivenza del processo client a un guasto transitorio, l’altra sul riavvio del processo da parte di qualcosa sopra di esso dopo l’uscita. Correggerne una sola lascia aperta l’altra lacuna.

Parti da ciò che l’unità ha realmente fatto, non da ciò che sostiene il monitoraggio. systemctl status openvpn-client@office e journalctl -u openvpn-client@office -n 50 mostrano il motivo dell’uscita e l’ultima riga scritta dal client prima di andarsene.

Il processo è uscito prima che qualcuno se ne accorgesse

Un client che sparisce senza errore di solito è uscito di proposito. È il profilo a decidere questo comportamento, non il gestore dei servizi: ping-exit termina il processo appena il peer smette di rispondere, mentre ping-restart mantiene il processo e si riconnette al suo interno. I limiti di sessione e i timer di inattività producono dall’esterno la stessa immagine: senza tunnel e senza allarme.

Le due direttive ping non possono comparire insieme in un profilo, quindi scegline una e annota la scelta. Guarda anche il server, perché il suo ping-exit chiude una sessione qualunque cosa abbia chiesto il client, e solo il registro del server annota chi ha preso quella decisione.

Scegliere tra ping-exit e ping-restart

Scegli ping-restart per un portatile o un sito remoto che deve guarire da solo, e riserva ping-exit ai casi in cui un tunnel morto deve fermare il processo perché qualcos’altro possa agirvi. I numeri contano meno della relazione: ping 10 con ping-restart 60 significa dieci secondi di silenzio prima di una sonda e sessanta prima del riavvio, il che è aggressivo su un collegamento mobile con perdite e ragionevole su uno cablato. Scrivi il motivo accanto alla riga, altrimenti il lettore successivo presumerà che i valori predefiniti fossero deliberati.

Poi conferma che sia davvero il processo a essere uscito. Un’unità che dichiara attività mentre il tunnel è morto è un guasto diverso, trattato più sotto.

Una supervisione che riavvia davvero l’unità

Su un host systemd, la più piccola modifica duratura è un solo file drop-in: Restart=on-failure e RestartSec=10 in /etc/systemd/system/[email protected]/restart.conf. Un drop-in viene letto solo quando systemd ricarica le proprie definizioni, quindi esegui systemctl daemon-reload dopo. Verifica con systemctl show -p Restart -p ExecMainStatus openvpn-client@office invece di presumere che il valore sia arrivato. L’istanza nel nome del file deve essere il profilo che l’unità carica davvero, quindi un file scritto per office non fa nulla per openvpn-client@home.

on-failure ignora un caso: un’uscita pulita con stato zero. Alcuni percorsi di smontaggio finiscono così, quindi leggi lo stato registrato invece di fidarti della formulazione di una pagina di manuale. Se il tuo client si arrende con uno zero, ti serve Restart=always, e il costo è che un profilo davvero rotto torna ancora e ancora finché scatta il limite di velocità di avvio e il registro si riempie.

Restart=always scatta anche dopo un arresto deliberato. Usa systemctl stop per la manutenzione, e maschera l’unità se deve restare ferma mentre lavori.

Cogliere la fuga mentre il tunnel è fermo

La supervisione riporta su il tunnel; non impedisce al traffico di uscire mentre il tunnel è assente. persist-tun mantiene il dispositivo e le sue rotte tra le riconnessioni, il che è comodo e apre una finestra. Il dispositivo sopravvive, le rotte puntano ancora a esso e i pacchetti escono senza protezione e senza segnalazione. È una scelta di politica, non un valore predefinito neutro.

Quando un host non deve emettere affatto pacchetti non protetti, solo il firewall può garantirlo. Una regola di uscita che consente l’interfaccia del tunnel e l’indirizzo del server VPN scartando tutto il resto continua a valere dopo la morte del client, e nulla nella configurazione del client stesso può filtrare il traffico che il client non trasporta.

Provalo fermando il client di proposito. Esegui systemctl stop openvpn-client@office, poi curl -m 5 https://example.com, che dovrebbe fallire invece di riuscire attraverso il collegamento fisico. Un successo significa che la regola del firewall manca o è troppo permissiva.

Riconnetti, conferma che il tunnel trasporti di nuovo traffico, e solo allora aggiungi il controllo al monitoraggio. Interrogare ip addr da cron per un dispositivo tun è la supervisione che fallisce più spesso, perché con persist-tun il dispositivo sopravvive alla sessione e la sonda segnala salute mentre non viene trasportato nulla.