Tiempo de espera de la conexión VPN: DNS, transporte, negociación o inicio de sesión

“Se agotó el tiempo de conexión” es el error menos específico que puede imprimir un cliente VPN. Significa que una operación perdió su plazo, y cada etapa, desde la resolución de nombres hasta la respuesta de inicio de sesión, tiene un plazo. Los clientes que solo muestran el mensaje final hacen que las etapas parezcan idénticas, así que la gente sube el tiempo de espera, cambia el puerto y reinstala el perfil, en ese orden, sin aprender nada. Comparar las etapas es más rápido: cada una falla en un lugar distinto, y cada fallo deja un tipo distinto de evidencia.

Cuatro etapas, cuatro fallos distintos

La secuencia es fija aunque el cliente la oculte: el nombre debe resolverse, debe establecerse un transporte hacia la dirección resultante, el protocolo debe negociar sus parámetros y claves, y la cuenta debe autenticarse. La guía de solución de problemas de conectividad de OpenVPN sigue el mismo orden para su propio cliente, y los demás la siguen de cerca. Un tiempo agotado en la segunda etapa y otro en la cuarta no tienen nada en común salvo la palabra de la pantalla.

Lea el registro buscando la última línea que indica progreso, no la última línea antes del error. La mayoría de los clientes imprime algo como una dirección resuelta, un socket establecido, un handshake iniciado o una solicitud de autenticación, y la etapa que sigue a esa línea es la que se agotó.

La resolución de nombres falla antes de cualquier contacto

Si el punto final nunca se resuelve, el cliente no tiene a qué conectarse y no se ha hecho ningún trabajo de transporte. Ese fallo suele ser instantáneo en lugar de un tiempo de espera completo, que es la forma más barata de distinguirlo del resto. Pruebe el nombre con el resolutor del sistema y con un segundo resolutor, y compare las dos respuestas antes de concluir que el servidor está caído.

Una dirección antigua copiada de una publicación de foro es una causa común de un tiempo agotado que parece un problema del servidor, porque ahora la dirección pertenece a otra cosa o a nada. Use el perfil actual del operador en lugar de sustituir una dirección que antes funcionaba. Una respuesta de ping ausente no es prueba en ningún sentido: muchos puntos finales descartan ICMP mientras sirven perfectamente bien.

La configuración del transporte espera un paquete que no llegará

Cuando el DNS está bien y el cliente aún consume todo el tiempo de espera, la capa de transporte es el sospechoso. En TCP puede probar el puerto directamente; Test-NetConnection en Windows o nc -vz en Linux le dice si algo acepta la conexión, y eso es más útil que un ping. En UDP no puede probar de la misma manera, porque no hay ningún handshake que completar en esa capa, y esta asimetría provoca muchas conclusiones equivocadas.

Lo que demuestra una prueba TCP es limitado: un servicio que acepta el puerto 443 no es necesariamente el oyente VPN, y un punto final solo UDP no tiene ningún puerto TCP para aceptar nada. Reescribir un perfil de UDP a TCP no crea un oyente al otro lado; solo cambia lo que espera su cliente. Si la red filtra el protocolo, el cambio produce un tiempo agotado distinto en la misma etapa.

Los portales cautivos merecen su propia comprobación en esta etapa. Hasta que el portal autorice el dispositivo, el tráfico saliente va al portal y el intento de túnel simplemente se cuelga. Complete primero el portal en un navegador, vuelva a intentarlo después, y no cambie el perfil mientras el portal siga pendiente.

Negociación e inicio de sesión significan que el servidor respondió

Una vez que el túnel llega al servidor, el cliente inicia un handshake y el error cambia de carácter. Un atasco aquí tiene que ver con la compatibilidad, no con la accesibilidad: versiones de protocolo desajustadas, un cifrado o una configuración de canal de datos que el otro lado no aceptará, o un perfil que espera una función que el servidor no ofrece. OpenVPN movió sus valores predeterminados de negociación entre versiones mayores con la suficiente frecuencia como para que un perfil escrito para una generación pueda llegar al servidor y aun así no levantarse.

La autenticación es la última etapa y la más fácil de leer mal. Un rechazo explícito es una respuesta, lo que significa que la ruta funciona y el problema es la identidad, el certificado o el estado de la cuenta. Un flujo de inicio de sesión único basado en navegador es un tercer caso: el cliente espera una acción que usted no ha realizado, o un navegador que no puede lanzar, y no llegará nada hasta que complete ese paso.

Compare la evidencia antes de cambiar el reintento

Mantenga el dispositivo y el perfil fijos y cambie una cosa a la vez, empezando por la red. Si el mismo perfil conecta con un punto de acceso del teléfono y se agota en el Wi-Fi del hotel, la variable es la ruta, no el servidor. Si falla en todas partes, la variable es el perfil o el punto final. Si falla solo a una hora del día, capture la marca de tiempo y compárela con eventos del lado del servidor antes de suponer nada sobre la carga.

Para un servicio que usted administra, la comparación decisiva es si el intento llega siquiera. Una conexión que llega al oyente y luego se atasca pertenece a la etapa de negociación; una que nunca aparece en la vista del oyente es un problema de transporte o de resolución, y ningún ajuste de reintentos lo moverá. Los registros del servidor también separan un inicio de sesión rechazado de una caída silenciosa, que es la diferencia entre una corrección de identidad y una de cortafuegos.

Anote la versión del cliente, el nombre del perfil, la hora del intento con su zona horaria y el primer error útil en lugar de la última línea de desconexión. Elimine las claves y el material con credenciales antes de compartir el extracto. Luego haga una corrección significativa y reintente, porque un plazo más largo solo ayuda a la operación lenta documentada, y no hace nada por una dirección equivocada o un puerto bloqueado.