Ponastavitev TCP ne dokazuje, da je vaš VPN blokiran

V dnevniku odjemalca se pojavi »povezava ponastavljena, znova zaganjam«, in sklep pride pred dokazom. Nekdo se odloči, da omrežje blokira VPN, ali da je potrdilo napačno, ali da se neka država vmešava. Ponastavitev je paket TCP, ki konča povezavo, in vrstica dnevnika zabeleži, da je vaš odjemalec prejel enega. Ne navaja naprave, ki ga je poslala, niti razloga.

Ponastavitev je paket, ne sodba

TCP določa obdelavo ponastavitve: segment z zastavico RST takoj konča povezavo. Prejemnik se ne pogaja, ne poskuša znova in ne sprašuje zakaj. Sporoči ponastavitev in gre naprej.

To je vse, kar odjemalec ve. RST je lahko prišel s strežnika, iz posrednika, z požarnega zidu ali iz porazdeljevalnika obremenitve, ki je izgubil stanje.

Ugotavljanje izvora je ločena vaja. Navidezni izvorni naslov v zajemu ni dokaz fizičnega izvora in ne pove ničesar o odločitvi politike za njim. Vmesne naprave lahko ponaredijo naslove, naprave s stanjem pa lahko ponastavijo zaradi časovne omejitve in ne namerno. Če ponastavitev obravnavate kot sodbo, preskočite del, v katerem to ugotovite.

Potrdite, katera povezava je bila ponastavljena

Najprej preverite, ali aktivni profil res uporablja TCP. Ponastavitev v tunelu UDP nima smisla, dnevnik posrednika HTTP pa se lahko nanaša na drug del TCP kot sam VPN.

Zapišite cilj, vrata, čas poskusa in fazo, do katere je prišel odjemalec.

Faza je najbolj uporabno polje. Ponastavitev med rokovanjem TLS kaže na eno skupino osumljencev; ponastavitev po preverjanju pristnosti na drugo. Brez faze ustreza vsaka teorija.

Primerjajte oba konca poti

Če upravljate strežnik, primerjajte njegove dogodke za isti poskus. Je sprejel povezavo? Jo je namerno zaprl? Je odgovor zapustil eno mejo in nikoli ni prispel na naslednjo?

Zajemajte pri odjemalcu in pri strežniku, če lahko. Ponastavitev, ki se pojavi pri odjemalcu, ne pa pri strežniku, ni nastala pri strežniku.

Bodite pozorni na segmente RST v obeh smereh:

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

Zožite s kontrolirano primerjavo

Drugo odobreno omrežje vam lahko pove, ali napaka sledi odjemalcu ali poti. Če isti profil deluje drugje, je konfiguracija odjemalca verjetno v redu, spremenljivka pa je pot.

To še vedno ne prepozna ene konkretne vmesne naprave. Zoži obseg na pot, kar je koristen in pošten rezultat.

Ohranite razliko med »ta pot odpove« in »ta imenovani akter je to povzročil«. Prvo je mogoče preizkusiti; drugega običajno ne z enega odjemalca.

Preverite popravek brez spreminjanja nastavitev zaupanja

Ne izklopite preverjanja TLS, ne ustvarite znova poverilnic in ne objavite politike blokiranja na podlagi ene vrstice ponastavitve. Vsaka od teh sprememb spremeni testirani sistem in naredi naslednjo primerjavo nesmiselno.

Popravite prepoznano komponento prek njenega lastnika, nato ponovite isti profil in isto opažanje:

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

Koristen rezultat je bolje lokalizirana napaka, ne bolj samozavestna zgodba. Če ponastavitev izgine po popravku posrednika, imate vzrok. Če se premakne v drugo fazo, ste se o poti nekaj naučili. Kakor koli, dokaz bi moral prestati branje druge osebe. Zapišite, kaj ste opazili, ne kaj ste sklenili.