NetworkManager-də gateway-ping-timeout əslində nəyi gözləyir

Siz connection.gateway-ping-timeout parametrini şəbəkə istifadəyə yararlı olmadan əvvəl açılan noutbuk haqqında bir müzakirədə tapırsınız, onu artırırsınız və nəsə dəyişir. Dəyişikliyin sizin düşündüyünüz səbəbdən kömək edib-etmədiyi ayrı bir sualdır. Cavab, aktivləşdirmənin həmin taymer işləyərkən əslində nə etdiyindən və gözləmənin iki mümkün sonu olmasından başlayır.

Bir bağlantını əmr sətrindən izləyin və semantika konkretləşir.

Bir aktivləşdirməni izləyin

Qlobal defolt dəyərə deyil, saxlanmış bağlantıya baxmaqla başlayın, çünki bu, hər bağlantıya aid bir xüsusiyyətdir. Yalnız həqiqətən lazım olduqda --show-secrets əlavə edin; parametrin özü sirr deyil.

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

Xüsusiyyət sıfırda olduqda, sənədləşdirilmiş defolt budur, aktivləşdirmə ünvanlama tamamlanan kimi davam edir. Onu müsbət dəyərə qoysanız, IP konfiqurasiyasının aktivləşdirilməsi ya şlüzdən cavab gələnə, ya da vaxt aşımı bitənə qədər gözləyir.

Sonra hadisə axınını izləyərkən bağlantını aşağı salıb yenidən qaldırın. Gördüyünüz sıra parametrin işini görməsidir: cihaz vəziyyəti, ünvanlama, gözləmə və nəhayət asılı xidmətlərin adətən ona görə sıralandığı aktiv vəziyyət.

Gözləmənin iki sonu var

Hər iki son vacibdir və çoxu yalnız birini xatırlayır. Şlüzdən gələn cavab gözləməni erkən bitirir, vaxt aşımı da bitirir, cavab verilib-verilməməsindən asılı olmayaraq. Xüsusiyyət aktivləşdirmənin tamamlanması üçün uğurlu ping tələb etmir.

Bu bir cümlə otel və konfrans məkanlarında noutbuklarla bağlı çoxlu çaşqınlığı aradan qaldırır, çünki orada ələ keçirmə portalı çox vaxt daxil olana qədər ICMP-ni rədd edir. Bağlantı vaxt aşımı bitdikdən sonra da aktivləşir; sadəcə lazım olduğundan gec edir və bağlantıdan sonra sıralanan hər xidmət onunla birlikdə gözləyir.

Bu, canlılıq yoxlaması da deyil. Təsvirdə heç nə bağlantı qalxdıqdan sonra şlüzə ping göndərməyə başlamır və heç nə sonrakı ping uğursuz olduğu üçün aktiv profili ayırmır. İtkini aşkarlamağa ehtiyacınız varsa, bu protokolun və ya tunelin sahibinə aiddir, aktivləşdirmə zamanı bir dəfə işləmiş xüsusiyyətə deyil.

İki obyekt, bir parametr

Kabel əsas profili və VPN profili ayrı konfiqurasiya obyektləridir və parametrin birinə qoyulması digərinə təsir etmir. Əsas bağlantını adlandıran VPN profili onun aktivləşdirmə parametrlərindən heç birini miras almır, buna görə dəyişdirdiyiniz dəyər izlədiyiniz şeyə təsir etmirmiş kimi görünə bilər.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

Adlara deyil, UUID-lərə baxın. Adlar yenidən quraşdırma və ya bərpa edilmiş profildən sonra təkrarlanır, və eyni görünən ada malik iki bağlantı sizi səhv faylı redaktə etməyə yönəldər, əsl fayl isə dəyişməz qalar.

Quraşdırılmış NetworkManager buraxılışı da vacibdir. Plagin davranışı və bağlantı növünün bu parametri öz aktivləşdirmə addımlarına necə uyğunlaşdırması fərqlənir, ona görə tapdığınız yazının dəyişməz qüvvədə olduğunu fərz etmək əvəzinə yerləşdirdiyiniz versiyada sınaqdan keçirin.

Gözləmənin təsdiqləyə bilmədiyi şeylər

Ən çox vaxt aparan hissə budur. Yerli marşrutlaşdırıcıdan gələn cavab, aktivləşdirmə zamanı bir hostun bir ICMP əks-sədasına cavab verdiyini sübut edir. O, VPN son nöqtəsinin həll olunduğunu, müştərinin kimliyinin qəbul edildiyini, şəxsi marşrutların quraşdırıldığını, ofis həlledicisinin cavab verdiyini və ya maraqlandığınız tətbiqin işləyəcəyini sübut etmir.

Bunlar ayrı sübutları olan ayrı asılılıqlardır. DNS uğursuz olanda şlüz cavab verə bilər və hər tətbiq yolu işləyərkən şlüz siyasətlə ICMP-ni səssizcə ata bilər. Beləliklə, bu parametrə şərt qoymaq hansı qatın gecikdiyinə dair bir təxmindir, onun ölçüsü deyil.

Asılı bir xidməti gözləyirsinizsə, onun nəyə ehtiyacı olduğunu adlandırın. Təyin edilmiş ünvana ünvanlama cavab verir. Tunelə tunelin öz vəziyyəti cavab verir. Şəxsi ada sorğu cavab verir. Tətbiqə tətbiq cavab verir və bu cavablardan heç biri şlüzün adını daşıyan taymerdən gəlmir.

Dəyişdirirsinizsə, səbəbini yazın

Təsdiqlənmiş dəyişiklikdən əvvəl köhnə dəyəri və səbəbi qeyd edin, sonra onu hər yerdə deyil, konkret bağlantıda qoyun. Daha uzun gözləmə həmin bağlantıdan sonra sıralanan hər şey üçün aktivləşdirmə vaxtını sürüşdürür, bu da yavaş sistemi yaxşı, sürətli sistemi isə xarab göstərə bilər.

Bir tarixi tələni adlandırmağa dəyər: belə bir dəyər bəzən köhnə redaktorun profili qəbul etməsi üçün dəyişdirilir. Əgər əsl hekayə budursa, sizin bir deyil, iki hadisəniz var. Redaktor saxladı və canlı şəbəkə siyasəti dəyişdi. Redaktoru və ya plagini düzəldin və taymeri geri qaytarın.

NetworkManager mənbəyi parametri IP ünvanlamasının uğurunun şlüz cavabına və ya vaxt aşımına qədər gecikdirilməsi kimi təyin edir, defolt sıfırdır və bağlantı parametrinin tərifi ikinci əl təsvir edilmiş hər hansı davranışa güvənməzdən əvvəl oxunmalı istinaddır.