Tiempo de espera TLS de sesenta segundos: ¿qué extremo se detuvo realmente?

El cliente se rinde a los sesenta segundos con un mensaje sobre la negociación de claves, y el portátil no opina sobre por qué. Esa frase describe la paciencia del cliente, no el comportamiento del servidor. Tres situaciones muy distintas la producen: el paquete nunca llegó al servicio correcto, el servicio lo descartó antes de registrar nada, o el servicio lo rechazó y lo dijo en algún lugar que el cliente no puede ver. Correlacionar un solo intento en ambos extremos es lo que las separa.

Dé a un intento una identidad que pueda buscar

Anote la hora de inicio con su zona horaria, el nombre del perfil, el destino que el cliente resolvió realmente, el puerto y si la conexión es UDP o TCP. Si el perfil contiene varias entradas remotas, indique cuál eligió ese intento, porque un reintento puede haberse movido a la entrada siguiente sin cambiar el archivo que está leyendo.

Tome el extremo del registro activo, no de la descarga que recuerda. Un perfil que apunta a una dirección privada es perfectamente válido y completamente inutilizable desde una red que no puede enrutar hacia ella, y ese caso se ve idéntico a un servidor caído.

Luego pida al operador la misma ventana en la instancia prevista. La desviación del reloj es lo bastante común como para que un desfase de pocos minutos haga que un evento coincidente parezca ausente, así que registre el desfase en lugar de concluir que no hubo ningún evento.

Cuatro observaciones, cuatro pasos siguientes distintos

Lo que el servidor registra decide la rama. La ausencia de cualquier intento apunta al direccionamiento, al transporte o al camino hacia el servicio. Los paquetes entrantes que desaparecen antes de un intercambio ordinario apuntan a los requisitos del canal de control del servicio real. Un rechazo con nombre apunta al objeto que nombra. Las respuestas que salen del servidor pero nunca llegan al cliente apuntan al camino de vuelta.

Un registro de aplicación vacío es una prueba más débil de lo que parece. El registro comienza en un punto determinado del intercambio, y los paquetes descartados antes de ese punto no dejan rastro en el archivo que está leyendo. Donde está autorizado, el operador puede usar observaciones del servicio y de la red para ver si llegó algo.

Mantenga los cuatro resultados separados en sus notas. La tentación es fusionarlos en «el servidor no responde», que es la frase que envía a la gente a cambiar cifrados cuando el problema real es una regla de cortafuegos. Una nota que solo registra la palabra tiempo de espera ha tirado la distinción que acaba de pagar.

Corrija la etapa que la evidencia nombra

Una conexión TCP que se completa solo demuestra que algo aceptó un socket. No demuestra que el oyente sea el servicio OpenVPN que configuró, y un servidor web en el mismo nombre de host responde perfectamente a un navegador mientras es irrelevante para el túnel.

Si el servidor informa de una lista de revocación caducada, ese es un hecho mucho más específico que el tiempo de espera final del cliente, y la corrección corresponde a la autoridad de certificación y no a la red. Si los dos extremos no coinciden sobre la protección del canal de control o el material compartido, restablecer una contraseña no cambia nada, porque el descarte ocurre antes de que se examine cualquier credencial.

Cambie una cosa que la evidencia realmente respalde, y luego repita el mismo perfil contra el mismo extremo. Conserve el primer evento nuevo si la conexión avanza más, porque ese evento es la siguiente etapa de la investigación, no un problema nuevo.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

Qué cambia realmente ampliar la ventana

Sesenta segundos es la ventana de apretón de manos del cliente, y la referencia comunitaria del cliente documenta la opción que la ajusta. Aumentarla hace que el cliente espere más antes de rendirse. No hace aparecer un servicio ausente ni hace aceptable un paquete rechazado.

Hay un uso legítimo de una ventana más larga en un enlace lento o un servidor muy cargado, y vale la pena probarlo cuando tenga pruebas de que el intercambio avanza despacio en lugar de no ocurrir. Probarlo primero solo retrasa el mismo diagnóstico otro minuto y hace que la línea temporal sea más difícil de leer. Si la línea temporal muestra un intercambio que avanza y luego se estanca, la ventana es un síntoma de carga y no de accesibilidad.