VPN bloccata dopo il riavvio del router: tre cose che sono cambiate

Il router completa l'avvio, il portatile si riunisce allo stesso SSID e la VPN resta su connesso senza che nulla si muova. Il profilo salvato è intatto. Ciò che è scaduto sotto era il percorso, e il client tiene ancora lo stato che aveva costruito per quello vecchio.

Tre condizioni decidono la correzione. Controllale in ordine, perché le successive sono fatica sprecata se la prima spiega già lo stallo.

Prima condizione: l'indirizzo locale è cambiato

Un riavvio può assegnare alla macchina un indirizzo diverso. Allora una VPN configurata con un endpoint locale fisso continua a usare un allegato che non esiste più. Vale lo stesso per un client che ha legato il proprio socket al vecchio indirizzo. L'interfaccia del tunnel può restare attiva mentre ogni pacchetto che produce finisce in un posto inutile.

Confronta l'indirizzo usato dal client con quello che l'interfaccia ha adesso. Una rotta predefinita che punta a un gateway cambiato anch'esso è la stessa classe di problema con un altro nome.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Seconda condizione: la mappatura tradotta è sparita

I router domestici traducono i flussi in uscita, e quelle mappature vivono in memoria. Un riavvio cancella ognuna di esse. È innocuo per una nuova connessione e fatale per un tunnel che crede che il suo flusso esistente sia ancora valido. Allora l'altro lato non vede nulla, così il client non riceve mai un errore su cui poter agire.

Qui è dove un tunnel senza keepalive si blocca in silenzio invece di fallire rumorosamente. Le limitazioni documentate di WireGuard descrivono la stessa forma di guasto. Uno stato dell'endpoint sbagliato produce pacchetti scartati invece di una diagnosi.

Un keepalive persistente di 25 secondi è la mitigazione consueta, perché aggiorna la mappatura prima che un timeout di inattività possa scadere. Non ripara una mappatura già sparita. Abbina il keepalive alla logica di riconnessione invece di trattarlo come una correzione.

Terza condizione: l'indirizzo pubblico è cambiato

Se l'indirizzo esterno del router stesso è cambiato, qualunque cosa dall'altra parte che filtri per indirizzo di origine ora vede un peer diverso. Il tunnel può salire e il server può comunque scartare il traffico, cosa che sembra un client guasto ed è in realtà una politica dall'altro capo.

Annota l'indirizzo esterno prima e dopo il riavvio. Quando i due differiscono, la domanda passa dal client a chi mantiene la lista di autorizzazione, e reimpostare le credenziali sul portatile non può aiutare.

Recupera nell'ordine giusto

Completa prima qualsiasi accesso obbligatorio al portale captive, poi lascia che il client si riconnetta con la sua procedura supportata invece di uccidere il processo. Osserva se tornano sia l'identità sia il traffico dati, perché sono due fasi diverse della stessa connessione.

Una pagina nella cache non dimostra nulla, né lo fa un'app di messaggistica che si è riconnessa da sola. Prova l'endpoint che ti interessa davvero con una richiesta nuova. Mantieni la politica del traffico diretto durante l'interruzione, perché un tentativo di riconnessione non è un blocco.

Quando questo si ripete dopo ogni riavvio, il registro conta più del tentativo. Annota l'indirizzo locale, il gateway, l'indirizzo esterno e lo stato del client prima e dopo, poi confronta le due colonne. Questo trasforma un reclamo vago in un bug del ciclo di vita che qualcuno può correggere, e ferma la terza sostituzione dei certificati a causa di un timeout della mappatura.