OpenVPN: falló el establecimiento de TLS, ¿en qué rama estás?

La línea que dice que el establecimiento de TLS falló es el final de una historia, no su principio. Lo importante es el evento inmediatamente anterior, porque ese evento nombra cuál de cuatro fallos muy distintos tienes. Un tiempo de espera, un desajuste del canal de control, un certificado rechazado y un fallo tras la negociación producen el mismo titular. Elige la rama a partir de las pruebas y la corrección deja de ser una conjetura.

Lee el último evento antes del fallo

Desplázate hacia arriba en lugar de leer la última línea. El evento anterior a la desconexión suele nombrar la etapa: ninguna respuesta, un error al intercambiar paquetes de control, un resultado de verificación o una negociación correcta seguida de un resultado de autenticación. Cada uno pertenece a un responsable distinto. Esa única línea decide qué sección de las de abajo se aplica.

Guarda el texto del error con la versión del cliente, el punto final y el transporte. Mantén las claves, las contraseñas y los perfiles sin censurar fuera de todo lo que publiques.

Un primer error preciso vale más que un largo fragmento de registro. Nombra la etapa, y la etapa nombra al responsable.

Rama uno: no volvió nada

Si el cliente envió su primer paquete y no recibió nada utilizable, el problema está en la ruta o en el receptor. Confirma que el perfil coincide con una opción que el operador ofrece de verdad: dirección, puerto y UDP o TCP. Luego comprueba si el punto final es accesible desde esta red. Anota cuál de las dos comprobaciones falló antes de seguir.

Un navegador que carga una página en el mismo nombre de host solo demuestra que un servicio web respondió. Incluso una conexión TCP aceptada no dice nada sobre si OpenVPN terminó la negociación.

Si el perfil funciona en otra red de confianza, conserva esa comparación. Localiza la restricción en una ruta o en un intermediario.

Rama dos: el canal de control no coincide

Cuando el intercambio empieza y luego se detiene, la configuración del canal de control es el primer sospechoso. tls-auth y tls-crypt deben coincidir con el despliegue, y el material de otro servidor no producirá un intercambio útil. Este fallo ocurre antes de cualquier inicio de sesión. Un perfil copiado de un servidor antiguo es la fuente habitual.

Restablecer la contraseña no sustituye esa configuración, y tomar prestada una clave de otro servicio no es una corrección de compatibilidad. Obtén el perfil por el canal verificado del operador y anota la versión de cliente que espera.

Registra el error de negociación concreto en lugar de activar un montón de algoritmos antiguos para ver qué aguanta. Un texto de error capturado es lo que permite al operador comprobar su lado.

Rama tres: se rechazó un certificado

Un fallo explícito de verificación nombra el certificado que no le gusta. Comprueba primero el reloj del dispositivo y luego lee qué objeto falló: el certificado del servidor, el del cliente o un emisor de la cadena. La caducidad, un emisor no confiable y una identidad inesperada son tres mensajes distintos.

Mantén la verificación activada mientras obtienes material corregido. Aceptar un certificado no relacionado elimina el error sin demostrar que llegaste al servidor previsto.

Anota si el fallo sigue a la red o al perfil. Un error de certificado que aparece en todas partes no es un problema de ruta.

Rama cuatro: la negociación terminó y falló otra cosa

Cuando el intercambio de identidad tiene éxito, el fallo restante pertenece a la autenticación o al enrutamiento. Un rechazo explícito de la cuenta es una cuestión de autenticación, y un túnel conectado con sitios inalcanzables es una cuestión de enrutamiento o DNS. Seguir sustituyendo opciones de TLS en ese momento daña una etapa que ya funcionaba.

Cuando informes del problema, di si fallan todas las redes, si funciona otro perfil y si el servidor registró el intento. El silencio del servidor y un rechazo suyo se sitúan en límites distintos.