TCP atstatymas neįrodo, kad jūsų VPN blokuojamas

Kliento žurnale pasirodo „ryšys atstatytas, paleidžiama iš naujo“, ir išvada ateina prieš įrodymą. Kažkas nusprendžia, kad tinklas blokuoja VPN, arba kad sertifikatas neteisingas, arba kad tam tikra šalis kišasi. Atstatymas yra TCP paketas, užbaigiantis ryšį, o žurnalo eilutė užfiksuoja, kad jūsų klientas tokį gavo. Ji neįvardija išsiuntusio įrenginio nei priežasties.

Atstatymas yra paketas, o ne nuosprendis

TCP apibrėžia atstatymo apdorojimą: segmentas su RST vėliavėle iš karto užbaigia ryšį. Gavėjas nesidera, nebandai iš naujo ir neklausia kodėl. Jis praneša apie atstatymą ir juda toliau.

Tai viskas, ką klientas žino. RST galėjo ateiti iš serverio, tarpinio serverio, užkardos arba apkrovos balansuotojo, kuris prarado būseną.

Kilmės nustatymas yra atskiras pratimas. Matomas šaltinio adresas įraše neįrodo fizinės kilmės ir nieko nesako apie politikos sprendimą, esantį už jo. Tarpiniai įrenginiai gali klastoti adresus, o būseną turintys įrenginiai gali atstatyti dėl laiko limito, o ne tyčia. Jei atstatymą laikote nuosprendžiu, praleidžiate dalį, kurioje išsiaiškinama tiesa.

Patvirtinkite, kuris ryšys buvo atstatytas

Pirmiausia patikrinkite, ar aktyvus profilis tikrai naudoja TCP. Atstatymas UDP tunelyje neturi prasmės, o HTTP tarpinio serverio žurnalas gali būti apie kitą TCP atkarpą nei pats VPN.

Užrašykite paskirties vietą, prievadą, bandymo laiką ir etapą, kurį klientas pasiekė.

Etapas yra naudingiausias laukas. Atstatymas TLS rankos paspaudimo metu nurodo vieną įtariamųjų grupę; atstatymas po autentifikavimo – kitą. Be etapo tinka bet kuri teorija.

Palyginkite abu kelio galus

Jei administruojate serverį, palyginkite jo įvykius tam pačiam bandymui. Ar jis priėmė ryšį? Ar jis sąmoningai jį uždarė? Ar atsakymas paliko vieną ribą ir niekada nepasiekė kitos?

Jei galite, fiksuokite kliente ir serveryje. Atstatymas, matomas kliente, bet ne serveryje, neatsirado serveryje.

Stebėkite RST segmentus abiem kryptimis:

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

Susiaurinkite kontroliuojamu palyginimu

Antras patvirtintas tinklas gali pasakyti, ar gedimas seka klientą, ar kelią. Jei tas pats profilis veikia kitur, kliento konfigūracija tikriausiai tvarkinga, o kintamasis yra kelias.

Tai vis dar neidentifikuoja vieno konkretaus tarpinio įrenginio. Tai susiaurina apimtį iki maršruto, o tai naudingas ir sąžiningas rezultatas.

Išlaikykite skirtumą tarp „šis kelias nepavyksta“ ir „šis įvardytas veikėjas tai sukėlė“. Pirmasis yra patikrinamas; antrasis paprastai ne iš vieno kliento.

Patikrinkite pataisą nekeisdami pasitikėjimo nustatymų

Neišjunkite TLS patikros, nepergeneruokite prisijungimo duomenų ir neskelbkite blokavimo politikos remdamiesi viena atstatymo eilute. Kiekvienas iš šių pakeitimų pakeičia bandomą sistemą ir padaro kitą palyginimą beprasmį.

Pataisykite identifikuotą komponentą per jo savininką, tada pakartokite tą patį profilį ir tą patį stebėjimą:

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

Naudingas rezultatas yra geriau lokalizuotas gedimas, o ne labiau užtikrinta istorija. Jei atstatymas dingsta pataisius tarpinį serverį, turite priežastį. Jei jis persikelia į kitą etapą, sužinojote ką nors apie kelią. Bet kuriuo atveju įrodymas turėtų atlaikyti antro žmogaus skaitymą. Užrašykite, ką stebėjote, o ne ką padarėte išvadą.