Një reset TCP nuk provon se VPN-ja juaj po bllokohet

«Lidhja u rivendos, po rinis» shfaqet në regjistrin e klientit, dhe përfundimi vjen para provës. Dikush vendos që rrjeti po bllokon VPN-në, ose që certifikata është e gabuar, ose që një vend i caktuar po ndërhyn. Një reset është një paketë TCP që përfundon një lidhje, dhe rreshti i regjistrit shënon se klienti juaj pranoi një. Ai nuk emërton pajisjen që e dërgoi dhe as arsyen.

Një reset është paketë, jo verdikt

TCP përcakton përpunimin e reset-it: një segment me flamurin RST përfundon lidhjen menjëherë. Marrësi nuk negocion, nuk provon përsëri dhe nuk pyet pse. Ai raporton reset-in dhe vazhdon.

Kjo është gjithçka që di klienti. RST mund të ketë ardhur nga serveri, një proxy, një firewall ose një balancues ngarkese që humbi gjendjen.

Përcaktimi i origjinës është ushtrim më vete. Një adresë burimore e dukshme në një kapje nuk është provë e origjinës fizike dhe nuk thotë asgjë për vendimin e politikës pas saj. Pajisjet e ndërmjetme mund të falsifikojnë adresa, dhe pajisjet me gjendje mund të rivendosin për shkak të skadimit të kohës dhe jo me qëllim. Trajtimi i reset-it si verdikt anashkalon pjesën ku e zbuloni të vërtetën.

Konfirmoni cila lidhje u rivendos

Fillimisht kontrolloni nëse profili aktiv përdor vërtet TCP. Një reset në një tunel UDP nuk ka kuptim, dhe regjistri i një proxy HTTP mund të ketë të bëjë me një këmbë TCP të ndryshme nga vetë VPN-ja.

Shënoni destinacionin, portën, kohën e provës dhe fazën ku kishte arritur klienti.

Faza është fusha më e dobishme. Një reset gjatë shtrëngimit të duarve TLS tregon një grup të dyshuarish; një reset pas vërtetimit tregon një tjetër. Pa fazën, çdo teori përshtatet.

Krahasoni të dy skajet e rrugës

Nëse administroni serverin, krahasoni ngjarjet e tij për të njëjtën provë. A e pranoi lidhjen? A e mbylli me qëllim? A doli një përgjigje nga një kufi dhe nuk arriti kurrë në tjetrin?

Kapni te klienti dhe te serveri nëse mundeni. Një reset që shfaqet te klienti por jo te serveri nuk e ka origjinën te serveri.

Vëzhgoni segmentet RST në të dy drejtimet:

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

Ngushtoni me një krahasim të kontrolluar

Një rrjet i dytë i miratuar mund t'ju thotë nëse dështimi ndjek klientin apo rrugën. Nëse i njëjti profil funksionon diku tjetër, konfigurimi i klientit ndoshta është në rregull dhe variabla është rruga.

Kjo ende nuk identifikon një pajisje të vetme të ndërmjetme. Kufizon shtrirjen në një rrugë, që është një rezultat i dobishëm dhe i ndershëm.

Mbajeni dallimin midis kjo rrugë dështon dhe ky aktor i emërtuar e shkaktoi. E para është e testueshme; e dyta zakonisht jo nga një klient i vetëm.

Verifikoni rregullimin pa ndryshuar cilësimet e besimit

Mos çaktivizoni verifikimin TLS, mos rigjeneroni kredencialet dhe mos shpallni një politikë bllokimi nga një rresht i vetëm reset-i. Secili prej këtyre ndryshimeve ndryshon sistemin në provë dhe e bën krahasimin e radhës të pakuptimtë.

Rregulloni komponentin e identifikuar përmes pronarit të tij, pastaj përsëritni të njëjtin profil dhe të njëjtin vëzhgim:

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

Rezultati i dobishëm është një dështim më i lokalizuar, jo një histori më e sigurt. Nëse reset-i zhduket pas një rregullimi të proxy-t, keni një shkak. Nëse kalon në një fazë tjetër, keni mësuar diçka për rrugën. Në çdo rast, prova duhet t'i mbijetojë leximit nga një person i dytë. Shkruani atë që vëzhguat, jo atë që konkluduat.