VPN morta dopo la sospensione: tunnel perduto o applicazione obsoleta?

Il coperchio si apre, l’icona wireless torna e la VPN risulta ancora connessa. La prima pagina interna si blocca allora fino allo scadere del tempo, e una nuova scheda fa lo stesso. Tre cose diverse possono produrre quell’immagine e richiedono tre correzioni diverse: un tunnel che non è sopravvissuto alla sospensione, un profilo che nessuno ha chiesto di riattivare, o un’applicazione che tiene ancora una sessione morta da ore. Confrontarle è più rapido che reinstallare qualsiasi cosa.

Tre cose possono rompersi dopo il risveglio

Il primo candidato è il tunnel stesso. L’interfaccia può esistere ancora con un indirizzo mentre l’associazione con il peer è sparita, per questo una spia non è prova di un percorso funzionante. Una stretta di mano più vecchia della sospensione è l’indizio, e basta un comando per vederla.

Il secondo è l’attivazione. Molti client si riconnettono da soli; altri no, e un profilo che nessuno invita a tornare resta lì e sembra configurato. Quel guasto è silenzioso per progetto, perché nulla ha segnalato un errore.

Il terzo è l’applicazione. Una scheda del browser, una sessione SSH o una connessione a un database possono sopravvivere a un cambio di rete come descrittore di file mentre il trasporto sotto è morto. Allora una sessione nuova funziona perfettamente, il che vi dice che il tunnel era a posto da sempre.

Confrontate i tre prima di cambiare qualsiasi cosa, perché le correzioni non si sovrappongono. Riavviare un client che non era mai stato invitato a ripartire spreca la prova che vi serviva. Annotate a quale candidato corrisponde il sintomo prima di toccare una configurazione. Quella sola frase di solito decide il resto dell’indagine.

Primo: il tunnel è tornato?

Guardate l’interfaccia e lo stato del peer invece del testo di stato del client. Un’interfaccia con un indirizzo e senza stretta di mano recente è un tunnel che esiste solo di nome.

ip -brief addr show
wg show
ip route show table all | head -20

Se l’interfaccia manca del tutto, il tunnel non è sopravvissuto e la domanda diventa chi avrebbe dovuto riportarlo. Se c’è ma la stretta di mano è vecchia, l’associazione con il peer va ristabilita, e il client forse attende traffico che la faccia scattare.

Controllate anche le rotte e la configurazione DNS. Un tunnel può tornare senza le sue rotte, il che produce lo stato confuso in cui l’interfaccia è attiva e i nomi interni si risolvono ancora tramite il server sbagliato.

Secondo: qualcosa gli ha chiesto di tornare?

È qui che il confronto si guadagna il suo posto. Un profilo di plugin OpenVPN e una connessione WireGuard nativa sono gestiti diversamente da NetworkManager, e la referenza delle impostazioni di connessione dice chiaramente che connection.autoconnect non attiva i profili VPN; il meccanismo per alzare una VPN insieme a una connessione è connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Se riconnettersi a mano ripara il problema ogni volta, è la firma di un’attivazione mancante e non di un tunnel rotto. Il registro di solito mostrerà l’interfaccia che cade e nulla che la riporti.

Resistete all’impulso di aggiungere subito un hook di sospensione. Un hook che scatta prima che la rete si sia ripresa gareggia con lo stesso processo a cui cerca di aiutare, e trasforma un problema riproducibile in uno intermittente.

Terzo: l’applicazione tiene uno stato vecchio?

Aprite una sessione completamente nuova verso la stessa destinazione prima di toccare la VPN. Se la sessione nuova funziona e la vecchia no, il tunnel è a posto e l’applicazione tiene una connessione morta.

Questa è la più economica delle tre verifiche e quella più spesso saltata, perché la finestra che fallisce è proprio sullo schermo. Chiudetela, riapritela e annotate se il problema sopravvive. Se la sessione nuova funziona, fermate del tutto l’indagine sul tunnel. Se fallisce anche lei, l’applicazione è un sintomo e non una causa.

Alcune applicazioni si riprendono da sole dopo un tempo di attesa, per questo il sintomo può sembrare che si sistemi da solo dopo qualche minuto. Quel comportamento indica l’applicazione e non il tunnel, e vale la pena registrarlo a parte. Un collega che dice che si è sistemato da solo sta descrivendo questo schema, non una fortuna.

Rendete il confronto riproducibile

Tenete piccole le variabili: una rete di accesso, una durata di sospensione e la stessa prima richiesta ogni volta. Poi registrate due esiti: se riconnettersi a mano lo ripara e se un’altra sospensione riporta il guasto.

È quell’ultima osservazione a separare i tre candidati nel modo più affidabile. Una sessione nuova che funziona dopo una vecchia fallita non è un problema di tunnel, e nessuna reinstallazione del client lo cambierà.

Il keepalive persistente di WireGuard entra in questo quadro solo come keepalive di mappatura NAT. Manda pacchetti per tenere aperta una mappatura; non impedisce alla macchina di sospendersi e non può continuare a inviare mentre il processo è sospeso.

Annotate nel ticket cosa avete trovato: quale delle tre cose era rotta, cosa l’ha riparata e come l’avete riprodotto. La prossima persona che aprirà un coperchio di lunedì vi ringrazierà, e la risposta non dovrà essere riscoperta da zero.