OpenVPN müştəri bloklama qaydası niyə heç vaxt FORWARD zəncirinə düşmür

Eyni OpenVPN serverindəki iki müştəri, hovuzları üçün DROP qaydası əlavə etdiyiniz halda belə bir-birinə çata bilir. Qayda FORWARD zəncirindədir, trafik açıq şəkildə axır və həmin qaydanın sayğacı sıfırda qalır. Təbii nəticə odur ki, firewall xarabdır. Çox vaxt isə paket zəncirə heç daxil olmamışdır.

Bir peer paketinin OpenVPN serverindən keçə biləcəyi iki yol var və bunlar firewall ilə deyil, konfiqurasiya ilə müəyyən edilir. Hansı yolun istifadə olunduğunu bilmək, host qaydasının ümumiyyətlə düzgün yerdə olub-olmadığını göstərir.

Peer paketinin keçə biləcəyi iki yol

Daxili yönləndirmə seçimi söndürüldükdə, A müştərisindən gələn paket tunel interfeysinə B müştərisinin təyin edilmiş ünvanı daxilində bir təyinatla çatır. Serverin marşrut cədvəli onu yenidən eyni tunel interfeysindən çölə göndərir, çünki B-nin ünvanına marşrut serverə aiddir. Bu, hostdan içəri-çölə axındır və IPv4 yönləndirmə yolu onu qiymətləndirir.

Daxili yönləndirmə seçimi açıldıqda, server prosesi paketi qoşulmuş müştəri ilə uyğunlaşdırır və onu birbaşa həmin müştəriyə geri yazır. Paket demonun içində emal olunur və heç vaxt tunel cihazına yenidən daxil olmur, buna görə hostun yönləndirmə yolu tamamilə atlanır. OpenVPN 2.6 təlimatı bu seçimi daxili müştəridən-müştəriyə yönləndirmə kimi təsvir edir və host firewall qaydasının onu görə bilməməsinin səbəbi məhz budur.

Data kanalını kernel moduluna ötürən quraşdırmalarda üçüncü variant mövcuddur. Yönləndirmə qərarı və şifrələmə istifadəçi məkanından çıxır və netfilterin axını görüb-görməməsi ötürmə yolunun necə qurulduğundan asılıdır. Köhnə qaydalar dəstinin ötürülən serverdə istifadəçi məkanındakı kimi davrandığını heç vaxt ehtimal etməyin. Rejimi paket versiyasından deyil, işləyən konfiqurasiyadan təsdiqləyin.

Sayğac heç vaxt tərpənmədikdə

Sıfır sayğac paketin həmin nöqtədə o qaydaya uyğun gəlmədiyini bildirir və bunun bir neçə səbəbi var. Birincisi yuxarıdakı yan keçmədir: trafik zəncirə heç çatmayıb. İkincisi interfeys, istiqamət, mənbə və ya təyinat uyğunsuzluğudur ki, bu da hovuz yenidən nömrələndikdə və qayda hələ köhnə prefiksi göstərdikdə tez-tez olur.

Üçüncüsü mövqedir. Zəncirdə daha əvvəlki qayda sizin DROP qiymətləndirilməzdən öncə axını qəbul edə bilər, daha sonrakı qayda isə nəticəni həqiqətən həll edən ola bilər. Zənciri sıra ilə və sayğaclar görünən halda oxuyun, sonra testi təkrarladıqda hansı qaydanın sayının artdığını yoxlayın.

Real ünvanlarını yadda saxladığınız icardan deyil, serverin öz vəziyyətindən təsdiqlədiyiniz iki müştəri arasında bir nəzarətli mübadilə keçirin. Əgər müvafiq sayğac yenə tərpənmirsə, uyğunluğu yenidən yazmazdan əvvəl yoldan şübhələnin. Tərpənir, amma bağlantı yenə də uğurlu olursa, drop sonradan üstələnir və problem sıradır. Bu cavab təmirin qayda dəyişikliyi, yoxsa topologiya dəyişikliyi olduğunu həll edir, ona görə hər hansı düzəlişdən əvvəl onu əldə edin.

Filtr edə bilən sərhəd seçmək

Siyasət host firewall-da yaşamalıdırsa, trafiki firewall-un görə biləcəyi yerə qoyun. Daxili yönləndirməni söndürmək peer trafikini tunel interfeysindən və yönləndirmə yolundan keçirməyin dəstəklənən üsuludur, bunun qiyməti hər peer paketinin host yığınından keçməsidir.

Sonra axını dəqiq uyğunlaşdırın. Trafik hər iki istiqamətdə tunel interfeysinə gəlir və tunel interfeysindən çıxır, buna görə yalnız fiziki interfeysi nəzərə alan qaydalar uyğun gəlməyəcək. Ünvana əsaslanan qaydalara cari hovuz lazımdır və onlar geri istiqaməti də, irəli istiqaməti də nəzərə almalıdır.

Bir çox quraşdırma üçün müştəri və ya qrup səviyyəsində filtrləmə daha yaxşıdır, orada şəxsiyyət məlumdur və siyasət yenidən qoşulduqda dəyişən ünvanı deyil, istifadəçini izləyir. Bu, host zəncirindən fərqli mexanizmdir və ikisi aydın səbəb olmadan qarışdırılmamalıdır.

Köhnə topologiyanın qaydalar dəstini miqrasiyadan dəyişmədən keçirməyin. Ünvan hovuzları, interfeys adları və yönləndirmə rejimləri hamısı qaydanın uyğun gəlib-gəlməməsinə təsir edir və əvvəl işləyən köçürülmüş qayda ən yanıltıcı sübut növüdür. İcazə vermək istədiyiniz axından başlayın və ona uyğun gələn qaydanı yazın.

Qaydaya güvənmək əvəzinə izolyasiyanı test etmək

Qadağan olunmuş halı və icazə verilən halı eyni işdə test edin. Bir müştəridən digərinə yeni bağlantı başladın və onun uğursuz olduğunu təsdiqləyin, sonra icazə verilməli olan bağlantının hələ işlədiyini təsdiqləyin. Yalnız birincisi test olunursa, hər şeyi bloklayan firewall uğur kimi görünür.

Server konfiqurasiyasını yenidən yüklədikdən və müştəri yenidən qoşulduqdan sonra təkrarlayın, çünki daxili yönləndirmə və hovuz təyinatları işləmə vaxtı vəziyyətidir. Sayğacları hər iki istiqamətdə yoxlayın, çünki bir istiqamətə uyğun gəlib cavaba uyğun gəlməyən qayda sürətli testdə görmək çətin olan qismən izolyasiya yaradır.

İzolyasiya axını həqiqətən daşıyan sərhəddə müşahidə olunan nəticədir. Hostun hansısa yerindəki DROP qaydası sübut deyil; uğursuz bağlantı və buna səbəb olan qaydanın sayğacının tərpənməsi sübutdur.