Tempo limite TLS de sessenta segundos: qual extremidade parou realmente?
Combine uma tentativa do cliente com os eventos do próprio servidor antes de mexer nas configurações de TLS. Silêncio, descarte precoce e uma rejeição nomeada exigem correções diferentes.
O cliente desiste após sessenta segundos com uma mensagem sobre negociação de chaves, e o notebook não opina sobre o motivo. Essa frase descreve a paciência do cliente, não o comportamento do servidor. Três situações bem diferentes a produzem: o pacote nunca chegou ao serviço certo, o serviço o descartou antes de registrar qualquer coisa, ou o serviço o rejeitou e disse isso num lugar que o cliente não vê. Correlacionar uma única tentativa nas duas pontas é o que as separa.
Dê a uma tentativa uma identidade que você possa procurar
Anote a hora de início com o fuso horário, o nome do perfil, o destino que o cliente realmente resolveu, a porta e se a conexão é UDP ou TCP. Se o perfil tiver várias entradas remotas, registre qual delas essa tentativa escolheu, porque uma nova tentativa pode ter passado para a entrada seguinte sem alterar o arquivo que você está lendo.
Pegue o endpoint no log ativo, não no download que você lembra. Um perfil que aponta para um endereço privado é perfeitamente válido e completamente inutilizável a partir de uma rede que não consegue encaminhar para lá, e esse caso parece idêntico a um servidor fora do ar.
Depois peça ao operador a mesma janela na instância pretendida. A diferença de relógio é comum o bastante para que alguns minutos de desvio façam um evento correspondente parecer ausente, então registre o desvio em vez de concluir que não houve evento.
Quatro observações, quatro próximos passos diferentes
O que o servidor registra decide o ramo. A ausência de qualquer tentativa aponta para endereçamento, transporte ou o caminho até o serviço. Pacotes de entrada que desaparecem antes de uma troca comum apontam para os requisitos do canal de controle do serviço real. Uma rejeição nomeada aponta para o objeto que ela nomeia. Respostas que deixam o servidor mas nunca chegam ao cliente apontam para o caminho de volta.
Um log de aplicação vazio é evidência mais fraca do que parece. O registro começa num certo ponto da troca, e os pacotes descartados antes desse ponto não deixam vestígio no arquivo que você lê. Onde isso é permitido, o operador pode usar observações do serviço e da rede para ver se algo chegou.
Mantenha os quatro resultados separados nas suas notas. A tentação é fundi-los em “o servidor não responde”, e é essa frase que manda as pessoas trocarem cifras quando o problema real é uma regra de firewall. Uma nota que registra apenas a palavra tempo limite jogou fora a distinção que você acabou de pagar.
Corrija a etapa que a evidência nomeia
Uma conexão TCP que se completa prova apenas que algo aceitou um socket. Não prova que o ouvinte é o serviço OpenVPN que você configurou, e um servidor web no mesmo nome de host responde perfeitamente a um navegador enquanto é irrelevante para o túnel.
Se o servidor relata uma lista de revogação expirada, isso é um fato bem mais específico que o tempo limite final do cliente, e a correção pertence à autoridade de certificação e não à rede. Se as duas pontas não concordam sobre a proteção do canal de controle ou o material compartilhado, redefinir uma senha não muda nada, porque o descarte acontece antes de qualquer credencial ser examinada.
Mude uma coisa que a evidência realmente sustenta, e depois repita o mesmo perfil contra o mesmo endpoint. Preserve o primeiro evento novo se a conexão avançar mais, porque esse evento é a próxima etapa da investigação, não um problema novo.
grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3
O que ampliar a janela realmente muda
Sessenta segundos é a janela de aperto de mão do cliente, e a referência do cliente da comunidade documenta a opção que a ajusta. Aumentá-la faz o cliente esperar mais antes de desistir. Isso não faz um serviço ausente aparecer e não torna aceitável um pacote rejeitado.
Há um uso legítimo para uma janela maior num link lento ou num servidor muito carregado, e vale a pena tentar quando você tem evidência de que a troca avança devagar em vez de não acontecer. Tentar primeiro apenas atrasa o mesmo diagnóstico por mais um minuto e torna a linha do tempo mais difícil de ler. Se a linha do tempo mostra uma troca que avança e depois para, a janela é sintoma de carga e não de alcance.