Un reset de TCP non demostra que o teu VPN estea bloqueado

«Conexión restablecida, reiniciando» aparece no rexistro do cliente, e a conclusión chega antes que a evidencia. Alguén decide que a rede bloquea a VPN, ou que o certificado está mal, ou que un país concreto interfire. Un reset é un paquete TCP que remata unha conexión, e a liña do rexistro anota que o teu cliente recibiu un. Non nomea o dispositivo que o enviou nin o motivo.

Un reset é un paquete, non un veredicto

TCP define o procesamento do reset: un segmento coa bandeira RST remata a conexión de inmediato. O receptor non negocia, non reintenta nin pregunta por que. Informa do reset e segue adiante.

Iso é todo o que sabe o cliente. O RST puido vir do servidor, dun proxy, dun cortalumes ou dun balanceador de carga que perdeu o seu estado.

A atribución é un exercicio á parte. Un enderezo de orixe aparente nunha captura non proba a orixe física e non di nada sobre a decisión de política que hai detrás. Os dispositivos intermedios poden falsificar enderezos, e os dispositivos con estado poden reiniciar por tempo de espera en lugar de por intención. Tratar o reset como un veredicto salta a parte na que o descubres.

Confirma que conexión se reiniciou

Primeiro comproba que o perfil activo use realmente TCP. Un reset nun túnel UDP non ten sentido, e un rexistro dun proxy HTTP pode referirse a unha pata TCP distinta da propia VPN.

Anota o destino, o porto, a hora do intento e a etapa á que chegara o cliente.

A etapa é o campo máis útil. Un reset durante o aperto de mans TLS apunta a un conxunto de sospeitosos; un reset despois da autenticación apunta a outro. Sen a etapa, todas as teorías encaixan.

Compara os dous extremos da ruta

Se administras o servidor, compara os seus eventos para o mesmo intento. Aceptou a conexión? Pechouna deliberadamente? Unha resposta saíu dun límite e nunca chegou ao seguinte?

Captura no cliente e no servidor se podes. Un reset que aparece no cliente pero non no servidor non se orixinou no servidor.

Vixía os segmentos RST nas dúas direccións:

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

Acouta cunha comparación controlada

Unha segunda rede aprobada pode dicirche se o fallo segue o cliente ou a ruta. Se o mesmo perfil funciona noutro sitio, a configuración do cliente probablemente está ben e a variable é a ruta.

Iso aínda non identifica un dispositivo intermedio concreto. Reduce o alcance a unha ruta, que é un resultado útil e honesto.

Mantén a distinción entre «esta ruta falla» e «este actor con nome causouno». A primeira é comprobable; a segunda normalmente non desde un só cliente.

Comproba a solución sen cambiar a configuración de confianza

Non desactives a verificación TLS, non rexeneres credenciais nin anuncios unha política de bloqueo a partir dunha liña de reset. Cada un deses cambios altera o sistema que probas e fai que a seguinte comparación non signifique nada.

Corrixe o compoñente identificado a través do seu propietario e logo repite o mesmo perfil e a mesma observación:

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

O resultado útil é un fallo mellor localizado, non unha historia máis segura. Se o reset desaparece tras corrixir o proxy, tes unha causa. Se se traslada a outra etapa, aprendiches algo sobre a ruta. En calquera caso, a evidencia debería sobrevivir á lectura dunha segunda persoa. Escribe o que observaches, non o que concluíches.