O VPN reconéctase ao conducir: cambio de radio ou de IP?

A chamada córtase cando pasas o bordo da vila, e a icona do VPN desaparece nese mesmo instante. É tentador rexistralo como “o cambio de torre matou o túnel”. Ocorreron dúas cousas distintas, e só unha ten que ver con torres. Un traspaso de radio pode deixar o teu enderezo IP, a ruta predeterminada e a sesión completamente intactos, mentres que un cambio de enderezo real romperá calquera túnel que non poida moverse con el. Comparar como tratan os clientes ese segundo caso é o exercicio útil, porque che di se ves un comportamento deseñado ou un fallo.

Un cambio de torre non é necesariamente un cambio de enderezo

As redes móbiles manteñen viva a sesión de paquetes durante os traspasos mentres a áncora de mobilidade do operador siga a ser a mesma. A ligazón de radio cambia, o túnel non se decata e non debería aparecer ningunha reconexión en ningún rexistro. Este é o caso habitual para o movemento dentro dunha cidade.

O que si cambia o enderezo é un movemento entre áncoras, un cambio de Wi-Fi a móbil ou un restablecemento do túnel por parte do operador tras unha pausa longa. Eses eventos substitúen o enderezo de orixe que levan os teus paquetes, e un par do VPN ve un par que se moveu.

A consecuencia práctica é que o movemento non é unha proba. Un dispositivo que percorreu corenta quilómetros pode ter mantido un só enderezo todo o camiño, e un dispositivo quieto pode ter cambiado de enderezo dúas veces porque a rede así o decidiu. Rexistrar o evento é a única forma de distinguilos.

Dous deseños: mover o túnel ou reconstruílo

Os clientes difiren en canto lles importa que a fonte exterior cambiase. Algúns atan o túnel ao enderezo sobre o que se construíu e esixen un restablecemento completo. Outros autentican cada paquete de forma independente e simplemente actualizan onde envían as respostas.

A fila superior explica moitos informes confusos. WireGuard non ten ningunha sesión que romper: cada paquete leva o índice do par e autentícase, así que un paquete válido que chega desde un enderezo novo é por definición dese par, e o extremo rexistrado séguello. Un cliente que mostra “conectado” de forma continua durante un traxecto di a verdade.

A fila inferior tampouco é un defecto. Reconstruír a sesión volve executar a autenticación contra o enderezo actual, que é exactamente o que queres cando o enderezo antigo pode pertencer xa a outra persoa.

Observe o evento en lugar do movemento

En Android, o subsistema de conectividade informa os cambios de rede como eventos, e son eses os que deberías correlacionar co comportamento do cliente. O volcado é extenso, pero as partes relevantes son a rede predeterminada e o seu enderezo:

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

No lado do servidor hai unha medición directa para o caso de itinerancia. WireGuard garda o último extremo autenticado por par, así que un cambio de enderezo aparece como un valor cambiado en lugar dunha reconexión:

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

Compare o extremo antes e despois do traxecto. Se o enderezo e o porto non cambiaron, o túnel nunca tivo que facer nada e a reconexión veu doutro sitio, normalmente a aplicación. Se o extremo cambiou mentres a marca de tempo do handshake se mantivo preto do seu intervalo normal de renovación de claves, o túnel moveuse en lugar de reiniciarse.

Un reinicio vese distinto: a marca de tempo do handshake volve ao momento da reconexión, e o cliente rexistra unha secuencia de inicialización en lugar dunha continuación silenciosa.

Cando a reconexión é o comportamento correcto

Tratar cada reconexión como un fallo leva a configuracións que manteñen vivas sesións mortas. Un par cuxo enderezo cambiou porque a rede o reasignou non debería seguir recibindo tráfico para a asignación antiga, e un cliente que continúa en silencio pode acabar enviando a un burato negro mentres a icona segue verde.

Compare os dous fallos desde a perspectiva do usuario. Unha reconexión custa uns segundos e unha reautenticación. Un túnel obsoleto custa unha aplicación que se colga sen erro, algo moito máis difícil de explicar e moito máis probable que se informe como “internet está roto”.

Debaixo escóndese ademais unha cuestión de política. Durante o oco entre perder unha ruta e establecer outra, algúns clientes volven enviar tráfico directamente. Evitalo é un control separado da recuperación automática, e un cliente pode ser bo nun e malo no outro. Decida cal necesita antes de axustar calquera dos dous.

Anote a secuencia observada

Un informe útil nomea a fonte do evento: un cambio de rede predeterminada cun enderezo novo, un cambio de Wi-Fi a móbil ou un traspaso sen ningún cambio de enderezo. Despois indica que fixo o cliente, coa marca de tempo do lado do servidor en lugar da memoria.

Se o túnel se moveu, dígao e anote a nova familia de extremos. Se se restableceu, anote se a autenticación tivo éxito ao primeiro intento e canto durou o oco. Eses tres feitos distinguen un deseño móbil san dun cliente que vai saltando entre redes.

E evite a frase “cambio de torre” a menos que o rexistro do dispositivo o estableza de verdade. A documentación de conectividade de Android describe as devolucións de chamada que distinguen a dispoñibilidade dun cambio de rede predeterminada, e esa distinción é a que necesita o teu informe. Todo o demais é unha historia sobre conducir.