Niyə OpenVPN müştəriləri şlüzün IPsec selektorlarını əldən verir

Şlüzdən uzaqdakı IPsec tunelinin arxasındakı hosta ping göndərin və o, təmiz cavab verir, yəni tunel sağlam görünür və bilet irəliləyir. Sonra qoşulmuş müştəri həmin hostu yoxlayır və heç nə almır. O ping heç vaxt müştərinin axını üçün sübut olmamışdı, çünki o, şlüzün öz mənbə ünvanı ilə çıxıb başqa bir IPsec selektoruna uyğun gəlmişdi. İki halın niyə fərqləndiyini anlamaq düzəlişin böyük hissəsidir.

Şlüzün pingi müştərinizin heç vaxt istifadə etmədiyi axını yoxlayır

Hansı siyasətin tətbiq olunacağını mənbə ünvanı müəyyən edir. Şlüzdə yaradılan paket yerli LAN-ından və ya tunel son nöqtəsindən bir ünvanla çıxır və ona uyğun gələn siyasət məhz bu hal üçün yazılmışdı. Müştərinin paketi isə OpenVPN interfeysinə müştəri hovuzundan bir ünvanla gəlir ki, bu tamamilə başqa selektordur.

Buna görə nasazlıq marşrut problemi kimi görünür, halbuki əslində siyasətin əhatə dairəsi problemidir. Şlüzdən əlçatanlıq qarşı tərəfin işlədiyini və təkliflərin razılaşdırıldığını sübut edir və hovuzun qorunub-qorunmadığı barədə heç nə sübut etmir.

Tətbiqin həqiqətən ehtiyac duyduğu uzaq prefiksi göndərin

Qoşulmuş müştərilər üçün 10.8.0.0/24 və qorunan uzaq şəbəkə üçün 172.30.239.0/25 nümunə cütünü götürün. Müştəriyə lazım olan ikinci prefiksə marşrutdur, nə şlüzün LAN-ına, nə də başqa tunel ünvanına. Hovuza göndərilən marşrut müştərinin bu trafiki ümumiyyətlə şlüzə verməsini təmin edir. O olmadan paket heç vaxt sizin sazladığınız siyasət qərarına çatmır.

Göndərilən marşrutları qəbul edən Community serverində direktiv real maskanı götürür: push "route 172.30.239.0 255.255.255.128". Access Server eyni təyinatı quraşdırılmış versiyanın şəxsi şəbəkə və ya giriş qaydası parametrləri ilə qurur, yönləndirmə və ya tərcümə rejimi isə qəsdən seçilir. Yaranmış firewall zəncirlərini sahib konfiqurasiya yerinə redaktə etmək işlək quraşdırmanı təkrar istehsal olunmaz hala gətirən yoldur.

Qoşulduqdan sonra serverin niyyətini deyil, müştərinin marşrut cədvəlini oxuyun. Yalnız hovuzu əhatə edən marşrut göndərmənin çatmadığını bildirir, tuneldən keçən default marşrut isə bu tələbdən genişdir və sizi sonra təəccübləndirəcək. Maskanı da prefikslə birlikdə yoxlayın, çünki /25 kimi göndərilən /24 qonşu ünvanların trafikini onu daşıya bilməyən yola salır. Sonra müştərinin həmin təyinat üçün tunel interfeysini seçdiyini təsdiqləyin.

Selektorlara müştəri hovuzunu daxil edin

Müştəri ünvanlarını qoruyan yönləndirilmiş giriş üçün IPsec siyasəti hovuzla uzaq prefiks arasındakı trafiki qorumalıdır. Şlüzün öz LAN-ı üçün yazılmış selektorlar pingi keçirir və müştərinin sorğusunu atır ki, bu da bu araşdırmanı başladan həmin asimmetriyadır.

Razılaşdırılmış siyasəti də konfiqurasiya edilmiş təkliflərlə birlikdə yoxlayın, məsələn strongSwan-da ipsec statusall və ya sizin tətbiqiniz üçün ekvivalent status əmri ilə. Siyasət əsaslı IPsec-də adi marşrut fiziki interfeysə işarə edə bilər, uyğun trafik isə hələ də şifrələnir, ona görə də tunel cihazının olmaması heç nə sübut etmir. Selektor cütlərini yazdığınız hovuz və prefikslə müqayisə edin.

Şlüzdə ümumi mənbə NAT-ı da uyğunluğu poza bilər. Əgər masquerade qaydası siyasət yoxlamasından əvvəl müştərinin mənbəyini yenidən yazırsa, paket artıq yazdığınız selektora bənzəmir. Geniş masquerade qaydasının ikinci VPN üçün pis həll olmasının bir səbəbi budur: hansı siyasətin tətbiq olunacağını və qarşı tərəfin hansı ünvanı qeyd edəcəyini dəyişir. Yönləndirmək istədiyiniz trafiki azad edin və ya onu qəsdən tərcümə edin və selektorları uyğun yeniləyin.

Yönləndirmə və ya tərcüməni qəsdən seçin

Yönləndirmə müştəri ünvanını qarşı tərəf üçün görünən saxlayır, yəni uzaq jurnallar və mənbə üzrə qaydalar mənalı qalır, və uzaq şlüzün hovuza qayıdış yolunu bilməsini tələb edir. Tərcümə hovuzu bir ünvanın arxasında gizlədir, bu qayıdış marşrutu problemini aradan qaldırır və hər müştərinin kimliyini məhv edir.

Bir dizayn seçin və onu yazın, çünki ikisi fərqli selektorlar və fərqli firewall sıralaması tələb edir. Yarım tətbiq olunmuş masquerade aralarında qalır və heç birini qane etmir. Yazılı seçim həm də növbəti mühəndisə səhvi qəsdən verilmiş qərardan ayırmağa imkan verir.

Yönləndirmə və cavab üzrə dövrəni bağlayın

Şlüz nəzərdə tutduğunuz protokolu və təyinatı yönləndirməlidir, yəni IP yönləndirmə aktiv olmalı və cütə icazə verən yönləndirmə zənciri olmalıdır. Sonra qarşı tərəf cavabları IPsec yolu ilə geri göndərməlidir və bu, sizin yox, onların şlüzündə marşrut qərarıdır. Hər iki yarım adi konfiqurasiyadır və hər ikisini yarımçıq qoymaq asandır. Onları ayrı-ayrı yoxlayın ki, çatışmayan yönləndirmə qaydası xarab tunellə səhv salınmasın.

Bir real müştəridən tətbiqə sorğu ilə yoxlayın və onun OpenVPN interfeysindən, IPsec qərarından və uzaq hostdan keçməsini izləyin. Cavabı ayrı müşahidə kimi yoxlayın, çünki gələn sorğu ilə heç qayıtmayan cavab müştərinin yerindən eyni görünür. Bir izlənmiş sorğu istənilən sayda şlüz pingindən daha dəyərlidir.

Sınaq zamanı təyinat icazəsini dar saxlayın və qaydası olmayan müştərinin xidmətə çatmadığını təsdiqləyin. Quraşdırılmış marşrutla qurulmuş assosiasiya verilmiş girişlə eyni şey deyil.