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

V klientském logu se objeví „spojení resetováno, restartuji“ a závěr přichází dřív než důkaz. Někdo rozhodne, že síť blokuje VPN, nebo že certifikát je špatný, nebo že určitá země zasahuje. Reset je paket TCP, který ukončí spojení, a řádek logu zaznamenává, že váš klient jeden dostal. Neuvádí zařízení, které ho poslalo, ani důvod.

Reset je paket, ne verdikt

TCP definuje zpracování resetu: segment s příznakem RST okamžitě ukončí spojení. Příjemce nevyjednává, neopakuje pokus ani se neptá proč. Oznámí reset a jde dál.

To je vše, co klient ví. RST mohl přijít ze serveru, z proxy, z firewallu nebo z vyvažovače zátěže, který ztratil stav.

Určení původu je samostatná disciplína. Zdánlivá zdrojová adresa v zachyceném provozu není důkazem fyzického původu a neříká nic o politickém rozhodnutí za ním. Mezilehlá zařízení mohou podvrhnout adresy a stavová zařízení mohou resetovat při vypršení časovače, ne záměrně. Když reset berete jako verdikt, přeskakujete část, ve které se to zjišťuje.

Ověřte, které spojení bylo resetováno

Nejprve zkontrolujte, zda aktivní profil skutečně používá TCP. Reset na tunelu UDP nedává smysl a log z proxy HTTP se může týkat jiné nohy TCP než samotné VPN.

Zapište cíl, port, čas pokusu a fázi, do které se klient dostal.

Fáze je nejužitečnější pole. Reset během TLS handshaku ukazuje na jednu skupinu podezřelých; reset po autentizaci na jinou. Bez fáze sedí každá teorie.

Porovnejte oba konce cesty

Pokud server spravujete, porovnejte jeho události pro stejný pokus. Přijal spojení? Uzavřel ho záměrně? Odešla odpověď z jedné hranice a nikdy nedorazila na další?

Zachycujte u klienta i u serveru, pokud můžete. Reset, který se objeví u klienta, ale ne u serveru, nevznikl na serveru.

Sledujte segmenty RST v obou směrech:

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

Zužte to řízeným srovnáním

Druhá schválená síť vám může říct, zda selhání sleduje klienta, nebo cestu. Pokud stejný profil funguje jinde, konfigurace klienta je pravděpodobně v pořádku a proměnnou je cesta.

To stále neidentifikuje konkrétní mezilehlé zařízení. Zužuje rozsah na trasu, což je užitečný a poctivý výsledek.

Zachovejte rozdíl mezi „tato cesta selhává“ a „tento pojmenovaný aktér to způsobil“. První je testovatelné; druhé obvykle z jednoho klienta ne.

Ověřte opravu bez změny nastavení důvěry

Nevypínejte ověřování TLS, negenerujte znovu přihlašovací údaje a neoznamujte politiku blokování na základě jednoho řádku resetu. Každá z těchto změn mění testovaný systém a činí další srovnání bezvýznamným.

Opravte identifikovanou komponentu přes jejího vlastníka, potom zopakujte stejný profil a stejné pozorování:

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

Užitečným výsledkem je lépe lokalizované selhání, ne sebevědomější příběh. Pokud reset po opravě proxy zmizí, máte příčinu. Pokud se přesune do jiné fáze, naučili jste se něco o cestě. Ať tak či onak, důkaz by měl přežít čtení druhým člověkem. Zapište, co jste pozorovali, ne co jste uzavřeli.