Qoruyucu keçid işə düşür: açıq TCP sessiyaları ilə nə baş verir?

Tunel kəsilir, qoruyucu keçid işə düşür və dörddə üçü tamamlanmış yükləmə ya donub qalır, ya da dərhal uğursuz olur. Bu iki nəticə müdafiənin fərqli səviyyələrindən deyil, tətbiqetmənin fərqli seçimlərindən doğur. Düşən paket bağlantını gözləmə vəziyyətində saxlayır, rədd edilən paket isə onu bağlayır və tətbiqə xəbər verir. Hansı davranışı istədiyinizə qərar vermək dizayn məsələsidir, onu yoxlamaq isə ayrı bir məşğuliyyətdir.

Düşən, rədd edilən və sıfırlanan paketlər fərqlidir

Trafiki düşürən firewall qaydası paketi atır və heç nə göndərmir, ona görə göndərən öz taymerləri ilə yenidən göndərməyə davam edir. TCP sıfırlama ilə rədd edən qayda bağlantını dərhal bağlayır və tətbiq xəta görür. Əksər kill switch-lər düşürür, çünki rədd siyasəti aşkar edərdi və düşürmə ölü şəbəkənin davranışına bənzəyir.

Bloklama da soketi bağlamaqla eyni deyil. Tətbiq hələ də qurulmuş vəziyyətdə deskriptor saxlayır və yalnız paketlər çatışmır. Buna görə səhifə dəqiqələrlə spinner üzərində qala bilər, halbuki əməliyyat sistemi bağlantının mövcud olduğunu təkid edir. Tətbiqin mesajından nəticə çıxarmaq əvəzinə sənədləşdirilmiş tətbiqetməni oxuyun, çünki hər iki davranış şəbəkənin söndüyü kimi görünür.

Boşluq davam edərkən tətbiq nə edir

TCP artan gecikmələrlə yenidən göndərir və Linux-un standart təkrar cəhd büdcəsi saniyələr içində deyil, təxminən dörddə bir saatda bitir. O vaxta qədər soket nə faydalı açıqdır, nə də bağlı. Öz keepalive-ları və ya sorğu taymautları olan tətbiqlər çox vaxt daha tez təslim olur, buna görə eyni maşındakı iki proqram bir kəsinti zamanı fərqli davranır.

Tunel qayıdanda yerli soket dəyişməz qalır, amma yol qalmaya bilər. Yeni ictimai mənbə ünvanı serverdə fərqli dördlük yaradır, ona görə uzaq tərəfdəki vəziyyət saxlayan firewall artıq sessiyaya uyğun gəlmir. Müştəri heç vaxt xəta görməsə də, bağlantı ölüdür.

Bərpanın tələb olunub-olunmadığına qərar verin

İki müqavilədən birini seçin. Ya sessiya qısa boşluğu keçməlidir, bu da sabit ünvanlama və vəziyyətini saxlayan server tələb edir, ya da tətbiq təmiz şəkildə yenidən qoşulmalıdır, bu da təkrarlanması təhlükəsiz olan yenidən cəhd məntiqi tələb edir. Arasındakı hər şey ən pis nəticəni verir: serverin artıq təsdiqlədiyini yenidən göndərən müştəri, ya da heç kimin görə bilmədiyi sessiya üçün uğur bildirən müştəri.

Sabit ünvanlama insanların unutduğu hissədir, çünki fərqli ictimai ünvana düşən yenidən qoşulma müştərinin soketi sağlam görünsə də, server tərəfinin vəziyyətini etibarsız edir. Hər tətbiqə iki müqavilədən hansının aid olduğunu yazın, çünki onlar nadir hallarda hamısı üst-üstə düşür.

Bloklanmanı və bərpanı ayrı-ayrılıqda yoxlayın

Sızma müdafiəsini və sessiyanın yaşamasını iki ayrı xassə kimi qəbul edin, çünki birinin keçməsi digəri haqqında heç nə demir. Yaşayan sessiya birbaşa trafikin bloklandığının sübutu deyil, ölən sessiya isə hər bir birbaşa marşrutun bloklandığının sübutu deyil.

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

Bərpanı müşahidə edərkən zərərsiz sınaq əməliyyatından istifadə edin ki, təkrar göndəriş hadisənin özünə çevrilməsin. Həqiqətən gördüyünüz nasazlıq rejimini qeyd edin: tətbiq nə göstərdi, soket yaşadımı və nə vaxt öz-özünə bərpa olundu.

Gözlənilən davranışı tətbiqetmə qaydasının yanına yazın və tarix qoyun. Həmin qaydanı dəyişəcək növbəti şəxs yerləşdirmənin iki müqavilədən hansına söz verdiyini bilməlidir.