La VPN se reconecta, pero la sesión de la aplicación sigue fallando

El túnel vuelve, el cliente dice que está conectado y el navegador sigue girando en una página que estaba cargando antes del corte. Una reconexión de VPN restaura una ruta y no restaura el estado de conexión que las aplicaciones y el lado remoto acumularon en la antigua. Son dos cosas distintas que reparar, y confundirlas le devuelve a los ajustes de la VPN sin motivo.

Una prueba las separa limpiamente, y tarda diez segundos. Envíe una petición nueva al mismo destino mientras la antigua sigue colgada.

Qué sobrevive a una reconexión y qué no

Un túnel es un conjunto de rutas, claves y direcciones, y una reconexión puede restaurar las tres mientras cada flujo establecido sigue muerto. El sistema operativo mantiene un socket abierto porque la aplicación se lo pidió, y el tiempo de espera de ese socket puede estar a minutos u horas. Por debajo, el par ha olvidado el flujo, una entrada de traducción ha caducado o la ruta pasa ahora por un extremo que nunca vio el saludo inicial. Nada en la secuencia de reconexión recorre los sockets de la aplicación y los repara.

Algunos clientes añaden un gancho que descarta las conexiones viejas al reconectar, y la mayoría no. El comportamiento aquí varía según el cliente, la plataforma y la versión.

El lado remoto también se olvidó de usted

El extremo lejano guarda estado propio: una sesión TLS, un bloque de control TCP y quizá una entrada de mapeo que ata su dirección y puerto al flujo. Un dispositivo de traducción en la ruta puede hacer caducar ese mapeo durante el hueco aunque el túnel se restablezca rápido. Una vez que el mapeo desaparece, llegan paquetes de un flujo que el servidor ya no reconoce, y la respuesta puede ser un reset que el cliente nunca muestra. Las aplicaciones lo informan como un bloqueo y no como un error, porque siguen esperando un socket que nunca responderá.

Los tiempos de inactividad del lado del servidor hacen lo mismo según su propio calendario, y por eso una sesión puede morir sin ningún evento de red. Una conexión que estuvo inactiva más tiempo del que el servidor espera ya se fue antes de que note que el túnel se movió.

Una petición nueva es la prueba que las separa

Envíe una petición nueva al mismo host mientras la antigua sigue colgada y observe ambas. Si la petición nueva tiene éxito, entonces el túnel, la ruta y la resolución de nombres funcionan, y el fallo se limita al flujo viejo. Si la petición nueva también falla, tiene un problema de ruta y el estado de sesión de la aplicación es una pista falsa.

Mantenga cualquier bloqueo de tráfico directo en su sitio durante la prueba. Una petición que tiene éxito por una ruta alternativa accidental no demuestra nada sobre el túnel.

Confirme con una conexión nueva, no con la vieja

Los comandos siguientes muestran los sockets aún abiertos, inician una petición nueva y comprueban si la tabla de sesiones aún tiene una entrada para el flujo. Ejecute el primero antes y después de la reconexión para que la diferencia sea visible. Sustituya el host y el puerto por su propio servicio.

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

Un socket establecido sin tráfico en movimiento es la firma que hay que buscar, y una petición nueva que devuelve un código de estado muestra que la ruta está viva. La tabla de conexiones responde si algo sigue mapeando el flujo, y esa es la parte que el cliente no puede ver. La consulta al resolutor cubre la otra mitad de una carga de página, ya que un fallo de nombre y una conexión atascada se ven iguales en un navegador. Juntos, esas cuatro salidas separan una sesión vieja de un túnel roto.

Anote la hora de la interrupción, la hora de la reconexión y la diferencia entre la petición vieja y la nueva. Ese registro convierte una queja vaga en un informe sobre el que alguien puede actuar.