TCP sıfırlaması VPN-in bloklandığını sübut etmir

Müştəri jurnalında «bağlantı sıfırlandı, yenidən başladılır» görünür və nəticə sübutdan əvvəl gəlir. Kimsə şəbəkənin VPN-i blokladığına, sertifikatın səhv olduğuna və ya müəyyən bir ölkənin müdaxilə etdiyinə qərar verir. Sıfırlama bağlantını bitirən TCP paketidir və jurnal sətri müştərinizin belə bir paket aldığını qeyd edir. O, paketi göndərən cihazı və ya göndərilmə səbəbini adlandırmır.

Sıfırlama paketdir, hökm deyil

TCP sıfırlama emalını müəyyən edir: RST bayrağı olan seqment bağlantını dərhal bitirir. Qəbul edən tərəf danışıq aparmır, yenidən cəhd etmir və səbəb soruşmur. Sadəcə sıfırlamanı bildirir və davam edir.

Müştərinin bildiyi budur. RST serverdən, proksidən, firewall-dan və ya vəziyyətini itirmiş yük balanslaşdırıcısından gəlmiş ola bilər.

Mənbənin müəyyən edilməsi ayrı bir məşğuliyyətdir. Tutmada görünən mənbə ünvanı fiziki mənşəyin sübutu deyil və arxasındakı siyasət qərarı haqqında heç nə demir. Ara cihazlar ünvanları saxtalaşdıra bilər, vəziyyət saxlayan cihazlar isə qəsdən deyil, vaxt aşımına görə sıfırlaya bilər. Sıfırlamanı hökm kimi qəbul etmək, həqiqəti öyrəndiyiniz hissəni atlayır.

Hansı bağlantının sıfırlandığını təsdiqləyin

Əvvəlcə aktiv profilin həqiqətən TCP istifadə etdiyini yoxlayın. UDP tunelində sıfırlamanın mənası yoxdur və HTTP proksisindən gələn jurnal VPN-in özündən fərqli TCP ayağına aid ola bilər.

Təyinatı, portu, cəhd vaxtını və müştərinin çatdığı mərhələni qeyd edin.

Ən faydalı sahə mərhələdir. TLS əl sıxması zamanı sıfırlama bir şübhəli qrupuna işarə edir; autentifikasiyadan sonra sıfırlama başqa bir qrupa. Mərhələ olmadan hər nəzəriyyə uyğun gəlir.

Yolun iki ucunu müqayisə edin

Serveri siz idarə edirsinizsə, həmin cəhd üçün onun hadisələrini müqayisə edin. Bağlantını qəbul etdimi? Onu qəsdən bağladımı? Cavab bir sərhədi tərk edib növbəti sərhədə çatmadımı?

Mümkünsə həm müştəridə, həm də serverdə tutma aparın. Müştəridə görünən, serverdə görünməyən sıfırlama serverdə yaranmayıb.

Hər iki istiqamətdə RST seqmentlərini izləyin:

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

Nəzarətli müqayisə ilə daraldın

İkinci təsdiqlənmiş şəbəkə nasazlığın müştərini, yoxsa yolu izlədiyini deyə bilər. Eyni profil başqa yerdə işləyirsə, müştəri konfiqurasiyası çox güman ki, qaydasındadır və dəyişən yoldur.

Bu hələ də konkret bir ara cihazı müəyyən etmir. Əhatəni bir marşruta daraldır, bu da faydalı və dürüst nəticədir.

«Bu yol uğursuz olur» ilə «bu adlandırılmış aktyor buna səbəb oldu» arasındakı fərqi qoruyun. Birincisi yoxlanıla bilər; ikincisi adətən tək müştəridən yoxlanıla bilməz.

Etibarlılıq parametrlərini dəyişmədən düzəlişi yoxlayın

TLS yoxlamasını söndürməyin, etimadnamələri yenidən yaratmayın və bir sıfırlama sətri əsasında bloklama siyasəti elan etməyin. Bunların hər biri sınaqdan keçirilən sistemi dəyişir və növbəti müqayisəni mənasız edir.

Müəyyən edilmiş komponenti sahibi vasitəsilə düzəldin, sonra eyni profili və eyni müşahidəni təkrarlayın:

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

Faydalı nəticə daha yaxşı lokallaşdırılmış nasazlıqdır, daha inamlı hekayə deyil. Proksi düzəlişindən sonra sıfırlama yox olursa, səbəbiniz var. Başqa mərhələyə keçirsə, yol haqqında bir şey öyrənmisiniz. Hər halda sübut ikinci bir oxucunun oxumasına tab gətirməlidir. Nə gördüyünüzü yazın, nə qənaət etdiyinizi deyil.