WireGuard fallisce dopo l’inattività: verifica prima la direzione

Quattro domande precedono ogni modifica delle impostazioni: la stessa risorsa funziona mentre il client è attivo, quanto è durato il periodo di inattività, il dispositivo si è addormentato o ha cambiato rete, e il guasto compare solo nel traffico avviato dal lato opposto. Le risposte separano una mappatura NAT scaduta da una radio addormentata e da un’app obsoleta. Dicono anche se un keepalive è persino pertinente. Inizia dalla direzione, perché costa un comando ed elimina metà delle cause possibili.

Quale direzione fallisce?

Una nuova richiesta in uscita del client e il traffico che arriva verso di esso dopo un periodo di quiete mettono alla prova in modo diverso le apparecchiature con stato. I pacchetti in uscita ricostruiscono una mappatura mentre escono, mentre i pacchetti in entrata hanno bisogno che la vecchia mappatura sia sopravvissuta. Questa asimmetria è l’intero test. Se il client riesce a uscire ma non entra nulla, la mappatura è probabilmente scaduta, e se non funziona nessuna delle due, il tunnel o l’accesso di rete del client è sparito.

Annota quanto è durato il periodo di quiete e se il dispositivo si è addormentato o è passato a un’altra rete nel frattempo. Questi due fatti cambiano la diagnosi prima di qualsiasi impostazione.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Esegui quei tre comandi prima e dopo il periodo di quiete, perché ciascuno risponde a una parte diversa della domanda. Un timestamp di handshake che non si è mosso dice che le parti hanno smesso di parlarsi, mentre un endpoint che è cambiato dice che la mappatura si è spostata invece di morire. I contatori di trasferimento mostrano se è arrivato qualcosa, ed è la differenza tra una mappatura obsoleta e un’app silenziosa. Annota i numeri in entrambi i punti, perché il confronto è la prova.

Sonno, radio e stato dell’app

Su un telefono o un portatile, un dispositivo addormentato può aver perso del tutto l’accesso alla rete, e un keepalive non può ripristinare una radio spenta né completare un portale captive che non è stato soddisfatto. Le piattaforme mobili sospendono il lavoro in background per politica, quindi se il traffico periodico continua dipende dalla piattaforma e da ciò che l’app ha negoziato con essa. Una connessione in cache è il terzo caso e il più ingannevole, perché il ritorno del tunnel non è lo stesso della riconnessione dell’app a esso.

Riapri l’app dopo il periodo di inattività invece di fidarti della scheda rimasta aperta. Se una nuova richiesta riesce dove la vecchia sessione ha fallito, il tunnel non è mai stato il problema.

Che cosa fa davvero un keepalive

PersistentKeepalive invia periodicamente un pacchetto vuoto autenticato a un peer, il che basta a mantenere viva una mappatura NAT tra peer e a mantenere aggiornato l’endpoint del peer, come descrive l’avvio rapido di WireGuard. Non ripara una radio addormentata, una rotta persa o un’app che non riprova mai. Scegli l’intervallo tramite le impostazioni client supportate e non attivare un valore aggressivo ovunque solo perché un indicatore di stato tace.

La maggior parte dei periodi di inattività non sono guasti. Un tunnel che si riconnette dopo cinque minuti di silenzio si comporta correttamente, e il problema è solo il caso in cui qualcosa doveva arrivare dal lato opposto.

Attendi l’intervallo che prima falliva

Fai una modifica supportata, poi lascia passare lo stesso periodo di inattività prima di testare di nuovo quella risorsa. Aspettare fa parte del test e non è una formalità. Il successo immediato dopo una riconnessione non dice nulla su un sintomo di inattività prolungata, perché la riconnessione è esattamente l’evento che azzera lo stato. Se il problema compare anche durante l’uso attivo, torna ai controlli di handshake e percorso dati invece di aggiungere altro traffico periodico.

Mantieni una modifica per test e annota la durata di inattività usata. Senza questo, ogni confronto successivo deriva e nessuno può dire quale modifica contasse. Registra i quattro fatti insieme: direzione, durata, stato di sonno e comportamento dell’app.