Um reset de TCP não prova que a sua VPN está bloqueada

«Ligação redefinida, a reiniciar» aparece no registo do cliente, e a conclusão chega antes da prova. Alguém decide que a rede bloqueia a VPN, ou que o certificado está errado, ou que um determinado país está a interferir. Um reset é um pacote TCP que encerra uma ligação, e a linha do registo anota que o seu cliente recebeu um. Não nomeia o dispositivo que o enviou nem o motivo.

Um reset é um pacote, não um veredicto

O TCP define o processamento do reset: um segmento com o sinalizador RST encerra a ligação imediatamente. O recetor não negoceia, não tenta de novo e não pergunta porquê. Limita-se a reportar o reset e a seguir em frente.

É tudo o que o cliente sabe. O RST pode ter vindo do servidor, de um proxy, de uma firewall ou de um balanceador de carga que perdeu o estado.

A atribuição é um exercício separado. Um endereço de origem aparente numa captura não prova a origem física e não diz nada sobre a decisão de política por trás. Os dispositivos intermédios podem falsificar endereços, e os dispositivos com estado podem repor por tempo limite em vez de por intenção. Tratar o reset como um veredicto salta a parte em que se descobre a verdade.

Confirme qual ligação foi reposta

Primeiro verifique se o perfil ativo usa realmente TCP. Um reset num túnel UDP não faz sentido, e um registo de um proxy HTTP pode dizer respeito a uma perna TCP diferente da própria VPN.

Anote o destino, a porta, a hora da tentativa e a fase a que o cliente tinha chegado.

A fase é o campo mais útil. Um reset durante o handshake TLS aponta para um conjunto de suspeitos; um reset após a autenticação aponta para outro. Sem a fase, todas as teorias encaixam.

Compare as duas pontas do caminho

Se administra o servidor, compare os eventos dele para a mesma tentativa. Aceitou a ligação? Fechou-a deliberadamente? Uma resposta saiu de uma fronteira e nunca chegou à seguinte?

Capture no cliente e no servidor se puder. Um reset que aparece no cliente mas não no servidor não se originou no servidor.

Fique atento aos segmentos RST nas duas direções:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Restrinja com uma comparação controlada

Uma segunda rede aprovada pode dizer-lhe se a falha segue o cliente ou o caminho. Se o mesmo perfil funcionar noutro local, a configuração do cliente está provavelmente bem e a variável é o caminho.

Isso ainda não identifica um dispositivo intermédio concreto. Restringe o âmbito a uma rota, o que é um resultado útil e honesto.

Mantenha a distinção entre «este caminho falha» e «este ator nomeado causou-o». O primeiro é testável; o segundo normalmente não é a partir de um único cliente.

Verifique a correção sem alterar as definições de confiança

Não desative a verificação TLS, não regenere credenciais e não anuncie uma política de bloqueio a partir de uma linha de reset. Cada uma dessas alterações muda o sistema em teste e torna a comparação seguinte sem sentido.

Corrija o componente identificado através do seu proprietário e depois repita o mesmo perfil e a mesma observação:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

O resultado útil é uma falha melhor localizada, não uma história mais segura. Se o reset desaparecer após uma correção do proxy, tem uma causa. Se se deslocar para outra fase, aprendeu algo sobre o caminho. De qualquer forma, a prova deve sobreviver à leitura de uma segunda pessoa. Escreva o que observou, não o que concluiu.