SSH VPN-də hər dəqiqə düşür? Səbəb keepalive deyil

SSH qoşulur, təxminən bir dəqiqə işləyir, sonra hər dəfə təxminən eyni intervalda donur. Geniş yayılmış izah boşdayanma taymautudur, ona görə insanlar MTU-nu aşağı salır və client keepalive-ları qururlar. Üzərində işlədiyim WireGuard linki artıq bütün bunlardan keçmişdi: daha kiçik tunnel MTU-su, client-alive parametrləri, konfiqurasiya edilmiş tunnel keepalive-ı. Düşmələr dəyişmədən davam edirdi. Səbəb asimmetrik LAN marşrutu idi və bu nümunəni tanımağa dəyər, çünki o, taymer əsaslı hər bir düzəlişi məğlub edir.

Keepalive hostunuzun hələ də göndərməyə hazır olduğunu sübut edir. O, heç vaxt yanından keçməyən cavabı vəziyyət saxlayan cihaza göstərə bilməz.

Mif: keepalive-lar səssiz düşməni düzəldir

SSH keepalive-ları bir iş üçün mövcuddur: boş sessiyanın səssizliyi sayan bir şey tərəfindən ləğv edilməsinin qarşısını almaq. Bunu yaxşı edirlər. Onlar bir istiqamətdə ilk paketi görüb sonra cavabı heç görməyən vəziyyət saxlayan cihazı həll etmir, çünki clientin göndərdiyi heç nə cavabın hansı interfeysdən istifadə etdiyini dəyişmir.

MTU dəyişikliyi digər populyar düzəlişdir və eyni uğursuzluq rejiminə malikdir. MTU-nu azaltmaq fraqmentasiya və yol-MTU problemlərinə kömək edir və marşruta heç nə etmir. Əgər taymerləriniz və MTU artıq məqbuldursa və düşmə hələ də təkrarlanan intervaldadırsa, interval sizə paket ölçüsündən deyil, haradasa bir taymautdan danışır. Aralığı yazın və onu yoldakı hər cihazdakı vəziyyət taymautları ilə müqayisə edin.

Əlamət, müntəzəmliklə sessiyanın həmin interval ərzində istifadə oluna qalmasının birləşməsidir. Boşdayanma taymautları heç nə olmayanda vurur; bu isə siz yazarkən vurur.

Əlavə şlüz əslində nə edir

Noutbuku və VPN şlüzünü eyni LAN-da yerləşdirin, ayrı LAN firewall-u default şlüz kimi qoyun. Noutbuk VPN-ə yönələn trafiki firewall-a göndərir, firewall onu şlüzə ötürür və şlüzün cavabları birbaşa LAN vasitəsilə noutbuka qayıdır. O ikinci ayaq heç vaxt firewall-dan keçmir, ona görə onun vəziyyət cədvəli yarım bağlantı saxlayır.

Aşağıdakı ünvanlar həmin düzülüşü əks etdirir:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

Yönləndirmələr və vəziyyət idarəsi sonra işləyən əl sıxışmasını dərhal deyil, sonra ölən bağlantıya çevirir. Gecikmə vəziyyət qeydinin köhnəlməsi və ya daha sərt yoxlamanın uğursuzluğudur, buna görə interval bu qədər mexaniki görünür.

Bunların heç biri client konfiqurasiyasında görünmür, buna görə onun axtarışı adətən səhv faylda başlayır.

Bir qəsdən seçilmiş yol seçin

Yuxarıdakı düzülüş üçün uzaq altşəbəkəni birbaşa VPN şlüzünə yönləndirmək yarım bağlantını aradan qaldırır:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

Bunlar nümunə ünvanlardır. Növbəti hop LAN-ınızda əlçatan olmalıdır, prefiks nəzərdə tutulan uzaq şəbəkə olmalıdır və ikinci əmr ona güvənməzdən əvvəl nəticəni göstərir. Əgər şlüz sizin altşəbəkənizdə deyilsə, bu marşrut istədiyiniz düzəliş deyil.

Əgər firewall həmin sistemlər arasındakı trafiki nəzarətdə saxlamaq üçündürsə, onun ətrafından yönləndirmə səhv dizayndır. Bunun əvəzinə hər iki istiqaməti sərhəddən keçirin və hər tərəfdəki marşrutları qayıdış yolu uyğun olsun deyə konfiqurasiya edin. Məqsəd az vəziyyət yoxlaması deyil, tək qəsdən seçilmiş yoldur.

Netgate-in asimmetrik yönləndirmə qeydləri interfeys səviyyəsində eyni asimmetriyanı və yaratdığı vəziyyət problemlərini təsvir edir, ona görə vəziyyət idarəsini qlobal şəkildə yumşaltmazdan əvvəl onları oxuyun. Bu halı xatırladan vaxtlı kəsilmələr təkbaşına sübut deyil. Məqaləni bir uğursuzluq rejiminin təsviri kimi qəbul edin, sonra qlobal vəziyyət siyasətini dəyişməzdən əvvəl öz şəbəkənizin ona uyğun olduğunu sübut edin.

Hər iki tərəfdən sınaqdan keçirin

Noutbukun hədəfə doğru marşrutunu və hədəfin noutbuka doğru geri marşrutunu oxuyun; bunlar iki ayrı qərardır və yəqin ki, yalnız biri səhvdir. Şlüzün özündən uğurlu ping problemi tamamilə gizlədə bilər, çünki o, yolu artıq düzgün olan maşından başlayır. Sizə real sessiyanın iki ucunun gördüyü hər iki istiqamət lazımdır.

Düzəlişdən sonra SSH-ı yenidən açın və sessiyanı əvvəl uğursuz olan intervaldan çox kənarda açıq saxlayın. Sonra marşrutu təsdiqlənmiş şəbəkə konfiqurasiyasında davamlı edin, çünki birdəfəlik əmr yenidən başlatma planı deyil və problem növbəti yenidən başlatmada yeni bir sirrlə qayıdacaq.

Asimmetriya nə vaxt qəbul ediləndir

Asimmetrik yönləndirmə bir çox şəbəkədə normaldır və tərifinə görə pozulmuş deyil. O, vəziyyət izləmə, tərcümə və ya siyasət görmədiyi bir yolu görməkdən asılı olduqda problemə çevrilir və bunların hər birinin fərqli dərmanı var. Ətrafında yenidən dizayn etməzdən əvvəl orta cihazın həqiqətən nə tələb etdiyini yoxlayın.

Dayanıqlı cavab iki yolu, hər ikisini görməsi lazım olan cihazı və bunu mümkün edən marşrutu adlandırır. Əgər cihazı adlandıra bilmirsinizsə, səbəbi hələ tapmamısınız.