Tempo limite da conexão VPN: DNS, transporte, negociação ou login

“A conexão expirou” é o erro menos específico que um cliente VPN pode imprimir. Significa que uma operação perdeu o prazo, e cada etapa, da resolução de nomes até a resposta de login, tem um prazo. Clientes que mostram apenas a mensagem final fazem as etapas parecerem idênticas, então as pessoas aumentam o tempo limite, trocam a porta e reinstalam o perfil, nessa ordem, sem aprender nada. Comparar as etapas é mais rápido: cada uma falha em um lugar diferente, e cada falha deixa um tipo diferente de evidência.

Quatro etapas, quatro falhas diferentes

A sequência é fixa mesmo quando o cliente a esconde: o nome deve ser resolvido, um transporte deve ser estabelecido para o endereço resultante, o protocolo deve negociar seus parâmetros e chaves, e a conta deve ser autenticada. O guia de solução de problemas de conectividade do OpenVPN segue a mesma ordem para seu próprio cliente, e os demais a seguem de perto. Um tempo limite na segunda etapa e outro na quarta não têm nada em comum além da palavra na tela.

Leia o log pela última linha que indica progresso, não a última linha antes do erro. A maioria dos clientes imprime algo como um endereço resolvido, um socket estabelecido, um handshake iniciado ou uma solicitação de autenticação, e a etapa que segue essa linha é a que expirou.

A resolução de nomes falha antes de qualquer contato

Se o endpoint nunca for resolvido, o cliente não tem a que se conectar e nenhum trabalho de transporte ocorreu. Essa falha costuma ser instantânea em vez de um tempo limite completo, o que é a forma mais barata de distingui-la do resto. Teste o nome com o resolvedor do sistema e com um segundo resolvedor, e compare as duas respostas antes de concluir que o servidor está fora do ar.

Um endereço antigo copiado de uma postagem de fórum é uma causa comum de tempo limite que parece problema do servidor, porque o endereço agora pertence a outra coisa ou a nada. Use o perfil atual do operador em vez de substituir um endereço que funcionava antes. A ausência de resposta ao ping não é prova em nenhuma direção: muitos endpoints descartam ICMP e ainda assim atendem muito bem.

A configuração do transporte espera um pacote que não virá

Quando o DNS está bom e o cliente ainda consome todo o tempo limite, a camada de transporte é a suspeita. No TCP você pode testar a porta diretamente; Test-NetConnection no Windows ou nc -vz no Linux diz se algo aceita a conexão, e isso é mais útil que um ping. No UDP não dá para testar da mesma forma, porque nessa camada não há handshake a completar, e essa assimetria provoca muitas conclusões erradas.

O que um teste TCP prova é limitado: um serviço que aceita a porta 443 não é necessariamente o ouvinte VPN, e um endpoint só UDP não tem porta TCP para aceitar nada. Reescrever um perfil de UDP para TCP não cria um ouvinte do outro lado; apenas muda o que seu cliente espera. Se a rede filtra o protocolo, a mudança produz um tempo limite diferente na mesma etapa.

Portais cativos merecem verificação própria nesta etapa. Até o portal autorizar o dispositivo, o tráfego de saída vai para o portal e a tentativa de túnel simplesmente fica pendurada. Conclua o portal no navegador primeiro, tente de novo depois, e não altere o perfil enquanto o portal estiver pendente.

Negociação e login significam que o servidor respondeu

Assim que o túnel chega ao servidor, o cliente inicia um handshake e o erro muda de caráter. Um travamento aqui é de compatibilidade, não de alcance: versões de protocolo incompatíveis, um ajuste de cifra ou canal de dados que o outro lado não aceitará, ou um perfil que espera um recurso que o servidor não oferece. OpenVPN mudou seus padrões de negociação entre versões principais com frequência suficiente para que um perfil escrito para uma geração alcance o servidor e ainda assim não suba.

A autenticação é a última etapa e a mais fácil de ler errado. Uma rejeição explícita é uma resposta, o que significa que o caminho funciona e o problema é a identidade, o certificado ou o estado da conta. Um fluxo de login único baseado em navegador é o terceiro caso: o cliente espera uma ação que você não fez, ou um navegador que não consegue iniciar, e nada chegará até você concluir esse passo.

Compare as evidências antes de mudar a nova tentativa

Mantenha o dispositivo e o perfil fixos e mude uma coisa por vez, começando pela rede. Se o mesmo perfil conecta em um hotspot do celular e expira no Wi-Fi do hotel, a variável é o caminho, não o servidor. Se falha em todo lugar, a variável é o perfil ou o endpoint. Se falha só em um horário do dia, registre o carimbo de tempo e compare com eventos do lado do servidor antes de supor qualquer coisa sobre carga.

Para um serviço que você administra, a comparação decisiva é se a tentativa chega ou não. Uma conexão que alcança o ouvinte e depois trava pertence à etapa de negociação; uma que nunca aparece na visão do ouvinte é problema de transporte ou de resolução, e nenhum ajuste de novas tentativas a moverá. Os logs do servidor também separam um login rejeitado de uma queda silenciosa, que é a diferença entre uma correção de identidade e uma de firewall.

Anote a versão do cliente, o nome do perfil, o horário da tentativa com o fuso horário e o primeiro erro útil em vez da última linha de desconexão. Remova chaves e material com credenciais antes de compartilhar o trecho. Depois faça uma correção significativa e tente de novo, porque um prazo maior só ajuda a operação lenta documentada e não faz nada por um endereço errado ou uma porta bloqueada.