VPN muerta tras la suspensión: ¿túnel perdido o aplicación obsoleta?

La tapa se abre, el icono inalámbrico vuelve y la VPN sigue mostrándose como conectada. La primera página interna entonces se cuelga hasta agotar el tiempo de espera, y una pestaña nueva hace lo mismo. Tres cosas distintas pueden producir esa imagen y necesitan tres arreglos distintos: un túnel que no sobrevivió a la suspensión, un perfil que nadie pidió reactivar, o una aplicación que aún mantiene una sesión que murió hace horas. Compararlas es más rápido que reinstalar cualquier cosa.

Tres cosas pueden estar rotas tras despertar

El primer candidato es el propio túnel. La interfaz puede seguir existiendo con una dirección mientras la asociación con el par se ha ido, por eso una luz indicadora no es prueba de una ruta que funcione. Un intercambio de claves más antiguo que la suspensión es la pista, y basta un comando para verlo.

El segundo es la activación. Muchos clientes se reconectan solos; otros no, y un perfil que nadie pide que vuelva se queda ahí con aspecto de configurado. Ese fallo es silencioso por diseño, porque nada dio error.

El tercero es la aplicación. Una pestaña del navegador, una sesión SSH o una conexión a una base de datos pueden sobrevivir a un cambio de red como descriptor de archivo mientras el transporte de debajo está muerto. Entonces una sesión nueva funciona a la perfección, lo que le dice que el túnel estaba bien todo el tiempo.

Compare las tres antes de cambiar nada, porque los arreglos no se solapan. Reiniciar un cliente al que nunca se le pidió volver a arrancar desperdicia la prueba que necesitaba. Anote a qué candidato encaja el síntoma antes de tocar una configuración. Esa sola frase suele decidir el resto de la investigación.

Primero: ¿volvió el túnel?

Mire la interfaz y el estado del par en lugar del texto de estado del cliente. Una interfaz con dirección y sin intercambio de claves reciente es un túnel que solo existe sobre el papel.

ip -brief addr show
wg show
ip route show table all | head -20

Si la interfaz falta por completo, el túnel no sobrevivió y la pregunta pasa a ser quién debía devolverlo. Si está presente pero el intercambio de claves es viejo, hay que restablecer la asociación con el par, y el cliente puede estar esperando tráfico para activarla.

Revise también las rutas y la configuración de DNS. Un túnel puede volver sin sus rutas, lo que produce el estado confuso en el que la interfaz funciona y los nombres internos aún se resuelven por el servidor equivocado.

Segundo: ¿pidió algo que volviera?

Aquí es donde la comparación se gana su sitio. Un perfil de complemento OpenVPN y una conexión nativa de WireGuard se manejan de forma distinta en NetworkManager, y la referencia de ajustes de conexión dice claramente que connection.autoconnect no activa perfiles de VPN; el mecanismo para levantar una VPN junto con una conexión es connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Si reconectar a mano arregla el problema todas las veces, es la firma de una activación ausente y no de un túnel roto. El registro normalmente mostrará la interfaz cayendo y nada que la devuelva.

Resista el impulso de añadir un hook de suspensión de inmediato. Un hook que se dispara antes de que la red se haya recuperado compite con el mismo proceso al que intenta ayudar, y convierte un problema reproducible en intermitente.

Tercero: ¿mantiene la aplicación estado viejo?

Abra una sesión completamente nueva hacia el mismo destino antes de tocar la VPN. Si la sesión nueva funciona y la vieja no, el túnel está bien y la aplicación mantiene una conexión muerta.

Esta es la más barata de las tres comprobaciones y la que más se omite, porque la ventana que falla está justo en la pantalla. Ciérrela, vuelva a abrirla y anote si el problema sobrevive. Si la sesión nueva funciona, detenga por completo la investigación del túnel. Si también falla, la aplicación es un síntoma y no una causa.

Algunas aplicaciones se recuperan solas tras un tiempo de espera, por eso puede parecer que el síntoma se arregla solo al cabo de unos minutos. Ese comportamiento apunta a la aplicación y no al túnel, y merece registrarse aparte. Un compañero que dice que se ha arreglado solo describe este patrón, no una suerte.

Haga la comparación reproducible

Mantenga las variables pequeñas: una red de acceso, una duración de suspensión y la misma primera petición cada vez. Después registre dos resultados: si reconectar a mano lo arregla y si otra suspensión vuelve a traer el fallo.

Esa última observación es la que separa a los tres candidatos con más fiabilidad. Una sesión nueva que funciona después de una vieja fallida no es un problema de túnel, y ninguna reinstalación del cliente lo cambiará.

El keepalive persistente de WireGuard solo entra en esta imagen como keepalive de asignación NAT. Envía paquetes para mantener una asignación abierta; no impide que la máquina se suspenda y no puede seguir enviando mientras el proceso está suspendido.

Anote en el ticket qué encontró: cuál de las tres cosas estaba rota, qué la arregló y cómo lo reprodujo. La próxima persona que abra una tapa un lunes se lo agradecerá, y la respuesta no tendrá que redescubrirse desde cero.