La IP WAN cambió y el túnel cayó: las comprobaciones en orden

El túnel cae, el router registra una reconexión y nada en la LAN se ha movido. Una dirección WAN nueva invalida la conexión exterior sin cambiar nada dentro: la dirección de origen del cliente ha cambiado, el estado NAT antiguo apunta a un origen que ya no existe y el par remoto puede seguir enviando a la dirección anterior. La recuperación es un comportamiento normal, y la pregunta útil es qué estado no se actualizó.

Nombre el evento antes de leer el registro

Compruebe qué ocurrió realmente en la capa de acceso. Una renovación del arrendamiento del ISP es un evento. Una sesión PPPoE que se ha reconectado es otro. Un módem de fibra que se reinició, o una conmutación por error de WAN de un enlace a otro, cambia la dirección exterior o su ruta de una tercera manera. No son el mismo evento y no dejan el mismo residuo.

Una línea de reconexión en el registro del VPN tampoco es prueba de un cambio de WAN. Un tiempo de espera por inactividad, un intervalo de reautenticación y la detección de par muerto producen reconexiones sin ningún cambio de dirección. Compare las marcas de tiempo del registro de acceso con el registro del VPN antes de concluir algo, y mantenga la ventana de comparación lo bastante amplia para atrapar un cambio que ocurrió durante la noche.

El roaming y la reconexión son protocolos distintos

WireGuard tiene roaming autenticado integrado en el protocolo: cuando un par recibe un paquete autenticado correctamente desde una dirección de origen nueva, actualiza el punto final de ese par. El inicio rápido de WireGuard describe la configuración del par que hace posible esto, y por eso un cliente en una dirección cambiante a menudo se recupera sin un reinicio visible.

OpenVPN se comporta de forma distinta por defecto. Una sesión UDP puede terminar y reconectarse, y el comportamiento opcional float permite que un par autenticado continúe desde una dirección nueva donde la configuración lo permite. Los túneles basados en TCP son más estrictos, porque la conexión misma está ligada al par de direcciones. Esa diferencia decide si la recuperación parece invisible o se anuncia en el registro cada vez.

Ninguno de los dos comportamientos dice nada sobre las aplicaciones de dentro. Un túnel recuperado no restaura una sesión TCP que el par ya consideraba muerta.

Estado que el túnel no posee

El estado de traducción y de enrutamiento sobrevive a la reconexión de maneras que sorprenden. Una entrada de conntrack creada para el origen antiguo mantiene la ruta de respuesta anclada a una dirección que ya no existe, y caduca según su propio calendario, no cuando el túnel volvió. Reiniciar el servicio del túnel no acorta esa espera, así que un enlace reparado todavía puede parecer roto durante un tiempo.

Las rutas y las reglas de política pueden referenciar la puerta de enlace o la interfaz antiguas. Un conjunto de reglas que era correcto antes de un cambio de WAN puede apuntar a un dispositivo que ahora está caído, lo que produce un túnel que informa que está conectado y un tráfico que no va a ninguna parte. El DNS dinámico para un servidor que aloja es un problema distinto del de un cliente que obtiene un origen nuevo. El registro debe actualizarse para que los clientes remotos lo encuentren, y ninguna configuración del lado del cliente compensa una dirección que la traducción aguas arriba no reenviará.

Ordene las comprobaciones de fuera hacia dentro

El orden siguiente va de la conexión exterior hacia dentro, y detenerse en el primer paso que falla es lo que lo hace útil: cada pasada descarta la capa de encima. Mantenga ese orden incluso cuando la avería parezca obvia.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

El primer comando muestra el punto final actual y la antigüedad del handshake de cada par. El segundo y el tercero muestran si la interfaz exterior y la ruta al punto final siguen teniendo sentido. El recuento de conntrack es una comprobación burda del estado que queda de la dirección anterior, y el registro del sistema es donde se anota el motivo de la reconexión.

Después pruebe desde un cliente de la LAN en lugar de desde el router. Un ping originado por el propio router usa una ruta distinta del tráfico reenviado, así que un ping correcto desde el router demuestra que el túnel existe y nada sobre la accesibilidad del cliente.

Decida el comportamiento esperado y anótelo

Reconectarse es el comportamiento correcto para la mayoría de los despliegues, así que el objetivo no es impedirlo. Decida en cambio qué debe pasar con el tráfico durante el hueco: detenerlo, retenerlo o pasar a otra ruta. Esa decisión pertenece al cortafuegos y a la política de enrutamiento, no al perfil del VPN.

Registre los eventos de acceso y las horas de reconexión juntos durante una semana. Los cambios repetidos sin un evento de acceso correspondiente apuntan al servicio de acceso, y sustituir el perfil del VPN no arreglará un enlace que no deja de renegociar. Un solo par de entradas en el mismo minuto resuelve la cuestión para ese incidente y da una línea base al siguiente.