OpenVPN sigue reintentando tras un error TLS: cómo detenerlo

El cliente se conecta, falla durante la negociación TLS, espera y vuelve a probar el mismo servidor con el mismo resultado. Bajo un supervisor que reinicia un proceso fallido, esos intentos se convierten en un bucle sin fin en el registro, y la primera línea de diagnóstico se pierde de vista. OpenVPN incluye una opción que convierte ese fallo de negociación en una salida visible en lugar de otro reintento. Es un ajuste de diagnóstico y supervisión, no una reparación, así que combínelo con una política que realmente deje el proceso detenido.

El ciclo que oculta el primer error

Lo que ve es un bloque repetido y no un solo fallo: un intento de conexión, un error TLS, una pausa y luego la misma secuencia. Cada repetición empuja la línea original más arriba en el registro. Si la unidad se reinicia al fallar, el ciclo puede continuar durante horas sin que nadie lea la causa. El síntoma es el bucle, aunque el defecto subyacente sea un único problema de negociación.

Las sesiones interactivas lo toleran porque un fallo transitorio puede desaparecer en el siguiente intento. Las conexiones automatizadas no pueden permitirse el mismo optimismo: el proceso tiene que detenerse para que una persona o un monitor vea el estado.

Antes de cambiar nada, capture un ciclo completo. Anote la dirección remota, la etapa TLS indicada en el error y si el proceso llega a salir.

La maquinaria de reintentos detrás del bucle

Reintentar es lo predeterminado porque varios tiempos de espera no relacionados comparten la misma maquinaria. connect-retry fija el intervalo entre intentos de conexión, connect-retry-max puede limitar con qué frecuencia se prueba cada entrada remota, y resolv-retry gobierna las búsquedas repetidas de nombres. Un fallo de negociación TLS llega a esa maquinaria como un evento de transporte, así que el cliente programa otro intento en lugar de informar. El valor predeterminado ayuda con un enlace inestable y perjudica con un fallo que no puede curarse.

La opción --tls-exit solo cambia el caso de negociación. El manual la describe como salir ante un fallo de negociación TLS, lo que es más estrecho que salir ante cualquier error. Los tiempos de espera, los fallos del resolutor y los rechazos de autenticación conservan su propio comportamiento.

Hacer que el cliente salga ante un fallo TLS

Ponga tls-exit en el perfil que el cliente carga realmente, o pase --tls-exit al iniciarlo, y ejecútelo una vez en primer plano. Lea el estado de salida y también la última línea del registro, porque el estado es lo que un supervisor tiene en cuenta. Una salida distinta de cero tras un fallo de negociación es el resultado previsto. Si el proceso sigue reintentando en lugar de terminar, la opción no está en el perfil que el cliente carga realmente.

El supervisor decide si esa salida es visible. Una unidad systemd con Restart=always o Restart=on-failure vuelve a iniciar el cliente, así que el bucle continúa y la opción parece no hacer nada. Revise la política antes de culpar al cliente:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no deja el proceso detenido, y Restart=on-failure sigue reiniciando tras un estado distinto de cero. Si quiere que el fallo sea visible pero que el servicio se recupere de caídas no relacionadas, defina Restart=on-failure y use StartLimitBurst y StartLimitIntervalSec para detener la tormenta de reinicios. Después lea el estado de la unidad para confirmar el último código de salida: systemctl status lo informa, y el registro conserva el primer error por encima de los reinicios.

Escriba la decisión en la unidad o en las notas del perfil. Un perfil que sale ante un fallo TLS parece un accidente para la siguiente persona, a menos que el motivo quede registrado. Indique qué fallos deben detener el proceso y cuáles deben reintentarse.

Demostrarlo con un punto final desechable

Para ver el comportamiento antes de confiar en él, copie el perfil y apunte la copia a un punto final que acepte una conexión TCP pero nunca hable OpenVPN. Basta con un oyente que responda y luego guarde silencio. Con tls-exit, el cliente debería terminar cuando falle el apretón de manos; sin la opción, el mismo perfil debería seguir ciclando. Use la copia, nunca el perfil de trabajo.

Compare las dos ejecuciones por el estado de salida y por la primera línea de error, no por cuánto duró cada una. El estado dice si la opción se activó, y la primera línea dice qué etapa falló.

Elimine el perfil de prueba cuando termine. Una copia con un punto final deliberadamente incorrecto es una trampa para quien después inicie todos los perfiles del directorio.

Etapas a las que esta opción nunca llega

Un rechazo de autenticación es una etapa posterior. Si el servidor evalúa la cuenta y la rechaza, TLS ya se ha negociado, así que tls-exit no se activa. Los ajustes de reintento de autenticación son el siguiente lugar donde mirar, y el motivo del servidor importa más que la última línea del cliente. Una contraseña incorrecta y un certificado ausente pueden producir mensajes similares del lado del cliente.

Una ruta ausente, un resolutor incorrecto o una puerta de enlace inalcanzable también quedan fuera de la opción, porque no son fallos de negociación. La pérdida silenciosa de paquetes es el caso menos evidente: según lo avanzado que esté el intercambio, el cliente puede informar de un fallo de negociación o simplemente agotar el tiempo.

Mantenga la distinción en sus notas. El ajuste es para diagnóstico y supervisión más que para reparación, así que no arregla una discrepancia de cifrado, un problema de certificado ni un puerto incorrecto. Repare primero la causa de la negociación fallida y luego decida si salir de inmediato sigue encajando en el despliegue.