Perché la tua VPN cade quando il Wi-Fi cambia o si collega l’Ethernet

Due cose vengono segnalate come un unico guasto: il portatile è passato a un’altra rete Wi-Fi, oppure è stato collegato un cavo mentre il Wi-Fi restava attivo. Il client dice ancora connesso, l’icona sembra sana e il tunnel non trasporta nulla. Sotto, solo tre pezzi di stato possono muoversi - il collegamento, l’indirizzo locale, la rotta predefinita - e quale si è mosso decide se il tunnel si riprende da solo o richiede una riconnessione. Li controllo in quest’ordine, perché cambiare le impostazioni dell’account non ne ha mai sistemato nessuno.

Collegamento, indirizzo e rotta si muovono in modo indipendente

Il roaming tra punti di accesso della stessa rete è di solito un evento di livello 2. La radio si riassocia, l’interfaccia conserva indirizzo e gateway, e nulla da cui dipende il tunnel cambia, per questo attraversare un grande ufficio a volte passa inosservato. Unirsi a un altro SSID non è questo: la vecchia interfaccia può cadere, il DHCP assegna un nuovo indirizzo, un nuovo gateway e nuovi resolver, e il flusso esterno che il tunnel usava smette di esistere.

L’Ethernet aggiunge una terza forma. Il Wi-Fi non cade mai, quindi nessun evento di collegamento scatta, ma l’interfaccia cablata compare con un proprio indirizzo e spesso vince la rotta predefinita sulla metrica. Il tunnel continua su un percorso che non è più preferito, oppure il client tiene il socket ancorato alla rete senza fili da cui è partito. Dal browser entrambi sembrano uguali: le pagine si bloccano nell’istante in cui il cavo si inserisce.

Quindi la prima domanda non è se il Wi-Fi è cambiato. È se è cambiato l’indirizzo a cui sei legato, o la rotta verso l’endpoint, mentre il tunnel era attivo.

Il socket esterno è ancorato a un indirizzo appena scomparso

Ogni tunnel è un flusso esterno: un indirizzo e una porta locali che parlano con l’indirizzo e la porta del server. Su Linux è un socket UDP legato alla vecchia origine; quando l’interfaccia che detiene l’indirizzo viene rimossa, gli invii falliscono con EADDRNOTAVAIL oppure escono dalla nuova interfaccia con un’origine che il server non ha mai visto.

Il lato remoto conserva il proprio ancoraggio. Una SA IKEv2 senza MOBIKE è identificata dalla coppia di indirizzi, e una OpenVPN sessione è legata all’indirizzo del peer che ha appreso, e una mappatura NAT appartiene all’indirizzo privato, alla porta e all’indirizzo pubblico che l’hanno creata. Spostati dietro un altro NAT e ogni risposta va a una mappatura che non esiste più. Nulla sulla tua macchina è configurato male; la quintupla punta a una rete che hai lasciato.

Leggi lo stato prima di teorizzare:

• ss -unp mostra l’indirizzo e la porta locali che ogni socket del tunnel tiene davvero.
• ip route get 203.0.113.10 stampa l’indirizzo di origine e il dispositivo che il kernel userebbe ora per l’endpoint.
• wg show wg0 endpoints, swanctl --list-sas oppure il log del client mostra l’indirizzo del peer con cui il lato remoto crede di parlare.

Se l’indirizzo del socket e la ricerca della rotta non concordano, hai trovato la rottura, e nessun cambio di credenziali la toccherà.

Che cosa fa ogni protocollo con un nuovo indirizzo di origine

I client assorbono il cambiamento in misura diversa, e la tabella è ciò con cui confronto la configurazione del client invece di indovinare dal comportamento di riconnessione.

La regola di roaming di WireGuard funziona solo in una direzione: il client deve inviare per primo dal nuovo indirizzo. Un socket ancora legato alla vecchia interfaccia non lo fa mai, per questo un tunnel può sembrare vivo mentre il suo timer di handshake invecchia. descrizione del protocollo stabilisce con precisione la condizione di aggiornamento dell’endpoint, e vale la pena leggerla prima di cambiare una configurazione.

MOBIKE si negozia, non si presume. Se il server non lo offre, il client deve ristabilire, e questo è un fatto che confermi dall’elenco delle SA o dal log, non che deduci da un indicatore che gira.

La preferenza di rotta decide il percorso, non l’icona del Wi-Fi

Con entrambe le interfacce attive, il kernel sceglie per metrica e lunghezza del prefisso. ip route show default elenca i candidati e ip route get 203.0.113.10 risolve la decisione reale, compreso l’indirizzo di origine. Una rotta predefinita cablata con metrica 100 e una senza fili con 600 significano che l’endpoint si sposta nell’istante in cui il cavo si assesta, mentre ogni applicazione che ha aperto un socket prima conserva la sua vecchia origine.

Windows fa lo stesso con metriche di interfaccia automatiche, influenzate dalla velocità del collegamento. Get-NetRoute -DestinationPrefix 0.0.0.0/0 ordina i candidati e Find-NetRoute -RemoteIPAddress 203.0.113.10 restituisce l’interfaccia e l’origine che sceglierebbe lo stack. Un client che lega il suo socket esterno a una sola interfaccia continua a usarla dopo che la metrica si ribalta; è una decisione di binding, non un guasto di routing.

Android rende visibile la separazione: ConnectivityManager segnala le reti disponibili e un valore predefinito separato, e un’app VPN che lega un socket a un oggetto Network mantiene quel legame finché non lo rifà. Su macOS, scutil --nwi stampa l’interfaccia primaria e l’ordine che il sistema userebbe.

DNS, MTU e IPv6 si spostano con l’attacco

Un nuovo attacco porta nuovi resolver. Con systemd-resolved il DNS è per collegamento, resolvectl status mostra quale collegamento risponde a un nome, e una rete ospiti che distribuisce il proprio resolver può lasciare inutilizzato il DNS spinto dal tunnel finché il collegamento non torna preferito. Un portale captive peggiora le cose: la prima richiesta HTTPS la risponde il portale invece dell’endpoint, e il client registra un server morto.

Anche l’MTU del percorso cambia. Ethernet e Wi-Fi portano di solito 1500 byte, PPPoE 1492, e i collegamenti mobili spesso meno. Un tunnel che eredita un MTU più piccolo si blocca sui pacchetti grandi mentre le richieste piccole passano, cosa che si legge come una connessione mezzo rotta. ping -M do -s 1472 203.0.113.10 invia un pacchetto da 1500 byte con DF impostato; il silenzio significa che il percorso è più piccolo di quanto supponessi.

IPv6 è l’altra metà. Una rete che distribuisce un nuovo prefisso cambia l’origine che userebbe un client dual-stack, e un tunnel solo v4 lascia il traffico v6 fuori finché la policy non si adegua. ip -6 route show default e ip -6 addr show rispondono se il nuovo collegamento ha un percorso v6.

Riproduci la transizione invece di descriverla

Scegli una richiesta innocua ed esegui gli stessi tre comandi da entrambi i lati del cambiamento: ip -br addr, ip route show default, ip route get 203.0.113.10. Poi osserva se il tunnel emette ancora pacchetti - tcpdump -ni any udp port 51820 per WireGuard, la porta corrispondente per qualsiasi altra cosa. I pacchetti che escono dalla vecchia origine indicano un problema di binding. I pacchetti dalla nuova origine senza risposta indicano il lato remoto o il NAT in mezzo.

Annota quale evento ha coinciso con il primo guasto: caduta del collegamento, cambio di indirizzo o cambio della rotta predefinita. Puntano a responsabili diversi - un client che deve rilegarsi, un indirizzo che deve essere riottenuto, o una rotta che appartiene a un file di configurazione e non a una regola di bypass permanente.

Prima di dichiararlo risolto, conferma che il blocco del traffico diretto tenga ancora durante il vuoto e che i nomi si risolvano attraverso il nuovo attacco. Se il client conserva il vecchio endpoint dopo il passaggio, sistema prima l’impostazione di roaming o di float. Se fa roaming correttamente e ancora non riceve risposta, guarda l’identità del peer sul server e il NAT sul percorso, e tieni entrambi i contesti di rete nel resoconto perché la persona successiva possa confrontarli.