TCP reset ne dokazuje da je vaš VPN blokiran

„Veza resetovana, ponovno pokretanje“ pojavljuje se u klijentskom dnevniku, a zaključak stiže prije dokaza. Neko odluči da mreža blokira VPN, ili da je certifikat pogrešan, ili da se određena zemlja miješa. Reset je TCP paket koji prekida vezu, a linija dnevnika bilježi da je vaš klijent primio jedan. Ona ne imenuje uređaj koji ga je poslao ni razlog slanja.

Reset je paket, a ne presuda

TCP definira obradu reseta: segment sa zastavicom RST odmah prekida vezu. Primalac ne pregovara, ne pokušava ponovo i ne pita zašto. Samo prijavi reset i nastavi.

To je sve što klijent zna. RST je mogao doći sa servera, proxyja, firewall-a ili balansera opterećenja koji je izgubio stanje.

Utvrđivanje porijekla je zasebna vježba. Prividna izvorna adresa u snimku nije dokaz fizičkog porijekla i ne govori ništa o odluci politike iza nje. Posredni uređaji mogu krivotvoriti adrese, a uređaji koji čuvaju stanje mogu resetovati zbog isteka vremena, a ne namjere. Ako reset tretirate kao presudu, preskačete dio u kojem se otkriva istina.

Potvrdite koja je veza resetovana

Prvo provjerite koristi li aktivni profil zaista TCP. Reset na UDP tunelu nema smisla, a dnevnik HTTP proxyja može se odnositi na drugu TCP dionicu od samog VPN-a.

Zabilježite odredište, port, vrijeme pokušaja i fazu do koje je klijent stigao.

Faza je najkorisnije polje. Reset tokom TLS rukovanja upućuje na jedan skup osumnjičenih; reset nakon autentifikacije na drugi. Bez faze svaka teorija odgovara.

Uporedite oba kraja puta

Ako administrirate serverom, uporedite njegove događaje za isti pokušaj. Je li prihvatio vezu? Je li je namjerno zatvorio? Je li odgovor napustio jednu granicu i nikada stigao do sljedeće?

Snimite saobraćaj na klijentu i na serveru ako možete. Reset koji se vidi na klijentu, ali ne na serveru, nije nastao na serveru.

Pazite na RST segmente u oba smjera:

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

Suzite kontroliranim poređenjem

Druga odobrena mreža može vam reći prati li kvar klijenta ili put. Ako isti profil radi drugdje, konfiguracija klijenta je vjerovatno ispravna, a varijabla je put.

To još uvijek ne identificira jedan posredni uređaj. Sužava opseg na rutu, što je koristan i iskren rezultat.

Zadržite razliku između „ovaj put ne uspijeva“ i „ovaj imenovani akter je to prouzrokovao“. Prvo je provjerljivo; drugo obično nije sa jednog klijenta.

Provjerite popravku bez mijenjanja postavki povjerenja

Ne isključujte TLS provjeru, ne regenerirajte vjerodajnice i ne najavljujte politiku blokiranja na osnovu jedne linije reseta. Svaka od tih promjena mijenja sistem koji testirate i čini sljedeće poređenje besmislenim.

Popravite identificiranu komponentu preko njenog vlasnika, zatim ponovite isti profil i isto opažanje:

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

Koristan ishod je bolje lociran kvar, a ne uvjerljivija priča. Ako reset nestane nakon popravke proxyja, imate uzrok. Ako se premjesti na drugu fazu, naučili ste nešto o putu. U svakom slučaju, dokaz treba izdržati čitanje druge osobe. Zapišite šta ste primijetili, a ne šta ste zaključili.