Il VPN si riconnette guidando: cambio di radio o cambio di IP?

La chiamata cade quando superi il bordo della città, e l’icona VPN scompare nello stesso istante. È allettante annotarlo come «il cambio di antenna ha ucciso il tunnel». Sono successe due cose diverse, e solo una riguarda le antenne. Un passaggio radio può lasciare il tuo indirizzo IP, la route predefinita e la sessione del tutto intatti, mentre un vero cambio di indirizzo spezzerà qualsiasi tunnel che non riesca a seguirlo. Confrontare come i client trattano quel secondo caso è l’esercizio utile, perché ti dice se stai vedendo un comportamento progettato o un bug.

Un cambio di antenna non è necessariamente un cambio di indirizzo

Le reti mobili mantengono viva la sessione a pacchetti durante i passaggi finché l’ancora di mobilità dell’operatore resta la stessa. Il collegamento radio cambia, il tunnel non se ne accorge e nessuna riconnessione dovrebbe comparire in alcun log. È il caso ordinario per gli spostamenti dentro una città.

Ciò che cambia l’indirizzo è uno spostamento tra ancore, un passaggio da Wi-Fi a cellulare o un ristabilimento del tunnel lato operatore dopo una lunga pausa. Questi eventi sostituiscono l’indirizzo di origine che i tuoi pacchetti portano, e un peer VPN vede un peer che si è spostato.

La conseguenza pratica è che lo spostamento non è una prova. Un dispositivo che ha percorso quaranta chilometri può aver mantenuto un solo indirizzo per tutta la strada, e un dispositivo fermo può aver cambiato indirizzo due volte perché la rete ha deciso così. Registrare l’evento è l’unico modo per distinguerli.

Due progetti: spostare il tunnel o ricostruirlo

I client differiscono in quanto importa loro che la fonte esterna sia cambiata. Alcuni legano il tunnel all’indirizzo su cui è stato costruito e richiedono un ristabilimento completo. Altri autenticano ogni pacchetto in modo indipendente e si limitano ad aggiornare dove inviano le risposte.

La riga in alto spiega molti rapporti confusi. WireGuard non ha alcuna sessione da rompere: ogni pacchetto porta l’indice del peer ed è autenticato, quindi un pacchetto valido che arriva da un nuovo indirizzo è per definizione di quel peer, e l’estremità registrata lo segue. Un client che mostra «connesso» in modo continuo durante un viaggio dice la verità.

Anche la riga in basso non è un difetto. Ricostruire la sessione riesegue l’autenticazione sull’indirizzo attuale, che è esattamente ciò che vuoi quando il vecchio indirizzo ora può appartenere a qualcun altro.

Osservate l’evento invece dello spostamento

Su Android il sottosistema di connettività segnala i cambi di rete come eventi, e sono quelli che dovresti correlare con il comportamento del client. Il dump è prolisso, ma le parti rilevanti sono la rete predefinita e il suo indirizzo:

adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40

Lato server esiste una misura diretta per il caso del roaming. WireGuard memorizza l’ultima estremità autenticata per ogni peer, quindi un cambio di indirizzo appare come un valore modificato invece che come una riconnessione:

sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes

Confrontate l’estremità prima e dopo il viaggio. Se indirizzo e porta sono invariati, il tunnel non ha mai dovuto fare nulla e la riconnessione è arrivata da altrove, di solito l’applicazione. Se l’estremità è cambiata mentre il timestamp dell’handshake restava vicino al suo intervallo normale di rinnovo della chiave, il tunnel si è spostato invece di riavviarsi.

Un riavvio appare diverso: il timestamp dell’handshake torna al momento della riconnessione, e il client registra una sequenza di inizializzazione invece di una continuazione silenziosa.

Quando la riconnessione è il comportamento corretto

Trattare ogni riconnessione come un guasto porta a configurazioni che tengono in vita sessioni morte. Un peer il cui indirizzo è cambiato perché la rete lo ha riassegnato non dovrebbe continuare a ricevere traffico per la vecchia mappatura, e un client che continua in silenzio può finire per inviare in un buco nero mentre l’icona resta verde.

Confrontate i due guasti dal punto di vista dell’utente. Una riconnessione costa qualche secondo e una nuova autenticazione. Un tunnel obsoleto costa un’applicazione che si blocca senza errore, cosa molto più difficile da spiegare e molto più probabile che venga segnalata come «internet è rotto».

Sotto si nasconde anche una questione di politica. Durante il divario tra la perdita di un percorso e la creazione di un altro, alcuni client tornano a inviare traffico direttamente. Impedirlo è un controllo separato dal ripristino automatico, e un client può essere bravo in uno e scarso nell’altro. Decidete di cosa avete bisogno prima di regolare l’uno o l’altro.

Annotate la sequenza osservata

Un rapporto utile nomina la fonte dell’evento: un cambio di rete predefinita con un nuovo indirizzo, un passaggio da Wi-Fi a cellulare, o un trasferimento senza alcun cambio di indirizzo. Poi indica cosa ha fatto il client, con il timestamp dal lato server invece che dalla memoria.

Se il tunnel si è spostato, ditelo e annotate la nuova famiglia di estremità. Se si è ristabilito, annotate se l’autenticazione è riuscita al primo tentativo e quanto è durato il divario. Questi tre fatti distinguono un progetto mobile sano da un client che oscilla tra reti.

Ed evitate l’espressione «cambio di antenna» a meno che il log del dispositivo lo stabilisca davvero. La documentazione Android sulla connettività descrive le callback che distinguono la disponibilità da un cambio di rete predefinita, e quella distinzione è ciò di cui ha bisogno il tuo rapporto. Tutto il resto è una storia di guida.