VPN yenidən qoşuldu, amma tətbiq sessiyası yenə də uğursuz olur
Yenidən qoşulma marşrutları bərpa edir, soket vəziyyətini yox. Köhnə sorğu hələ asılı qalarkən bir yeni sorğu açın və ikisindən hansının uğursuz olduğunu biləcəksiniz.
Tunel geri qayıdır, müştəri qoşulduğunu bildirir, brauzer isə fasilədən əvvəl yüklədiyi səhifədə hələ də fırlanır. VPN-in yenidən qoşulması marşrutu bərpa edir və tətbiqlərlə uzaq tərəfin köhnə marşrut üzərində topladığı bağlantı vəziyyətini bərpa etmir. Bunlar bərpa edilməli iki fərqli şeydir və onları qarışdırmaq sizi lazımsız yerə VPN parametrlərinə qaytarır.
Bir test onları təmiz ayırır və cəmi on saniyə çəkir. Köhnə sorğu asılı qalarkən eyni ünvana yeni sorğu göndərin.
Yenidən qoşulmadan nə sağ qalır, nə sağ qalmır
Tunel marşrutlar, açarlar və ünvanlar toplusudur və yenidən qoşulma hər üçünü bərpa edə bilər, halbuki hər qurulmuş axın ölü qalır. Əməliyyat sistemi soketi tətbiq istədiyi üçün açıq saxlayır və o soketin vaxt aşımı dəqiqələr və ya saatlar uzaqda ola bilər. Altda isə qarşı tərəf axını unudub, tərcümə qeydinin müddəti bitib, ya da yol artıq heç vaxt əl sıxışmasını görməmiş bir son nöqtədən keçir. Yenidən qoşulma ardıcıllığında heç nə tətbiqin soketlərini gəzib onları təmir etmir.
Bəzi müştərilər yenidən qoşulma zamanı köhnə bağlantıları atan bir qarmaq əlavə edir, əksəriyyəti isə etmir. Buradakı davranış müştəriyə, platformaya və versiyaya görə dəyişir.
Uzaq tərəf sizi də unudub
Uzaq uc öz vəziyyətini saxlayır: TLS sessiyası, TCP idarə bloku və bəlkə də ünvanınızı və portunuzu axına bağlayan bir xəritələmə qeydi. Yol boyunca tərcümə cihazı, tunel tez bərpa olunsa belə, fasilə zamanı həmin xəritələmənin müddətini bitirə bilər. Xəritələmə getdikdən sonra paketlər serverin artıq tanımadığı bir axın üçün gəlir və cavab müştərinin heç göstərmədiyi reset ola bilər. Tətbiqlər bunu xəta kimi deyil, donma kimi bildirir, çünki hələ də heç vaxt cavab verməyəcək bir soketi gözləyirlər.
Server tərəfindəki boşdayanma vaxt aşımları eyni şeyi öz cədvəli ilə edir, buna görə sessiya heç bir şəbəkə hadisəsi olmadan ölə bilər. Serverin gözlədiyindən daha uzun boş qalmış bağlantı, siz tunelin yerini dəyişdiyini görməmişdən əvvəl artıq yoxa çıxıb.
Yeni sorğu onları ayıran testdir
Köhnə sorğu hələ asılı qalarkən eyni hosta yeni sorğu göndərin və ikisini də izləyin. Yeni sorğu uğurludursa, tunel, marşrut və ad həlli işləyir, nasazlıq isə yalnız köhnə axınla məhdudlaşır. Yeni sorğu da uğursuz olursa, marşrut problemi var və tətbiqin sessiya vəziyyəti yanlış izdir.
Test zamanı birbaşa trafik üçün hər hansı bloku yerində saxlayın. Təsadüfi bir ehtiyat yol üzərindən uğurlu olan sorğu tunel haqqında heç nə sübut etmir.
Köhnə yox, yeni bağlantı ilə təsdiqləyin
Aşağıdakı əmrlər hələ açıq olan soketləri göstərir, bir yeni sorğu başladır və sessiya cədvəlinin axın üçün hələ də qeyd saxlayıb-saxlamadığını yoxlayır. Fərq görünsün deyə birincisini yenidən qoşulmadan əvvəl və sonra işə salın. Hostu və portu öz xidmətinizlə əvəz edin.
ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com
Heç bir trafik hərəkət etməyən qurulmuş soket axtarılmalı əlamətdir və status kodu qaytaran yeni sorğu yolun canlı olduğunu göstərir. Bağlantı cədvəli hər hansı bir şeyin axını hələ də xəritələyib-xəritələmədiyini cavablandırır, bu da müştərinin görə bilmədiyi hissədir. Ad həlli sorğusu səhifə yükləməsinin digər yarısını əhatə edir, çünki ad uğursuzluğu ilə donmuş bağlantı brauzerdə eyni görünür. Birlikdə, bu dörd çıxış köhnə sessiyanı qırıq tuneldən ayırır.
Kəsilmə vaxtını, yenidən qoşulma vaxtını və köhnə sorğu ilə yeni sorğu arasındakı fərqi qeyd edin. Bu qeyd qeyri-müəyyən şikayəti kiminsə hərəkət edə biləcəyi hesabata çevirir.