El VPN se reconecta al conducir: ¿cambio de radio o de IP?

La llamada se corta cuando pasas el borde del pueblo, y el icono del VPN desaparece en ese mismo instante. Es tentador registrarlo como “el cambio de torre mató el túnel”. Ocurrieron dos cosas distintas, y solo una tiene que ver con torres. Un traspaso de radio puede dejar tu dirección IP, la ruta predeterminada y la sesión completamente intactas, mientras que un cambio de dirección real romperá cualquier túnel que no pueda moverse con él. Comparar cómo tratan los clientes ese segundo caso es el ejercicio útil, porque te dice si ves un comportamiento diseñado o un fallo.

Un cambio de torre no es necesariamente un cambio de dirección

Las redes móviles mantienen viva la sesión de paquetes durante los traspasos mientras el ancla de movilidad del operador siga siendo la misma. El enlace de radio cambia, el túnel no se entera y no debería aparecer ninguna reconexión en ningún registro. Este es el caso habitual para el movimiento dentro de una ciudad.

Lo que sí cambia la dirección es un movimiento entre anclas, un cambio de Wi-Fi a móvil o un restablecimiento del túnel por parte del operador tras una pausa larga. Esos eventos sustituyen la dirección de origen que llevan tus paquetes, y un par del VPN ve un par que se ha movido.

La consecuencia práctica es que el movimiento no es una prueba. Un dispositivo que ha recorrido cuarenta kilómetros puede haber conservado una sola dirección todo el camino, y un dispositivo quieto puede haber cambiado de dirección dos veces porque la red lo decidió. Registrar el evento es la única forma de distinguir ambos casos.

Dos diseños: mover el túnel o reconstruirlo

Los clientes difieren en cuánto les importa que la fuente exterior haya cambiado. Algunos atan el túnel a la dirección sobre la que se construyó y exigen un restablecimiento completo. Otros autentican cada paquete de forma independiente y simplemente actualizan dónde envían las respuestas.

La fila superior explica muchos informes confusos. WireGuard no tiene ninguna sesión que romper: cada paquete lleva el índice del par y se autentica, así que un paquete válido que llega desde una dirección nueva es por definición de ese par, y el extremo registrado lo sigue. Un cliente que muestra “conectado” de forma continua durante un trayecto dice la verdad.

La fila inferior tampoco es un defecto. Reconstruir la sesión vuelve a ejecutar la autenticación contra la dirección actual, que es exactamente lo que quieres cuando la dirección antigua puede pertenecer ya a otra persona.

Observe el evento en lugar del movimiento

En Android, el subsistema de conectividad informa los cambios de red como eventos, y esos son los que deberías correlacionar con el comportamiento del cliente. El volcado es extenso, pero las partes relevantes son la red predeterminada y su dirección:

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

En el lado del servidor hay una medición directa para el caso de itinerancia. WireGuard guarda el último extremo autenticado por par, así que un cambio de dirección aparece como un valor cambiado en lugar de una reconexión:

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

Compare el extremo antes y después del trayecto. Si la dirección y el puerto no han cambiado, el túnel nunca tuvo que hacer nada y la reconexión vino de otro sitio, normalmente la aplicación. Si el extremo cambió mientras la marca de tiempo del handshake se mantuvo cerca de su intervalo normal de renovación de claves, el túnel se movió en lugar de reiniciarse.

Un reinicio se ve distinto: la marca de tiempo del handshake vuelve al momento de la reconexión, y el cliente registra una secuencia de inicialización en lugar de una continuación silenciosa.

Cuándo la reconexión es el comportamiento correcto

Tratar cada reconexión como un fallo lleva a configuraciones que mantienen vivas sesiones muertas. Un par cuya dirección cambió porque la red la reasignó no debería seguir recibiendo tráfico para la asignación antigua, y un cliente que continúa en silencio puede acabar enviando a un agujero negro mientras el icono sigue verde.

Compare los dos fallos desde la perspectiva del usuario. Una reconexión cuesta unos segundos y una reautenticación. Un túnel obsoleto cuesta una aplicación que se cuelga sin error, algo mucho más difícil de explicar y mucho más probable que se reporte como “internet está roto”.

Debajo se esconde además una cuestión de política. Durante el hueco entre perder una ruta y establecer otra, algunos clientes vuelven a enviar tráfico directamente. Evitarlo es un control separado de la recuperación automática, y un cliente puede ser bueno en uno y malo en el otro. Decida cuál necesita antes de ajustar cualquiera de los dos.

Anote la secuencia observada

Un informe útil nombra la fuente del evento: un cambio de red predeterminada con una dirección nueva, un cambio de Wi-Fi a móvil o un traspaso sin ningún cambio de dirección. Después indica qué hizo el cliente, con la marca de tiempo del lado del servidor en lugar de la memoria.

Si el túnel se movió, dilo y anota la nueva familia de extremos. Si se restableció, anota si la autenticación tuvo éxito al primer intento y cuánto duró el hueco. Esos tres hechos distinguen un diseño móvil sano de un cliente que va saltando entre redes.

Y evite la frase “cambio de torre” a menos que el registro del dispositivo lo establezca de verdad. La documentación de conectividad de Android describe las devoluciones de llamada que distinguen la disponibilidad de un cambio de red predeterminada, y esa distinción es la que necesita tu informe. Todo lo demás es una historia sobre conducir.