Reset TCP nedokazuje, že je vaša VPN blokovaná

V klientskom logu sa objaví „spojenie resetované, reštartujem“ a záver prichádza skôr než dôkaz. Niekto rozhodne, že sieť blokuje VPN, alebo že certifikát je nesprávny, alebo že určitá krajina zasahuje. Reset je paket TCP, ktorý ukončí spojenie, a riadok logu zaznamenáva, že váš klient jeden dostal. Neuvádza zariadenie, ktoré ho poslalo, ani dôvod.

Reset je paket, nie verdikt

TCP definuje spracovanie resetu: segment s príznakom RST okamžite ukončí spojenie. Príjemca nevyjednáva, neopakuje pokus ani sa nepýta prečo. Oznámi reset a ide ďalej.

To je všetko, čo klient vie. RST mohol prísť zo servera, z proxy, z firewallu alebo z vyvažovača záťaže, ktorý stratil stav.

Určenie pôvodu je samostatná disciplína. Zdánlivá zdrojová adresa v zachytenej komunikácii nie je dôkazom fyzického pôvodu a nehovorí nič o politickom rozhodnutí za ňou. Medziľahlé zariadenia môžu podvrhnúť adresy a stavové zariadenia môžu resetovať pri vypršaní časovača, nie zámerne. Keď reset beriete ako verdikt, preskakujete časť, v ktorej sa to zisťuje.

Overte, ktoré spojenie bolo resetované

Najprv skontrolujte, či aktívny profil skutočne používa TCP. Reset na tuneli UDP nemá zmysel a log z proxy HTTP sa môže týkať inej nohy TCP než samotnej VPN.

Zapíšte cieľ, port, čas pokusu a fázu, do ktorej sa klient dostal.

Fáza je najužitočnejšie pole. Reset počas TLS handshake ukazuje na jednu skupinu podozrivých; reset po autentifikácii na inú. Bez fázy sedí každá teória.

Porovnajte oba konce cesty

Ak server spravujete, porovnajte jeho udalosti pre ten istý pokus. Prijal spojenie? Uzavrel ho zámerne? Odišla odpoveď z jednej hranice a nikdy nedorazila na ďalšiu?

Zachytávajte u klienta aj u servera, ak môžete. Reset, ktorý sa objaví u klienta, ale nie u servera, nevznikol na serveri.

Sledujte segmenty RST v oboch smeroch:

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

Zúžte to riadeným porovnaním

Druhá schválená sieť vám môže povedať, či zlyhanie sleduje klienta alebo cestu. Ak ten istý profil funguje inde, konfigurácia klienta je pravdepodobne v poriadku a premennou je cesta.

To stále neidentifikuje konkrétne medziľahlé zariadenie. Zužuje rozsah na trasu, čo je užitočný a poctivý výsledok.

Zachovajte rozdiel medzi „táto cesta zlyháva“ a „tento pomenovaný aktér to spôsobil“. Prvé je testovateľné; druhé zvyčajne z jedného klienta nie.

Overte opravu bez zmeny nastavení dôvery

Nevypínajte overovanie TLS, negenerujte znova prihlasovacie údaje a neoznamujte politiku blokovania na základe jedného riadku resetu. Každá z týchto zmien mení testovaný systém a robí ďalšie porovnanie bezvýznamným.

Opravte identifikovaný komponent cez jeho vlastníka, potom zopakujte ten istý profil a to isté pozorovanie:

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

Užitočným výsledkom je lepšie lokalizované zlyhanie, nie sebavedomejší príbeh. Ak reset po oprave proxy zmizne, máte príčinu. Ak sa presunie do inej fázy, naučili ste sa niečo o ceste. Tak či onak, dôkaz by mal prežiť čítanie druhým človekom. Zapíšte, čo ste pozorovali, nie čo ste uzavreli.