OpenVPN: o handshake TLS falhou — em que ramo você está?

A linha que diz que o handshake TLS falhou é o fim de uma história, não o começo. O importante é o evento imediatamente anterior, porque esse evento nomeia qual das quatro falhas muito diferentes você tem. Um timeout, uma incompatibilidade do canal de controle, um certificado recusado e uma falha após a negociação produzem o mesmo título. Escolha o ramo pelas evidências, e a correção deixa de ser um chute.

Leia o último evento antes da falha

Role para cima em vez de ler a última linha. O evento antes da desconexão costuma nomear a etapa: nenhuma resposta, um erro ao trocar pacotes de controle, um resultado de verificação ou uma negociação bem-sucedida seguida de um resultado de autenticação. Cada um deles pertence a um responsável diferente. Essa única linha decide qual seção abaixo se aplica.

Guarde o texto do erro com a versão do cliente, o endpoint e o transporte. Mantenha chaves, senhas e perfis não censurados fora de tudo o que você publicar.

Um primeiro erro preciso vale mais que um trecho longo de log. Ele nomeia a etapa, e a etapa nomeia o responsável.

Ramo um: nada voltou

Se o cliente enviou seu primeiro pacote e não recebeu nada utilizável, o problema está no caminho ou no ouvinte. Confirme que o perfil corresponde a uma opção que o operador realmente oferece: endereço, porta e UDP ou TCP. Depois verifique se o endpoint é acessível a partir desta rede. Anote qual das duas verificações falhou antes de seguir.

Um navegador que carrega uma página no mesmo nome de host prova apenas que um serviço web respondeu. Nem uma conexão TCP aceita diz algo sobre se o OpenVPN concluiu a negociação.

Se o perfil funciona em outra rede confiável, mantenha essa comparação. Ela localiza a restrição em um caminho ou em um intermediário.

Ramo dois: o canal de controle não corresponde

Quando a troca começa e depois trava, as configurações do canal de controle são o primeiro suspeito. tls-auth e tls-crypt precisam corresponder à implantação, e material de outro servidor não produzirá uma troca útil. Essa falha ocorre antes de qualquer login de conta. Um perfil copiado de um servidor mais antigo é a origem habitual.

Redefinir a senha não substitui essas configurações, e pegar uma chave emprestada de outro serviço não é uma correção de compatibilidade. Obtenha o perfil pelo canal verificado do operador e anote a versão de cliente que ele espera.

Registre o erro de negociação específico em vez de ativar uma pilha de algoritmos mais antigos para ver o que aguenta. Um texto de erro capturado é o que permite ao operador verificar o lado dele.

Ramo três: um certificado foi recusado

Uma falha explícita de verificação nomeia o certificado de que não gosta. Verifique primeiro o relógio do dispositivo e depois leia qual objeto falhou: o certificado do servidor, o do cliente ou um emissor da cadeia. Expiração, um emissor não confiável e uma identidade inesperada são três mensagens diferentes.

Mantenha a verificação ativa enquanto obtém material corrigido. Aceitar um certificado não relacionado remove o erro sem provar que você chegou ao servidor pretendido.

Anote se a falha segue a rede ou o perfil. Um erro de certificado que aparece em toda parte não é um problema de caminho.

Ramo quatro: a negociação terminou e outra coisa falhou

Quando a troca de identidade tem sucesso, a falha restante pertence à autenticação ou ao roteamento. Uma recusa explícita da conta é uma questão de autenticação, e um túnel conectado com sites inalcançáveis é uma questão de roteamento ou DNS. Continuar a substituir opções de TLS nesse ponto danifica uma etapa que já funcionava.

Ao relatar o problema, diga se todas as redes falham, se outro perfil funciona e se o servidor registrou a tentativa. O silêncio do lado do servidor e uma recusa dele ficam em limites diferentes.