Perché OpenVPN muore dopo il risveglio del portatile?

Metti la macchina in sospensione, risvegliala, poi controlla tre cose in questo ordine prima di toccare qualsiasi configurazione: se tun0 esiste ancora, se la rotta verso un indirizzo interno lo sceglie ancora e se il server elenca ancora questo peer. Un dispositivo che sopravvive alla sospensione mentre la rotta punta altrove è un residuo, non un tunnel. Quando la rotta è corretta e il traffico muore lo stesso, il guasto è sopra il tunnel e riavviare il client non lo cambierà. Automatizzare un riavvio ha senso solo dopo che un test manuale ha mostrato quale di questi tre casi hai.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Riproduci il risveglio prima di automatizzarlo

La sospensione termina la sessione cifrata più spesso di quanto rimuova il dispositivo. Il flusso UDP che teneva vivo il tunnel si ferma, il server può scartare il peer e il client o se ne accorge e si riconnette oppure mantiene un’interfaccia senza nulla dietro. Un controllo dell’interfaccia da solo dimostra poco, perché un dispositivo obsoleto sembra esattamente uno funzionante finché i pacchetti non devono attraversarlo. Esegui la ricerca della rotta più una richiesta reale attraverso il tunnel, poi leggi il registro intorno al momento del risveglio.

Se il client torna da solo, un hook aggiunge confusione invece di affidabilità. Se non si riprende mai, l’automazione è la soluzione onesta.

Dove vive davvero un hook di sospensione di systemd

Molte guide più vecchie indicano /etc/pm/sleep.d, una directory di proprietà di pm-utils che una sospensione basata su systemd non consulta mai. systemd legge gli hook da /usr/lib/systemd/system-sleep/ e /etc/systemd/system-sleep/, passando prima la fase e poi l’operazione, quindi pre e post sono gli unici valori su cui un hook si dirama. Tieni la copia locale sotto /etc invece di modificare un file pacchettizzato, e ricorda che lo script gira come root nel mezzo della transizione, quindi deve tornare in fretta.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart tocca un’unità solo quando è già attiva, quindi un tunnel che hai spento di proposito resta spento durante il risveglio. --no-block impedisce all’hook di aspettare mentre il client negozia, cosa che conta quando la rete non è ancora salita. Insieme i due flag significano un hook che fallisce in silenzio invece di trattenere tutta la sequenza di risveglio. Quando l’unità è già ferma non succede assolutamente nulla, che è esattamente il risultato che vuoi lì.

Recupera il servizio, lascia stare tun0

Abbassare tun0 a mano lascia il demone a sorvegliare un’interfaccia che non possiede più, e il successivo cambio di stato produce errori confusi. Punta al servizio o al suo profilo di connessione invece che all’interfaccia; controlla prima il nome esatto dell’unità, perché i pacchetti delle distribuzioni, OpenVPN 3 e NetworkManager scelgono nomi diversi. Un profilo NetworkManager torna quando quella connessione viene riciclata, quindi l’unità systemd non è lì il bersaglio. Qualunque sia il meccanismo, dovrebbe essere la stessa azione che hai verificato a mano.

Un riavvio reinstalla le rotte che il client ha spinto quando si è connesso. La maggior parte dei risvegli lo vuole. Una macchina dove hai aggiunto rotte tue no, quindi ricontrollale invece di dare per scontato che il recupero le abbia ripristinate, e scrivile dove il prossimo risveglio può trovarle.

Gestisci i tempi che non puoi controllare

L’associazione wireless e il DHCP spesso finiscono dopo che l’hook è stato eseguito, quindi un riavvio può fallire mentre non esiste ancora un percorso verso il server. Aspetta brevemente quell’indirizzo, riprova una volta e registra il risultato.

La risoluzione dei nomi è una corsa separata, perché lo stack di rete del desktop può ripristinare il DNS dopo che il tunnel è già su. Prova le risoluzioni da sole con resolvectl query internal.example invece di dedurle da una rotta funzionante. Un tunnel che instrada correttamente e non risolve nulla è un problema di DNS, non un problema di hook.

Mantieni visibile la decisione dell’hook scrivendo la fase, il nome dell’unità e il risultato nel registro. Annota nelle note della macchina quale test di risveglio hai eseguito, così un recupero funzionante si distingue da uno fortunato. Scegli l’azione meno invasiva che riporta il servizio e lascia che un client che si riprende da solo lo faccia. Un riavvio completo scarta le sessioni in corso, che è un costo reale su un portatile che si risveglia più volte al giorno.