Un reset TCP nu dovedește că VPN-ul tău este blocat

„Conexiune resetată, se repornește” apare în jurnalul clientului, iar concluzia vine înaintea dovezii. Cineva decide că rețeaua blochează VPN-ul, sau că certificatul este greșit, sau că o anumită țară intervine. Un reset este un pachet TCP care încheie o conexiune, iar linia din jurnal notează că clientul tău a primit unul. Ea nu numește dispozitivul care l-a trimis și nici motivul.

Un reset este un pachet, nu o sentință

TCP definește procesarea resetului: un segment cu steagul RST încheie conexiunea imediat. Receptorul nu negociază, nu reîncearcă și nu întreabă de ce. Raportează resetul și merge mai departe.

Atât știe clientul. RST-ul poate să fi venit de la server, de la un proxy, de la un firewall sau de la un balansator de încărcare care și-a pierdut starea.

Atribuirea este un exercițiu separat. O adresă de sursă aparentă într-o captură nu dovedește originea fizică și nu spune nimic despre decizia de politică din spate. Dispozitivele intermediare pot falsifica adrese, iar dispozitivele cu stare pot reseta din cauza expirării, nu a intenției. A trata resetul ca pe o sentință sare peste partea în care afli adevărul.

Confirmă ce conexiune a fost resetată

Verifică mai întâi dacă profilul activ folosește într-adevăr TCP. Un reset pe un tunel UDP nu are sens, iar un jurnal de la un proxy HTTP poate privi un alt segment TCP decât VPN-ul propriu-zis.

Notează destinația, portul, momentul încercării și etapa la care ajunsese clientul.

Etapa este cel mai util câmp. Un reset în timpul strângerii de mână TLS indică un set de suspecți; un reset după autentificare indică altul. Fără etapă, orice teorie se potrivește.

Compară ambele capete ale căii

Dacă administrezi serverul, compară evenimentele lui pentru aceeași încercare. A acceptat conexiunea? A închis-o intenționat? Un răspuns a părăsit o graniță și nu a ajuns niciodată la următoarea?

Capturează la client și la server dacă poți. Un reset care apare la client dar nu la server nu a luat naștere la server.

Urmărește segmentele RST în ambele direcții:

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

Restrânge cu o comparație controlată

O a doua rețea aprobată îți poate spune dacă defecțiunea urmează clientul sau calea. Dacă același profil funcționează în altă parte, configurația clientului este probabil în regulă, iar variabila este calea.

Asta încă nu identifică un singur dispozitiv intermediar. Restrânge domeniul la o rută, ceea ce este un rezultat util și onest.

Păstrează distincția dintre această cale eșuează și acest actor numit a cauzat-o. Prima este testabilă; a doua de obicei nu este de la un singur client.

Verifică remedierea fără a schimba setările de încredere

Nu dezactiva verificarea TLS, nu regenera acreditările și nu anunța o politică de blocare pornind de la o singură linie de reset. Fiecare dintre aceste schimbări modifică sistemul testat și face următoarea comparație lipsită de sens.

Remediază componenta identificată prin proprietarul ei, apoi repetă același profil și aceeași observație:

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

Rezultatul util este o defecțiune mai bine localizată, nu o poveste mai sigură. Dacă resetul dispare după o remediere a proxy-ului, ai o cauză. Dacă se mută într-o altă etapă, ai învățat ceva despre cale. În orice caz, dovada ar trebui să supraviețuiască citirii de către o a doua persoană. Notează ce ai observat, nu ce ai concluzionat.