TCP atiestatīšana nepierāda, ka jūsu VPN tiek bloķēts

Klienta žurnālā parādās „savienojums atiestatīts, restartē“ un secinājums nāk pirms pierādījuma. Kāds nolemj, ka tīkls bloķē VPN, vai ka sertifikāts ir nepareizs, vai ka konkrēta valsts iejūkas. Atiestatīšana ir TCP pakete, kas izbeidz savienojumu, un žurnāla rinda fiksē, ka jūsu klients tādu saņēma. Tā nenosauc nosūtītāju ierīci nedz iemeslu.

Atiestatīšana ir pakete, nevis spriedums

TCP nosaka atiestatīšanas apstrādi: segments ar RST karodziņu nekavējoties izbeidz savienojumu. Uztvērējs nesaskaņo, necenšas vēlreiz un nejautā kāpēc. Tas ziņo par atiestatīšanu un turpina.

Tas ir viss, ko klients zina. RST varēja nākt no servera, starpniekservera, ugunsmūra vai slodzes balansētāja, kas zaudēja stāvokli.

Izcelsmes noteikšana ir atsevišķs vingrinājums. Šķietamā avota adrese ierakstā nav fiziskās izcelsmes pierādījums un neko neizsaka par politiku lēmumu aiz tās. Starpierīces var viltot adreses, un ierīces ar stāvokli var atiestatīt noildzes dēļ, nevis tīši. Ja atiestatīšanu uzskatāt par spriedumu, jūs izlaižat daļu, kurā noskaidro patiesību.

Apstipriniet, kurš savienojums tika atiestatīts

Vispirms pārbaudiet, vai aktīvais profils patiešām izmanto TCP. Atiestatīšana UDP tunelī nav jēgas, un HTTP starpniekservera žurnāls var attiekties uz citu TCP posmu nekā pats VPN.

Ierakstiet galamērķi, portu, mēģinājuma laiku un posmu, kuru klients bija sasniedzis.

Posms ir visnoderīgākais lauks. Atiestatīšana TLS rokasspiediena laikā norāda uz vienu aizdomās turamo grupu; atiestatīšana pēc autentifikācijas — uz citu. Bez posma der jebkura teorija.

Salīdziniet abus ceļa galus

Ja pārvaldāt serveri, salīdziniet tā notikumus tam pašam mēģinājumam. Vai tas pieņēma savienojumu? Vai tas to apzināti aizvēra? Vai atbilde pameta vienu robežu un nekad nesasniedza nākamo?

Ja varat, ierakstiet klientā un serverī. Atiestatīšana, kas redzama klientā, bet ne serverī, nav radusies serverī.

Uzmaniet RST segmentus abos virzienos:

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

Sašauriniet ar kontrolētu salīdzinājumu

Otrs apstiprināts tīkls var pateikt, vai kļūme seko klientam vai ceļam. Ja tas pats profils darbojas citur, klienta konfigurācija, visticamāk, ir kārtībā, un mainīgais ir ceļš.

Tas joprojām neidentificē vienu konkrētu starpierīci. Tas sašaurina tvērumu līdz maršrutam, kas ir noderīgs un godīgs rezultāts.

Saglabājiet atšķirību starp „šis ceļš neizdodas“ un „šis nosauktais dalībnieks to izraisīja“. Pirmais ir pārbaudāms; otrais parasti nav no viena klienta.

Pārbaudiet labojumu, nemainot uzticēšanās iestatījumus

Neizslēdziet TLS pārbaudi, neģenerējiet no jauna akreditācijas datus un nepaziņojiet bloķēšanas politiku, pamatojoties uz vienu atiestatīšanas rindu. Katrs no šiem grozījumiem maina pārbaudāmo sistēmu un padara nākamo salīdzinājumu bezjēdzīgu.

Izlabojiet identificēto komponentu caur tā īpašnieku, pēc tam atkārtojiet to pašu profilu un to pašu novērojumu:

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

Noderīgs rezultāts ir labāk lokalizēta kļūme, nevis pārliecinātāks stāsts. Ja atiestatīšana pazūd pēc starpniekservera labojuma, jums ir cēlonis. Ja tā pārvietojas uz citu posmu, jūs uzzinājāt kaut ko par ceļu. Jebkurā gadījumā pierādījumam vajadzētu izturēt otra cilvēka lasījumu. Pierakstiet, ko novērojāt, nevis ko secinājāt.