VPN niyə kəsintidən daha uzun bərpa olunur

Wi-Fi otuz saniyə əvvəl qayıtdı və VPN hələ də söndürülüb, ona görə müştəri xarab görünür. Çox vaxt o, öz yenidən cəhd cədvəlinə riayət edir və həmin cədvəl şəbəkənin yenicə qayıtdığını bilmir. Bu boşluq bütün hekayədir: bərpa müddəti kəsinti üstəgəl müştərinin əvvəlcədən öhdəsinə götürdüyü hər hansı gözləmədir. Hər taymeri aşağı salmaq bir cavabdır, hansı taymerin vacib olduğunu anlamaq isə digəridir.

Üç şərt tənzimləmənin kömək edib-etmədiyini müəyyən edir: hansı mərhələ yavaşdır, nasazlıq ümumiyyətlə təkrar cəhdə yararlıdırmı və müştəri şəbəkənin qayıtdığını necə öyrənir.

Bir kimi görünən üç gözləmə

Son nöqtənin həlli, IKE və ya TLS danışıqları, paketlərin yenidən ötürülməsi və yeni cəhdə başlama ayrı taymerləri olan ayrı hadisələrdir. strongSwan yenidən ötürmə gecikməsini IKE üçün sənədləşdirir və OpenVPN fərqli semantikaya malik öz təkrar cəhd nəzarətlərinə sahibdir. Rəqəmi birindən digərinə köçürmək mexanizmlərin uyğun olduğunu fərz edir, halbuki uyğun deyillər. Hansı intervala baxdığınıza qərar verməzdən əvvəl jurnal ardıcıllığını oxuyun.

Jurnalda səssiz bir dəqiqə mütləq donmuş proses deyil. Bu, konfiqurasiya olunduğu işi məhz yerinə yetirən eksponensial gecikmə ola bilər.

Hansı mərhələ həqiqətən yavaşdır?

Jurnal cəhdlərin autentifikasiya xətası ilə uğursuz olduğunu göstərirsə, heç bir taymer dəyişikliyi kömək etmir, çünki etimad məlumatı səhvdir. Əgər cəhd ümumiyyətlə edilmirsə, müştəri gözləmə pəncərəsinin içindədir və həll cədvəldir. Əgər cəhdlər edilir və vaxtı keçirsə, problem əlçatanlıqda və ya çatışmayan dinləyicidədir və daha sürətli təkrar cəhd yalnız jurnalı doldurur. Bu üç vəziyyətin hər birinin fərqli sahibi var və yalnız biri zamanlama problemidir.

Rəqəmə toxunmazdan əvvəl nasazlığı təsnif edin.

Taymeri aşağı salmaq nə vaxt kömək edir və nə vaxt etmir

Təkrar cəhd həddini o zaman aşağı salın ki, üstünlük təşkil edən xərc qısa və tez-tez kəsintidən sonra gözləməkdir, məsələn, giriş nöqtələri arasında hərəkət edən noutbuk. Nasazlıqlar uzun və ya nadirdirsə, ona toxunmayın, çünki aqressiv təkrar cəhd konsentratorun cavab verə bilmədiyi dəqiq anda yük əlavə edir. Hər iki halda bir parametri dəyişin, onu qeyd edin və yaxşılaşdığını fərz etmək əvəzinə növbəti bərpanı ölçün.

Hər profilə köçürülən çox aşağı fasilə müddəti, ölçmədən tənzimləmənin adi son nəticəsidir.

Müştərini günahlandırmazdan əvvəl hazırlığı yoxlayın

Müştəri çox vaxt nəyinsə cəhd etməsinə qədər şəbəkənin istifadəyə yararlı olduğunu görə bilmir. Əsir portal, DHCP yenilənməsi və ya marşrut dəyişikliyi onu bütün bunlardan əvvəl qurulmuş cədvəl üzrə gözləməyə qoya bilər. Əməliyyat sisteminin şəbəkə vəziyyətinin dəyişməsini və müştərinin növbəti cəhdini eyni saatla izləyin və kimin gözlədiyini görəcəksiniz. Sürətli variant şəbəkə-hazır hadisəsinin vaxt damğasını və ondan sonrakı ilk cəhdin vaxt damğasını qeyd etməkdir.

Gözləmə zamanı birbaşa trafikin də hələ də bloklandığını təsdiqləyin, çünki trafiki sızdıran daha sürətli yenidən qoşulma təkmilləşmə deyil.

Nə qeyd etməli

Hansı taymerin dəyişdiyini, hansı dəyərdən hansı dəyərə, və sonrasında bərpanın necə göründüyünü yazın. Müştəri versiyasını da qeyd edin, çünki defoltlar buraxılışlar arasında dəyişir və sənədləşdirilməmiş çox aşağı fasilə profili oxuyan növbəti şəxsi çaşdıracaq.

Bu qeyd növbəti proqram yeniləməsini eksperimentdən çox müqayisəyə çevirir.