A TCP-visszaállítás nem bizonyítja, hogy a VPN-ed blokkolva van

A kliensnaplóban megjelenik a „kapcsolat visszaállítva, újraindítás“, és a következtetés a bizonyíték előtt érkezik. Valaki eldönti, hogy a hálózat blokkolja a VPN-t, vagy hogy a tanúsítvány hibás, vagy hogy egy adott ország beavatkozik. A visszaállítás egy TCP-csomag, amely lezár egy kapcsolatot, és a naplósor rögzíti, hogy a kliense kapott egyet. Nem nevezi meg a küldő eszközt és az okot sem.

A visszaállítás csomag, nem ítélet

A TCP meghatározza a visszaállítás kezelését: az RST jelzővel ellátott szegmens azonnal lezárja a kapcsolatot. A fogadó nem tárgyal, nem próbálkozik újra, és nem kérdez miért. Jelenti a visszaállítást, és továbbhalad.

Ennyit tud a kliens. Az RST jöhetett a szerverről, egy proxyról, egy tűzfalról vagy egy állapotát vesztett terheléselosztóról.

Az eredet megállapítása külön gyakorlat. A csomagrögzítésben látszó forráscím nem bizonyítja a fizikai eredetet, és semmit sem mond a mögötte álló szakpolitikai döntésről. A köztes eszközök hamisíthatnak címeket, az állapottal rendelkező eszközök pedig időtúllépés miatt is visszaállíthatnak, nem szándékból. Ha a visszaállítást ítéletként kezeled, kihagyod azt a részt, ahol kideríted az igazat.

Erősítsd meg, melyik kapcsolat állt vissza

Először ellenőrizd, hogy az aktív profil valóban TCP-t használ. UDP-alagúton a visszaállításnak nincs értelme, és egy HTTP-proxy naplója a VPN-től eltérő TCP-szakaszra vonatkozhat.

Jegyezd fel a célt, a portot, a kísérlet idejét és azt a szakaszt, amelyig a kliens eljutott.

A szakasz a leghasznosabb mező. A TLS-kézfogás közbeni visszaállítás egy gyanúsított csoportra mutat; a hitelesítés utáni visszaállítás egy másikra. Szakasz nélkül minden elmélet illik.

Hasonlítsd össze az útvonal két végét

Ha te adminisztrálod a szervert, hasonlítsd össze az eseményeit ugyanarra a kísérletre. Elfogadta a kapcsolatot? Szándékosan zárta le? Egy válasz elhagyott egy határt, és soha nem ért el a következőhöz?

Rögzíts a kliensnél és a szervernél, ha tudsz. Az a visszaállítás, amely a kliensnél látszik, de a szervernél nem, nem a szerveren keletkezett.

Figyeld az RST-szegmenseket mindkét irányban:

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

Szűkíts ellenőrzött összehasonlítással

Egy második jóváhagyott hálózat megmondhatja, hogy a hiba a klienst vagy az útvonalat követi-e. Ha ugyanaz a profil máshol működik, a kliens beállítása valószínűleg rendben van, és a változó az útvonal.

Ez még mindig nem azonosít egyetlen köztes eszközt. A hatókört egy útvonalra szűkíti, ami hasznos és őszinte eredmény.

Tartsd meg a különbséget aközött, hogy ez az útvonal meghiúsul, és aközött, hogy ez a megnevezett szereplő okozta. Az első tesztelhető; a második általában nem egyetlen kliensről.

Ellenőrizd a javítást a bizalmi beállítások módosítása nélkül

Ne kapcsold ki a TLS-ellenőrzést, ne generáld újra a hitelesítő adatokat, és ne hirdess blokkolási szabályzatot egyetlen visszaállítási sor alapján. Ezek a változtatások mindegyike módosítja a tesztelt rendszert, és értelmetlenné teszi a következő összehasonlítást.

Javítsd ki az azonosított összetevőt a tulajdonosán keresztül, majd ismételd meg ugyanazt a profilt és ugyanazt a megfigyelést:

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

A hasznos eredmény egy jobban lokalizált hiba, nem egy magabiztosabb történet. Ha a visszaállítás eltűnik egy proxy javítása után, van okod. Ha egy másik szakaszra vált, tanultál valamit az útvonalról. Akárhogy is, a bizonyítéknak ki kell bírnia egy második ember olvasását. Azt írd le, amit megfigyeltél, nem azt, amire következtettél.