OpenConnect kəsilmiş VPN bağlantısını nə qədər təkrar yoxlamalıdır?

--reconnect-timeout dar bir suala cavab verir: tunel düşdükdən sonra bu müştəri prosesi əl çəkib çıxana qədər nə qədər cəhd etməyə davam edir. OpenConnect təlimat səhifəsi bu seçimi itirilmiş rabitə və ya cavab verməyi dayandırmış peer ardınca edilən təkrar cəhdlər üçün sənədləşdirilmiş 300 saniyəlik standart dəyərlə qeyd edir və bu rəqəm işləyən bir müştəri üçün son müddətdir, VPN-in əlçatan qalmasına sübut deyil. O, həm də prosesi sağ saxlamaq siyasəti deyil və qarışıqlığın çoxu buradan başlayır.

İkinci bir mexanizm üstünə gələndə qarışıqlıq daha da artır. Müştərini yenidən başladan nəzarətçi, şlüzu yoxlayan prob və daxili təkrar cəhd pəncərəsi eyni nasazlığa reaksiya verə bilər və hadisə sonra heç kimin uzlaşdıra bilmədiyi üç zaman xətti yaradır.

Yenidən qoşulma pəncərəsi əslində nəyi məhdudlaşdırır

Təsəvvür edin ki, giriş şəbəkəsi bir neçə saniyə yox olur. Müştəri rabitənin düşdüyünü görür və ya ölü peer cavablarını eşitməyi dayandırır və bacardığı qədər vəziyyəti saxlayaraq sessiyanı yenidən qurmağa başlayır. Təkrar cəhdlər şlüz yenidən qəbul edənə qədər və ya pəncərə bitənə qədər davam edir və bitən pəncərə sıfırdan fərqli çıxışla nəticələnir. Prosesin həyat dövrü sahibliyi məhz həmin çıxışda, taymaut dəyərində deyil, prosesə nəzarət edənə keçir.

Pəncərə probun nə qədər tez-tez işləməsi barədə heç nə demir və autentifikasiyanı uzada bilmir. Əgər şlüz sessiyanı ləğv edibsə və ya hesab indi yeni ikinci faktor tələb edirsə, daha çox gözləmək köhnə sessiyanı yenidən etibarlı etməyəcək. Təkrar cəhd yalnız yol qayıdanda, şlüz sessiyanı hələ də tanıyanda və tələb etdiyi etimad məlumatları istifadə edilə qalanda uğur qazanır, ona görə də rəqəmi canlılıq intervalı deyil, son müddət kimi oxuyun.

Pəncərə həm də tətbiqlərin onun işlədiyi vaxt ərzində nə etdiyini idarə etmir. Platformadan və nasazlığın nə qədər irəlilədiyindən asılı olaraq müştəri marşrutlar hələ quraşdırılmışkən və ya onlar çıxarıldıqdan sonra yenidən qoşula bilər. Buna görə də fasilə ortasında verilən sorğu tez uğursuz olmaq əvəzinə taymaut bitənə qədər asılı qalır.

Nəzarətçinin yenidən başlatması və müştərinin təkrar cəhdləri iki qatdır

Qoy işləyən müştəri öz pəncərəsini xərcləsin, xidmət meneceri isə çıxışa reaksiya versin. systemd altında yenidən başlatma siyasəti olan ön planda müştəri tam bu bölgünü verir: məhdud müddət ərzində təkrar cəhdlər, sonra bir yenidən başlatma qərarı. Nəticə sonradan yenə də bərpa edə biləcəyiniz vahid zaman xəttidir.

Arxa planda işləyən müştəri və interfeys görmədikdə başqa nüsxə başladan müstəqil yoxlayıcı səhv gedən naxışdır. Sonra hər iki proses eyni cihaz qovşağı, marşrutlar və həlledici parametrləri üçün rəqabət aparır. Əgər həqiqətən daemon istəyirsinizsə, seçimi müştərinin faktiki başladığı əmr sətrinə qoyun:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

O sətirdə iki detal çəki daşıyır. --background prosesi ayırır, ona görə pid faylı onun üzərində yeganə etibarlı tutacaq olur və taymaut yalnız həmin proses yaşadıqca xərclənir; onu öldürən nəzarətçi davam etmək üçün büdcə qoymur.

Qəsdən edilən ayrılmalar öz siqnalına ehtiyac duyur. Planlaşdırılmış fasilə ilə real kəsinti sadəlövh müşahidəçi üçün eyni görünür, hər ikisi «qoşulmayıb» kimi oxunur. Fasiləni nəzarətçinin dayandırma əməliyyatı və ya örtüyün anladığı marker vasitəsilə idarə edin ki, qəsdən dayanma heç kimin istəmədiyi yenidən başlatmanı tetikləməsin.

Ötürmənin təkrar cəhd dövrü ilə yarışmasının qarşısını almaq

Nəzarətsiz bərpa insan olmadan yenilənən etimad məlumatlarından asılıdır. Yalnız interaktiv masaüstü sessiyası daxilində açılan açar halqası və ya həmişə əl ilə yazılan kod tələb edən token, yol qayıtdıqdan sonra müştərini autentifikasiya mərhələsində saxlayacaq. Pəncərəni uzatmazdan əvvəl bu iş axınını həll edin, çünki daha uzun pəncərə yalnız eyni bloklanmış sorğuya uğursuz olmaq üçün daha çox vaxt verir.

Server yoxlaması sorğuları azaltmaq üçün yumşaldılmamalıdır. Şlüzu doğrulayan pin və ya etimad ankeri avtomatik yenidən qoşulmanı təhlükəsiz edən şeydir və sertifikat sualından yayınmaq üçün onu söndürmək görünən fasiləni görünməyən biri ilə dəyişir. Doğrulanmış kimliyi saxlayın və əvəzində sorğunu düzəldin; hər şlüza qoşulmağa hazır müştəri dayanıb gözləyəndən pisdir.

İnterfeysin mövcudluğu da sağlamlıq siqnalı deyil. Tunel cihazı arxasında ölü sessiya ilə mövcud ola bilər və başladıcı proses heç bir tunel olmadan mövcud ola bilər. Bu müşahidələrin heç biri real sorğuya tab gətirmir. Sağlamlıq istifadəçinin ehtiyac duyduğu şeydən, məsələn tuneldən keçib tanınmış daxili xidmətə gedən sorğudan gəlməlidir.

Kəsinti zamanı və sonrasında nəyi yoxlamaq lazımdır

Dörd hadisəni ayrı testlər kimi keçirin: pəncərədən qısa kəsinti, ondan uzun kəsinti, autentifikasiya uğursuzluğu və qəsdən dayandırma. Hər biri fərqli və proqnozlaşdırıla bilən vəziyyətdə bitməlidir və ilk ikisi arasındakı sərhəd dəyərin seçilməsinin bütün səbəbidir.

Yoxlamaları xaricə yönəldin, çünki proses cədvəli tək başına çox az şey sübut edir. Qısa kəsinti boyunca pid-in sabit qaldığını izləyin, sonra uzun kəsintidən sonra onun getdiyini və bir dəfə əvəzləndiyini təsdiqləyin:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Qısa kəsinti zamanı müştərinin erkən çıxmaq əvəzinə həqiqətən təkrar cəhd etdiyini və marşrutların və həlledici qeydlərinin dublikatsız qayıtdığını təsdiqləyin. Daha uzun kəsinti üçün təmiz çıxışı və ondan sonra düz bir yenidən başlatmanın gəldiyini təsdiqləyin. Autentifikasiya uğursuzluğu üçün müştərinin onu rədd etməyə davam edəcək şlüz qarşısında fırlanmadığını təsdiqləyin. Pid-in yığılmaq əvəzinə tək dəyərə qayıtdığını yoxlayan bir çek əlavə edin.

Qəsdən dayandırma üçün sağlamlıq URL-i əlçatmaz qalmalı və proses dayanmalıdır. Sonra dövrəni tətbiq tərəfindən bağlayın: eyni sorğu tunel yoxkən uğursuz olmalı və qayıtdıqdan sonra siyasətinizin gözlədiyi mənbə ünvanından uğur qazanmalıdır. Yaşıl tunel ikonu sübut deyil, tamamlanmış sorğu sübutdur.