Un reset de TCP no demostra que el teu VPN estigui bloquejat

«Connexió reiniciada, s’està reiniciant» apareix al registre del client, i la conclusió arriba abans que l’evidència. Algú decideix que la xarxa bloqueja la VPN, o que el certificat és incorrecte, o que un país concret hi intervé. Un reset és un paquet TCP que acaba una connexió, i la línia del registre anota que el teu client n’ha rebut un. No diu quin dispositiu el va enviar ni per què.

Un reset és un paquet, no un veredicte

TCP defineix el processament del reset: un segment amb el flag RST acaba la connexió immediatament. El receptor no negocia, no reintenta ni pregunta per què. Informa del reset i continua.

Això és tot el que sap el client. El RST pot haver vingut del servidor, d’un proxy, d’un tallafoc o d’un balancejador de càrrega que ha perdut l’estat.

L’atribució és un exercici a part. Una adreça d’origen aparent en una captura no és prova de l’origen físic, i no diu res de la decisió de política que hi ha al darrere. Els dispositius intermedis poden falsificar adreces, i els dispositius amb estat poden reiniciar per temps d’espera més que per intenció. Tractar el reset com un veredicte se salta la part en què ho esbrines.

Confirma quina connexió s’ha reiniciat

Primer comprova que el perfil actiu faci servir realment TCP. Un reset en un túnel UDP no té sentit, i un registre d’un proxy HTTP pot referir-se a una pota TCP diferent de la mateixa VPN.

Anota la destinació, el port, l’hora de l’intent i l’etapa a què havia arribat el client.

L’etapa és el camp més útil. Un reset durant l’apretada de mans TLS assenyala un conjunt de sospitosos; un reset després de l’autenticació n’assenyala un altre. Sense l’etapa, totes les teories encaixen.

Compara els dos extrems del camí

Si administres el servidor, compara-ne els esdeveniments per al mateix intent. Va acceptar la connexió? La va tancar deliberadament? Una resposta va sortir d’una frontera i no va arribar mai a la següent?

Captura al client i al servidor si pots. Un reset que apareix al client però no al servidor no es va originar al servidor.

Vigila els segments RST en les dues direccions:

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

Estreny amb una comparació controlada

Una segona xarxa aprovada et pot dir si la fallada segueix el client o el camí. Si el mateix perfil funciona en un altre lloc, la configuració del client probablement és correcta i la variable és el camí.

Això encara no identifica un dispositiu intermedi concret. Redueix l’abast a una ruta, que és un resultat útil i honest.

Mantén la distinció entre «aquest camí falla» i «aquest actor anomenat ho ha causat». La primera és comprovable; la segona normalment no ho és des d’un sol client.

Comprova la solució sense canviar la configuració de confiança

No desactivis la verificació TLS, no regeneris credencials ni anunciïs una política de bloqueig a partir d’una línia de reset. Cadascun d’aquests canvis modifica el sistema que proves i fa que la comparació següent no tingui sentit.

Arregla el component identificat a través del seu propietari, i després repeteix el mateix perfil i la mateixa observació:

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

El resultat útil és una fallada millor localitzada, no una història més segura. Si el reset desapareix després d’arreglar el proxy, tens una causa. Si es mou a una altra etapa, has après alguna cosa del camí. En qualsevol cas, l’evidència hauria de sobreviure a la lectura d’una segona persona. Escriu què has observat, no què has conclòs.