El VPN es reconnecta mentre condueixes: canvi de ràdio o canvi d’IP?

La trucada cau quan passes pel costat del poble, i la icona del VPN desapareix en el mateix moment. És temptador enregistrar-ho com “el canvi de torre de mòbil va matar el túnel”. Van passar dues coses diferents, i només una té a veure amb torres. Un traspàs de ràdio pot deixar la teva adreça IP, la ruta per defecte i la sessió completament intactes, mentre que un canvi d’adreça real trencarà qualsevol túnel que no pugui moure’s amb ell. Comparar com gestionen els clients aquest segon cas és l’exercici útil, perquè et diu si veus un comportament dissenyat o un error.

Un canvi de torre no és necessàriament un canvi d’adreça

Les xarxes mòbils mantenen viva la sessió de paquets durant els traspassos mentre l’àncora de mobilitat de l’operador sigui la mateixa. L’enllaç de ràdio canvia, el túnel no se n’adona i no hauria d’aparèixer cap reconnexió en cap registre. Aquest és el cas ordinari per al moviment dins d’una ciutat.

El que sí que canvia l’adreça és un moviment entre àncores, un canvi de Wi-Fi a mòbil o un restabliment del túnel per part de l’operador després d’una pausa llarga. Aquests esdeveniments substitueixen l’adreça d’origen que porten els teus paquets, i un parell del VPN veu un parell que s’ha mogut.

La conseqüència pràctica és que el moviment no és una prova. Un dispositiu que ha recorregut quaranta quilòmetres pot haver mantingut una sola adreça tot el camí, i un dispositiu quiet pot haver canviat d’adreça dues vegades perquè la xarxa ho va decidir. Enregistrar l’esdeveniment és l’única manera de distingir-ho.

Dos dissenys: moure el túnel o reconstruir-lo

Els clients difereixen en quant els importa que la font exterior hagi canviat. Alguns lliguen el túnel a l’adreça sobre la qual es va construir i requereixen un restabliment complet. Altres autentiquen cada paquet de manera independent i simplement actualitzen on envien les respostes.

La fila de dalt explica molts informes confusos. WireGuard no té cap sessió per trencar: cada paquet porta l’índex del parell i s’autentica, així que un paquet vàlid que arriba d’una adreça nova és per definició d’aquell parell, i l’extrem enregistrat el segueix. Un client que mostra “connectat” de manera contínua durant un trajecte diu la veritat.

La fila de baix tampoc no és cap defecte. Reconstruir la sessió torna a executar l’autenticació contra l’adreça actual, que és exactament el que vols quan l’adreça antiga pot pertànyer ara a una altra persona.

Observeu l’esdeveniment en lloc del moviment

A Android, el subsistema de connectivitat informa els canvis de xarxa com a esdeveniments, i són aquests els que hauries de correlacionar amb el comportament del client. L’abocament és verbós, però les parts rellevants són la xarxa per defecte i la seva adreça:

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

Al costat del servidor hi ha una mesura directa per al cas d’itinerància. WireGuard desa l’últim extrem autenticat per parell, així que un canvi d’adreça apareix com un valor canviat en lloc d’una reconnexió:

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

Compareu l’extrem abans i després del trajecte. Si l’adreça i el port no han canviat, el túnel no havia de fer res i la reconnexió va venir d’un altre lloc, normalment l’aplicació. Si l’extrem ha canviat mentre la marca de temps de l’encaixada de mans s’ha mantingut a prop del seu interval normal de renegociació, el túnel s’ha mogut en lloc de reiniciar-se.

Un reinici es veu diferent: la marca de temps de l’encaixada de mans es reinicia al moment de la reconnexió, i el client registra una seqüència d’inicialització en lloc d’una continuació silenciosa.

Quan la reconnexió és el comportament correcte

Tractar cada reconnexió com una fallada porta a configuracions que mantenen vives sessions mortes. Un parell l’adreça del qual ha canviat perquè la xarxa l’ha reassignada no hauria de continuar rebent trànsit per al mapatge antic, i un client que continua en silenci pot acabar enviant a un forat negre mentre la icona es manté verda.

Compareu les dues fallades des de la perspectiva de l’usuari. Una reconnexió costa uns quants segons i una reautenticació. Un túnel obsolet costa una aplicació que es penja sense error, cosa molt més difícil d’explicar i molt més probable que es reporti com “internet s’ha espatllat”.

També hi ha una qüestió de política amagada a sota. Durant el buit entre perdre un camí i establir-ne un altre, alguns clients tornen a enviar trànsit directament. Evitar-ho és un control separat de la recuperació automàtica, i un client pot ser bo en un i dolent en l’altre. Decidiu quin necessiteu abans d’ajustar cap dels dos.

Anoteu la seqüència observada

Un informe útil nomena la font de l’esdeveniment: un canvi de xarxa per defecte amb una adreça nova, un canvi de Wi-Fi a mòbil o un traspàs sense cap canvi d’adreça. Després diu què va fer el client, amb la marca de temps del costat del servidor en lloc de la memòria.

Si el túnel s’ha mogut, digueu-ho i anoteu la nova família d’extrems. Si s’ha restablert, anoteu si l’autenticació va tenir èxit al primer intent i quant va durar el buit. Aquests tres fets distingeixen un disseny mòbil saludable d’un client que va sacsejant entre xarxes.

I eviteu la frase “canvi de torre” tret que el registre del dispositiu ho estableixi de veritat. La documentació de connectivitat d’Android descriu les devolucions de trucada que distingeixen la disponibilitat d’un canvi de xarxa per defecte, i aquesta distinció és la que necessita el teu informe. La resta és una història sobre conduir.