VPN atascada tras reiniciar el router: tres cosas que cambiaron

El router termina de arrancar, el portátil se vuelve a unir al mismo SSID y la VPN se queda en conectada sin que nada se mueva. El perfil guardado está intacto. Lo que caducó por debajo fue la ruta, y el cliente sigue conservando el estado que construyó para la anterior.

Tres condiciones deciden la solución. Compruébalas en orden, porque las posteriores son esfuerzo perdido si la primera ya explica el atasco.

Primera condición: la dirección local ha cambiado

Un reinicio puede asignar al equipo una dirección distinta. Entonces una VPN configurada con un punto final local fijo sigue usando un enlace que ya no existe. Lo mismo ocurre con un cliente que vinculó su socket a la dirección antigua. La interfaz del túnel puede seguir activa mientras cada paquete que genera va a un lugar inútil.

Compara la dirección que usa el cliente con la que tiene ahora la interfaz. Una ruta predeterminada que apunta a una puerta de enlace que también ha cambiado es la misma clase de problema con otro nombre.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Segunda condición: el mapeo traducido ha desaparecido

Los routers domésticos traducen los flujos salientes, y esos mapeos viven en la memoria. Un reinicio borra todos y cada uno de ellos. Eso es inofensivo para una conexión nueva y fatal para un túnel que cree que su flujo existente sigue siendo válido. Entonces el otro extremo no ve nada, así que el cliente nunca recibe un error sobre el que pueda actuar.

Aquí es donde un túnel sin keepalives se atasca en silencio en lugar de fallar ruidosamente. Las limitaciones documentadas de WireGuard describen la misma forma de fallo. Un estado de punto final incorrecto produce paquetes descartados en lugar de un diagnóstico.

Un keepalive persistente de 25 segundos es la mitigación habitual, porque refresca el mapeo antes de que pueda caducar un tiempo de espera por inactividad. No repara un mapeo que ya ha desaparecido. Combina el keepalive con lógica de reconexión en lugar de tratarlo como una solución.

Tercera condición: la dirección pública ha cambiado

Si la dirección externa del propio router ha cambiado, cualquier cosa al otro lado que filtre por dirección de origen ahora ve un interlocutor distinto. El túnel puede levantarse y el servidor puede seguir descartando el tráfico, lo que parece un cliente averiado y en realidad es una política del otro extremo.

Anota la dirección externa antes y después del reinicio. Cuando las dos difieren, la pregunta pasa del cliente a quien mantiene la lista de permitidos, y restablecer las credenciales en el portátil no puede ayudar.

Recupera en el orden correcto

Completa primero cualquier inicio de sesión obligatorio en el portal cautivo, luego deja que el cliente se reconecte mediante su procedimiento admitido en lugar de matar el proceso. Observa si se recuperan tanto la identidad como el tráfico de datos, porque son dos etapas distintas de la misma conexión.

Una página en caché no demuestra nada, ni tampoco una aplicación de chat que se ha reconectado sola. Prueba el punto final que de verdad te importa con una solicitud nueva. Mantén la política de tráfico directo durante la interrupción, porque un intento de reconexión no es un bloqueo.

Cuando esto se repite tras cada reinicio, el registro importa más que el reintento. Anota la dirección local, la puerta de enlace, la dirección externa y el estado del cliente antes y después, y compara las dos columnas. Eso convierte una queja vaga en un error de ciclo de vida que alguien puede corregir, y evita que los certificados se sustituyan por tercera vez por un tiempo de espera del mapeo.