OpenVPN segue reintentando tras un erro TLS: como detelo

O cliente conecta, falla durante a negociación TLS, agarda e volve probar o mesmo servidor co mesmo resultado. Baixo un supervisor que reinicia un proceso fallido, eses intentos converten nun bucle sen fin no rexistro, e a primeira liña de diagnóstico pérdese de vista. OpenVPN inclúe unha opción que converte ese fallo de negociación nunha saída visible en lugar doutro reintento. É un axuste de diagnóstico e supervisión, non unha reparación, así que combíneo cunha política que realmente deixe o proceso detido.

O ciclo que oculta o primeiro erro

O que ve é un bloque repetido e non un único fallo: un intento de conexión, un erro TLS, unha pausa e despois a mesma secuencia. Cada repetición empurra a liña orixinal máis arriba no rexistro. Se a unidade se reinicia ao fallar, o ciclo pode continuar durante horas sen que ninguén lea a causa. O síntoma é o bucle, aínda que o defecto subxacente sexa un único problema de negociación.

As sesións interactivas toléranno porque un fallo transitorio pode desaparecer no seguinte intento. As conexións automatizadas non poden permitirse o mesmo optimismo: o proceso ten que deterse para que unha persoa ou un monitor vexa o estado.

Antes de cambiar nada, capture un ciclo completo. Anote o enderezo remoto, a etapa TLS indicada no erro e se o proceso chega a saír.

A maquinaria de reintentos detrás do bucle

Reintentar é o predeterminado porque varios tempos de espera non relacionados comparten a mesma maquinaria. connect-retry fixa o intervalo entre intentos de conexión, connect-retry-max pode limitar con que frecuencia se proba cada entrada remota, e resolv-retry goberna as buscas repetidas de nomes. Un fallo de negociación TLS chega a esa maquinaria como un evento de transporte, así que o cliente programa outro intento en lugar de informar. O valor predeterminado axuda cunha ligazón inestable e prexudica cun fallo que non pode curarse.

A opción --tls-exit só cambia o caso de negociación. O manual descríbea como saír ante un fallo de negociación TLS, o que é máis estreito que saír ante calquera erro. Os tempos de espera, os fallos do resolvedor e os rexeitamentos de autenticación manteñen o seu propio comportamento.

Facer que o cliente saia ante un fallo TLS

Pona tls-exit no perfil que o cliente carga realmente, ou pase --tls-exit ao iniciar, e execúteo unha vez en primeiro plano. Lea o estado de saída e tamén a última liña do rexistro, porque é o estado no que actúa un supervisor. Unha saída distinta de cero tras un fallo de negociación é o resultado previsto. Se o proceso segue reintentando en lugar de rematar, a opción non está no perfil que o cliente carga realmente.

O supervisor decide se esa saída é visible. Unha unidade systemd con Restart=always ou Restart=on-failure volve iniciar o cliente, así que o bucle continúa e a opción parece non facer nada. Revise a política antes de culpar o cliente:

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

Restart=no deixa o proceso detido, e Restart=on-failure segue reiniciando tras un estado distinto de cero. Se quere que o fallo sexa visible pero que o servizo se recupere de caídas non relacionadas, defina Restart=on-failure e use StartLimitBurst e StartLimitIntervalSec para deter a tormenta de reinicios. Despois lea o estado da unidade para confirmar o último código de saída: systemctl status infórmao, e o rexistro conserva o primeiro erro por riba dos reinicios.

Escriba a decisión na unidade ou nas notas do perfil. Un perfil que sae ante un fallo TLS parece un accidente para a seguinte persoa, a menos que o motivo quede rexistrado. Indique que fallos deben deter o proceso e cales deben reintentarse.

Probalo cun punto final dun só uso

Para ver o comportamento antes de confiar nel, copie o perfil e apunte a copia a un punto final que acepta unha conexión TCP pero nunca fala OpenVPN. Abonda cun oínte que responde e despois queda en silencio. Con tls-exit, o cliente debería rematar cando falla o apretón de mans; sen ela, o mesmo perfil debería seguir xirando. Use a copia, nunca o perfil de traballo.

Compare as dúas execucións polo estado de saída e pola primeira liña de erro, non por canto durou cada unha. O estado di se a opción se activou, e a primeira liña di que etapa fallou.

Retire o perfil de proba cando remate. Unha copia cun punto final deliberadamente incorrecto é unha trampa para quen despois inicie todos os perfís do directorio.

Etapas ás que esta opción nunca chega

Un rexeitamento de autenticación é unha etapa posterior. Se o servidor avalía a conta e a rexeita, TLS xa se negociou, así que tls-exit non se activa. Os axustes de reintento de autenticación son o seguinte lugar onde mirar, e o motivo do servidor importa máis que a última liña do cliente. Un contrasinal incorrecto e un certificado ausente poden producir mensaxes similares no lado do cliente.

Unha ruta ausente, un resolvedor incorrecto ou unha pasarela inalcanzable tamén quedan fóra da opción, porque non son fallos de negociación. A perda silenciosa de paquetes é o caso menos evidente: segundo o avanzado que estea o intercambio, o cliente pode informar dun fallo de negociación ou simplemente esgotar o tempo.

Manteña a distinción nas súas notas. O axuste é para diagnóstico e supervisión máis que para reparación, así que non arranxa unha discrepancia de cifrado, un problema de certificado nin un porto incorrecto. Repare primeiro a causa da negociación fallida e despois decida se saír de inmediato segue encaixando no despregamento.