OpenVPN continua a tentar depois de um erro TLS: como impedir

O cliente liga-se, falha durante a negociação TLS, espera e volta a tentar o mesmo servidor com o mesmo resultado. Sob um supervisor que reinicia um processo falhado, essas tentativas tornam-se um ciclo sem fim no registo, e a primeira linha de diagnóstico sai do alcance. O OpenVPN inclui uma opção que transforma essa falha de negociação numa saída visível em vez de mais uma tentativa. É uma definição de diagnóstico e supervisão, não uma reparação, por isso combine-a com uma política que deixe mesmo o processo parado.

O ciclo que esconde o primeiro erro

O que vê é um bloco repetido e não uma única falha: uma tentativa de ligação, um erro TLS, uma pausa e depois a mesma sequência. Cada repetição empurra a linha original mais acima no registo. Se a unidade reinicia ao falhar, o ciclo pode continuar durante horas sem que ninguém leia a causa. O sintoma é o ciclo, embora o defeito subjacente seja um único problema de negociação.

As sessões interativas toleram isto porque uma falha transitória pode desaparecer na tentativa seguinte. As ligações automatizadas não podem dar-se ao mesmo otimismo: o processo tem de parar para que uma pessoa ou um monitor veja o estado.

Antes de mudar algo, capture um ciclo completo. Anote o endereço remoto, a etapa TLS indicada no erro e se o processo chega a sair.

O mecanismo de repetição por trás do ciclo

Repetir é o comportamento predefinido porque vários tempos limite não relacionados partilham o mesmo mecanismo. connect-retry define o intervalo entre tentativas de ligação, connect-retry-max pode limitar a frequência com que cada entrada remota é tentada, e resolv-retry governa as pesquisas repetidas de nomes. Uma falha de negociação TLS chega a esse mecanismo como evento de transporte, por isso o cliente agenda outra tentativa em vez de reportar. O valor predefinido ajuda numa ligação instável e prejudica num defeito que não consegue sarar.

A opção --tls-exit altera apenas o caso da negociação. O manual descreve-a como sair quando a negociação TLS falha, o que é mais estreito do que sair em qualquer erro. Os tempos limite, as falhas do resolvedor e as recusas de autenticação mantêm o seu próprio comportamento.

Fazer o cliente sair quando falha o TLS

Coloque tls-exit no perfil que o cliente carrega realmente, ou passe --tls-exit ao iniciá-lo, e execute-o uma vez em primeiro plano. Leia o estado de saída e a última linha do registo, porque é sobre o estado que um supervisor age. Uma saída diferente de zero após uma falha de negociação é o resultado pretendido. Se o processo continua a tentar em vez de terminar, a opção não está no perfil que o cliente carrega realmente.

O supervisor decide se essa saída é visível. Uma unidade systemd com Restart=always ou Restart=on-failure volta a iniciar o cliente, por isso o ciclo continua e a opção parece não fazer nada. Verifique 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 processo parado, e Restart=on-failure continua a reiniciar após um estado diferente de zero. Se quer que a falha seja visível mas que o serviço recupere de falhas não relacionadas, defina Restart=on-failure e use StartLimitBurst e StartLimitIntervalSec para parar a tempestade de reinícios. Depois leia o estado da unidade para confirmar o último código de saída: systemctl status informa-o, e o registo mantém o primeiro erro acima dos reinícios.

Escreva a decisão na unidade ou nas notas do perfil. Um perfil que sai quando falha o TLS parece um acidente para a pessoa seguinte, a menos que o motivo fique registado. Indique que falhas devem parar o processo e quais devem ser repetidas.

Prove-o com um ponto final descartável

Para ver o comportamento antes de confiar nele, copie o perfil e aponte a cópia para um ponto final que aceita uma ligação TCP mas nunca fala OpenVPN. Basta um ouvinte que responde e depois fica em silêncio. Com tls-exit, o cliente deve terminar quando o handshake falha; sem ela, o mesmo perfil deve continuar a ciclar. Use a cópia, nunca o perfil de trabalho.

Compare as duas execuções pelo estado de saída e pela primeira linha de erro, não por quanto cada uma durou. O estado diz se a opção disparou, e a primeira linha diz que etapa falhou.

Remova o perfil de teste quando terminar. Uma cópia com um ponto final deliberadamente errado é uma armadilha para quem depois inicie todos os perfis da pasta.

Etapas a que esta opção nunca chega

Uma recusa de autenticação é uma etapa posterior. Se o servidor avalia a conta e a recusa, o TLS já foi negociado, por isso tls-exit não dispara. As definições de repetição da autenticação são o próximo local a ver, e o motivo do servidor importa mais do que a última linha do cliente. Uma palavra-passe errada e um certificado em falta podem produzir mensagens semelhantes do lado do cliente.

Uma rota em falta, um resolvedor errado ou um gateway inalcançável também ficam fora da opção, porque não são falhas de negociação. A perda silenciosa de pacotes é o caso menos evidente: conforme o avanço da troca, o cliente pode reportar uma falha de negociação ou simplesmente esgotar o tempo.

Mantenha a distinção nas suas notas. A definição serve para diagnóstico e supervisão e não para reparação, por isso não corrige uma incompatibilidade de cifra, um problema de certificado nem uma porta errada. Repare primeiro a causa da negociação falhada e depois decida se sair de imediato ainda serve à implementação.