Il VPN continua a disconnettersi? Procedi in questo ordine

Prima di reinstallare il client, annota tre cose: quanto è rimasto attivo il tunnel, cosa ha detto il client quando è caduto e se la macchina ha dormito o cambiato rete nel frattempo. Quella nota è l’unica prova che avrai in seguito, e la reinstallazione di solito la cancella. Una caduta a intervallo ripetibile è un timer o una scadenza di stato; una caduta in un momento casuale è un problema di percorso. L’ordine qui sotto ti evita di cambiare tre cose insieme e non imparare nulla.

Primo passo: annota l’intervallo e il testo dell’errore

Parti dal registro del client stesso invece che dalla dashboard del fornitore. Su un client Linux, il registro del servizio più lo stato vivo del tunnel coprono la maggior parte:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Annota le marche temporali dell’ultimo handshake riuscito e il momento in cui il traffico si è fermato, non solo il momento in cui l’icona ha cambiato colore. Un client GUI che dice disconnesso a posteriori potrebbe riportare uno stato raggiunto dal kernel pochi secondi prima.

Conserva la formulazione dell’errore. Un timeout, un rifiuto di autenticazione e un errore di adattatore o driver indicano tre livelli diversi, e la maggior parte dello sforzo sprecato in questo problema nasce dal trattarli come uno solo. Copia la riga alla lettera nella tua nota.

Secondo passo: cambia una variabile, non il profilo

Mantieni fissi dispositivo e profilo e sposta la macchina su un’altra rete di accesso, come un hotspot del telefono. Questo è il test più economico che separa il client dal percorso. Eseguilo abbastanza a lungo da coprire l’intervallo di guasto originale; due minuti stabili non dimostrano nulla su una caduta che avviene al trentesimo minuto.

Un portatile con porta Ethernet offre un secondo confronto che toglie del tutto il Wi-Fi dal quadro. Se il tunnel tiene su entrambe le alternative, la rete di accesso originale merita attenzione: roaming tra punti di accesso, un router domestico con la tabella di traduzione in scadenza o un collegamento a monte che azzera flussi di lunga durata.

Annota quale variabile hai cambiato. Un confronto conta solo quando tutto il resto è rimasto uguale, e questo include l’endpoint del server e l’ora del giorno.

Terzo passo: collega l’intervallo a un livello

La durata di una buona sessione è il singolo numero più informativo che hai. Leggilo rispetto a questo elenco prima di toccare i timer:

• Caduta dopo sospensione o ripresa: lo stato del tunnel ha superato la sospensione ma l’interfaccia no. Controlla il comportamento di riconnessione del client alla ripresa e se il servizio riavvia il tunnel o attende traffico.
• Caduta solo quando è inattivo: qualcosa nel mezzo ha lasciato scadere il flusso. È proprio il caso per cui esistono i keepalive.
• Caduta a un’età di sessione fissa: un evento di riautenticazione o di rinnovo della chiave, non un guasto del percorso. Un rifiuto esplicito nel registro esattamente a quell’intervallo è il segnale.
• Caduta durante trasferimenti grandi o pagine grandi: sospetta MTU e frammentazione, non un timer di inattività.

Per il caso di inattività, le impostazioni dipendono dal protocollo ed entrambe le estremità contano. Il keepalive 10 60 di OpenVPN sul server invia un ping ogni 10 secondi e riavvia il collegamento dopo 60 secondi senza; i client WireGuard dietro NAT usano PersistentKeepalive = 25 nel blocco del peer. OpenVPN rinegozia anche il canale dati con un timer, reneg-sec, che per impostazione predefinita è 3600 secondi nella versione 2.x.

Non copiare valori aggressivi dalla guida di un altro fornitore. Un timeout breve su un collegamento mobile con perdite produce proprio le disconnessioni che doveva evitare, e i valori inviati dal server prevalgono su quelli impostati nel profilo del client.

Quarto passo: confronta un’unica alternativa supportata

Se l’operatore pubblica sia un profilo UDP sia uno TCP, esegui lo stesso dispositivo e la stessa rete contro l’altro. Usa il file corrispondente reale invece di modificare il trasporto in un profilo copiato. Un profilo TCP stabile su un percorso dove l’UDP viene azzerato restringe il problema a quel percorso; non dimostra che TCP sia il trasporto migliore ovunque.

La stessa logica vale per gli endpoint. Prova un altro server e tieni il risultato originale accanto. Se solo un’uscita azzera le sessioni, è una prova su quell’endpoint, non un motivo per ricostruire ogni adattatore del portatile.

Dopo ogni modifica, ripeti il trigger originale e conferma dove va davvero il traffico. Un accesso a internet recuperato non è lo stesso risultato del traffico dentro il tunnel, e un client che è ricaduto in silenzio su una rotta diretta sembra sano dal browser.

Verifica la correzione e conserva il rollback

Una correzione si verifica riproducendo il trigger originale, non con una connessione riuscita. Lascia il tunnel inattivo oltre il vecchio intervallo di guasto, sospendi e riprendi una volta, poi controlla l’età dell’handshake e l’indirizzo di uscita:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Conserva il profilo precedente e i valori dei timer precedenti finché il nuovo comportamento non sopravvive a un’intera giornata lavorativa. Se le cadute tornano, ripristina il backup, poi riapplica le modifiche una alla volta così il secondo tentativo parte da uno stato noto.

Se il registro resta pulito e il tunnel continua a cadere a intervallo ripetibile, la prossima tappa è il lato server per quella sessione. Porta con te l’identificatore di sessione del client e l’ora esatta della caduta, perché è quella coppia a rendere ricercabile un registro del server. Le opzioni di collegamento del protocollo sono documentate nel manuale di OpenVPN 2.6 quando ti serve il significato esatto di un valore.