Por qué se cae tu VPN cuando cambia el Wi-Fi o se enchufa el Ethernet

Dos cosas se reportan como un solo fallo: el portátil pasó a otra red Wi-Fi, o se enchufó un cable mientras el Wi-Fi seguía activo. El cliente sigue diciendo conectado, el icono parece sano y el túnel no transporta nada. Por debajo, solo tres piezas de estado pueden moverse - el enlace, la dirección local, la ruta por defecto - y cuál se movió decide si el túnel se recupera solo o necesita reconectar. Las reviso en ese orden, porque cambiar los ajustes de la cuenta nunca ha arreglado ninguna.

Enlace, dirección y ruta se mueven por separado

La itinerancia entre puntos de acceso de la misma red suele ser un evento de L2. La radio se reasocia, la interfaz conserva su dirección y su puerta de enlace, y nada de lo que depende el túnel cambia, por eso cruzar una oficina grande a veces pasa desapercibido. Unirse a un SSID distinto no es eso: la interfaz antigua puede caerse, DHCP reparte una dirección nueva, una puerta de enlace nueva y resolutores nuevos, y el flujo exterior que usaba el túnel deja de existir.

El Ethernet añade una tercera forma. El Wi-Fi nunca cae, así que no se dispara ningún evento de enlace, pero la interfaz cableada aparece con su propia dirección y a menudo gana la ruta por defecto por métrica. El túnel sigue funcionando por un camino que ya no es preferido, o el cliente mantiene su socket clavado a la red inalámbrica en la que empezó. Desde el navegador ambos se ven igual: las páginas se atascan en el momento en que el cable encaja.

Así que la primera pregunta no es si cambió el Wi-Fi. Es si cambió la dirección a la que estás ligado, o la ruta hasta el punto final, mientras el túnel estaba activo.

El socket exterior está clavado a una dirección que acaba de desaparecer

Cada túnel es un flujo exterior: una dirección y un puerto locales que hablan con la dirección y el puerto del servidor. En Linux eso es un socket UDP ligado al origen antiguo; cuando se elimina la interfaz que tiene la dirección, los envíos o fallan con EADDRNOTAVAIL o salen por la interfaz nueva con un origen que el servidor nunca ha visto.

El lado remoto guarda su propia fijación. Una SA de IKEv2 sin MOBIKE se identifica por el par de direcciones, y una OpenVPN sesión está atada a la dirección del par que aprendió, y un mapeo NAT pertenece a la dirección privada, el puerto y la dirección pública que lo crearon. Muévete detrás de otro NAT y cada respuesta se envía a un mapeo que ya no existe. Nada en tu máquina está mal configurado; la quíntupla apunta a una red que dejaste.

Lee el estado antes de teorizar:

• ss -unp muestra la dirección y el puerto locales que cada socket de túnel tiene de verdad.
• ip route get 203.0.113.10 imprime la dirección de origen y el dispositivo que el núcleo usaría para el punto final ahora mismo.
• wg show wg0 endpoints, swanctl --list-sas o el registro del cliente muestra la dirección del par con la que el lado remoto cree que habla.

Si la dirección del socket y la consulta de ruta no coinciden, has encontrado la rotura, y ningún cambio de credenciales la tocará.

Qué hace cada protocolo con una dirección de origen nueva

Los clientes absorben el cambio en distinto grado, y la tabla es lo que comparo con la configuración del cliente en lugar de adivinar por el comportamiento de reconexión.

La regla de itinerancia de WireGuard solo funciona en una dirección: el cliente tiene que enviar primero desde la dirección nueva. Un socket aún ligado a la interfaz antigua nunca lo hace, por eso un túnel puede parecer vivo mientras su temporizador de handshake envejece. descripción del protocolo precisa la condición de actualización del punto final, y merece la pena leerla antes de cambiar una configuración.

MOBIKE se negocia, no se supone. Si el servidor no lo ofrece, el cliente debe restablecer, y eso es un hecho que confirmas desde la lista de SA o el registro y no que deduces de un indicador que gira.

La preferencia de ruta decide el camino, no el icono del Wi-Fi

Con las dos interfaces arriba, el núcleo elige por métrica y longitud de prefijo. ip route show default lista los candidatos y ip route get 203.0.113.10 resuelve la decisión real, incluida la dirección de origen. Una ruta por defecto cableada con métrica 100 y una inalámbrica con 600 significan que el punto final se mueve en el momento en que el cable asienta, mientras que cada aplicación que abrió un socket antes conserva su origen antiguo.

Windows hace lo mismo con métricas de interfaz automáticas, sesgadas por la velocidad del enlace. Get-NetRoute -DestinationPrefix 0.0.0.0/0 ordena los candidatos y Find-NetRoute -RemoteIPAddress 203.0.113.10 devuelve la interfaz y el origen que elegiría la pila. Un cliente que liga su socket exterior a una interfaz sigue usándola después de que la métrica se invierta; eso es una decisión de ligadura, no un fallo de encaminamiento.

Android hace visible la división: ConnectivityManager informa de las redes disponibles y de un valor por defecto aparte, y una aplicación VPN que liga un socket a un objeto Network mantiene esa ligadura hasta que vuelve a ligarlo. En macOS, scutil --nwi imprime la interfaz principal y el orden que usaría el sistema.

DNS, MTU e IPv6 se mueven con la conexión

Una conexión nueva trae resolutores nuevos. Con systemd-resolved el DNS es por enlace, resolvectl status muestra qué enlace responde a un nombre, y una red de invitados que reparte su propio resolutor puede dejar sin usar el DNS empujado por el túnel hasta que el enlace vuelva a ser preferido. Un portal cautivo lo empeora: la primera petición HTTPS la responde el portal en lugar del punto final, y el cliente registra un servidor muerto.

La MTU del camino también cambia. Ethernet y Wi-Fi suelen llevar 1500 bytes, PPPoE 1492, y los enlaces móviles a menudo menos. Un túnel que hereda una MTU menor se atasca en paquetes grandes mientras las peticiones pequeñas pasan, lo que se lee como una conexión medio rota. ping -M do -s 1472 203.0.113.10 envía un paquete de 1500 bytes con DF activado; el silencio significa que el camino es más pequeño de lo que supusiste.

IPv6 es la otra mitad. Una red que reparte un prefijo nuevo cambia el origen que usaría un cliente de doble pila, y un túnel solo v4 deja el tráfico v6 fuera hasta que la política se ponga al día. ip -6 route show default y ip -6 addr show responden si el enlace nuevo tiene algún camino v6.

Reproduce la transición en lugar de describirla

Elige una petición inofensiva y ejecuta los mismos tres comandos a ambos lados del cambio: ip -br addr, ip route show default, ip route get 203.0.113.10. Luego observa si el túnel sigue emitiendo paquetes - tcpdump -ni any udp port 51820 para WireGuard, el puerto correspondiente para cualquier otra cosa. Los paquetes que salen del origen antiguo significan un problema de ligadura. Los paquetes que salen del origen nuevo sin respuesta significan el lado remoto o el NAT por medio.

Anota qué evento coincidió con el primer fallo: caída del enlace, cambio de dirección o cambio de la ruta por defecto. Apuntan a responsables distintos - un cliente que debe volver a ligarse, una dirección que debe volver a obtenerse o una ruta que pertenece a un archivo de configuración y no a una regla de bypass permanente.

Antes de darlo por arreglado, confirma que el bloque de tráfico directo sigue aguantando durante el hueco y que los nombres se resuelven por la conexión nueva. Si el cliente conserva el punto final antiguo tras el cambio, arregla primero el ajuste de itinerancia o de float. Si hace la itinerancia bien y aún no recibe respuesta, mira la identidad del par en el servidor y el NAT del camino, y guarda los dos contextos de red en el informe para que la siguiente persona pueda compararlos.