Niyə nc -uz OpenVPN serverinin hazır olduğunu sübut edə bilmir

İşə salınan nc -uz əmri OpenVPN serverinə qarşı demək olar ki, heç nə ölçmür, və OpenBSD təlimatı bunu öz xəbərdarlıqlarında deyir: bu rejimdə UDP skanları heç nə dinləməsə də uğur bildirir. Çıxış statusu uzaq vəziyyəti deyil, yerli göndərməni əks etdirir, ona görə ona güvənən nəzarətçi proses cədvəli inandırıcı göründüyü müddətcə ölü serveri sağlam kimi saxlayır. Onu əvəz etmək yoxlamanın hansı suala cavab verməli olduğunu müəyyən etməklə başlayır, çünki proses, dinləyici, autentifikasiya və tətbiqin əlyetərliliyi dörd fərqli müşahidədir. Onlardan birini adlandıran yoxlama faydalıdır; dördünü ima edən yoxlama isə yükdür.

UDP yoxlamasının nəyi görə və nəyi görə bilmədiyi

nc -uz datagram göndərir və çıxır, qaytardığı status isə yerli göndərməni təsvir edir. Bağlı port ICMP port unreachable ilə cavab verə bilər, lakin bu skan rejiminin sənədləşdirilmiş davranışı bunu uğursuzluğa çevirmir, filtrlənmiş port isə ümumiyyətlə cavab vermir. Buna görə sükut və uğur çağıran üçün eyni şey deməkdir.

Bu, yoxlamanı serverin deyil, yerli yığının testinə çevirir. O, hostun əlyetərli olduğunu, portun bağlandığını, OpenVPN prosesinin işlədiyini və ya müştərinin autentifikasiya edə biləcəyini təsdiqləmir. TCP bağlantı testi daha güclüdür, çünki əl sıxma dəqiq cavab verir, ancaq yerləşdirmə həqiqətən TCP-də dinləyəndə. Yoxlamanı eyni nömrədə TCP-yə keçirmək mövcud olmaya bilən dinləyicini test edir və yalnız UDP üzərində işləyən serverə qarşı sağlam xidməti uğursuz edəcək.

Yoxlamanı konfiqurasiya edilmiş nəqliyyata uyğunlaşdırmaq iki nəticədən hər hansı birinə güvənməkdən əvvəl gəlir. UDP yerləşdirməsi fərqli protokol deyil, fərqli siqnal tələb edir.

Üç çağıran, üç fərqli sual

Hazırlıq kimin soruşduğundan asılıdır. Çökmüş prosesi yenidən başladan xidmət meneceri instansiyanın başladığını və dinləyicisini bağladığını bilməlidir. Yük balanslaşdırıcısı indi gələn müştərinin qəbul ediləcəyini bilməlidir. Monitorinq sistemi real şəbəkədən gələn yolun hələ də icazə verilmiş resursa sessiya daşıdığını bilməlidir.

Bunlar eyni yoxlama deyil və bir yoxlama hər üçünü dürüst şəkildə əhatə edə bilməz. Əvvəlcə çağıranı seçin, sonra sübutu.

Yoxlamanı cari instansiyadan qurun

OpenVPN instansiya inisializasiyanı bitirdikdə başlama sətri yazır və bu sətir yerli başlama haqqında faydalı sübutdur. Onu əlavə edilmiş faylın quyruğundan deyil, cari başlamadan oxuyun, çünki keçən həftənin uğuru bir dəqiqə əvvəlki uğurla tam eyni oxunur. Server həm də heç bir müştəri qoşulmadan əvvəl inisializasiyanı bitirə bilər, ona görə sətir autentifikasiya haqqında heç nə demir.

Başlama yoxlaması üçün proses vəziyyətini cari jurnal sübutu və konfiqurasiya edilmiş nəqliyyata uyğun dinləyici ilə birləşdirin. Proses işlədiyi halda inisializasiyanı bitirməyibsə, yoxlama uğursuz olmalıdır, bu isə jurnal sorğusunun bu açılış və bu vahidlə məhdudlaşdırılması deməkdir.

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

Üç çıxış, üç iddia: vahid aktivdir, bu açılış inisializasiya sətrini yaratdı və nəsə UDP portunu tutur. Heç biri müştərinin qoşula biləcəyini demir. Onları status səhifəsində ayrı saxlayın ki, insident tək yaşıl nöqtəyə çökəsin.

Onu qəsdən sındırın və yoxlamaya baxın

Yoxlama yalnız onun uğursuzluğunu gördükdən sonra etibarlı olur. Serveri dayandırın, yoxlamanı işə salın və gözlədiyiniz nəticəni təsdiqləyin. Sonra onu yenidən başladın və yoxlamanın başqa heç bir dəyişiklik olmadan bərpa olduğunu təsdiqləyin.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

Bloku sətir-sətir oxuyun. netcat əmri exit=0 çap edir, halbuki heç nə bağlanmayıb və bütün problem bir sətirdə budur. Birinci ss heç nə çap etmir, yenidən başlatma uğurlu olur və ikinci ss dinləyicini yenidən göstərir. Əgər yoxlamanız dayandırılmış serverə qarşı keçirsə, o, yerli yığını ölçür və başqa heç nəyi.

Əks uğursuzluq da vacibdir. Sağlam serverə qarşı uğursuz olan yoxlama heç vaxt lazım olmayan yenidən başlatmalara səbəb olur və yenidən başlatma dövrəsi özü bir kəsintidir. Yoxlamanı ona əsasən hərəkət edə bilən bir şeyə qoşmazdan əvvəl hər iki istiqaməti sınayın.

Status sətri nə deməlidir

Hər yoxlamanın hansı sərhədi əhatə etdiyini qeyd edin: proses, dinləyici, autentifikasiya və ya tətbiq. Bir yoxlama nadir hallarda birdən çoxunu əhatə edir və onları “up” kimi sıxan status səhifəsi insident zamanı vacib olan fərqi gizlədir. Şəbəkə yolu üçün ayrılmış kimliyi olan real müştəri istifadə edin, onun əl sıxmanı və bir zərərsiz icazəli əməliyyatı tamamlamasına icazə verin, sonra bağlantını kəsin. Bu, idarəetmə kanalını, autentifikasiya siyasətini və dinləyicini bir addımda yoxlayır.

Bu kimliyi real istifadəçilərdən ayrı saxlayın və yoxlamanın ehtiyac duyduğu minimum icazələri verin. Geniş çıxışı olan hazırlıq yoxlaması rahatlıq üçün əlavə edilmiş yeni hücum səthidir. Onun etimad məlumatlarını hər hansı digər hesab kimi döndərin, çünki autentifikasiyanı dayandıran yoxlama müştəriləri qəbul etməyi dayandıran serverlə tam eyni görünür.

Sərhədi xəbərdarlıq mətnində adlandırın ki, ilk cavab verən vahidə, soketə, sertifikata və ya marşruta baxmalı olduğunu bilsin. Nəyi sübut etdiyini deyə bilməyən yoxlamaya səhv səbəbdən güvəniləcək və netcat yoxlaması ilk növbədə belə sağ qaldı.