OpenVPN-də route-nopull serverin nəyi göndərməsini həqiqətən dayandırır

route-nopull sətrini müştəri profilində tunelin standart marşrutunuzu udmasının qarşısını almaq üçün qoydunuz, indi isə ofis alt şəbəkəsi əlçatmazdır, müştəri isə hələ də qoşulduğunu göstərir. Hər iki müşahidə doğrudur və heç nə uğursuz olmayıb. Bayraq müştəriyə serverin göndərdiyi marşrutları və DHCP qeydlərini atlamağı tapşırır ki, bu da çoxlarının onu əlavə edərkən gözlədiyindən daha dar bir göstərişdir. Qalan şey, hansı təyinatların ondan istifadə etməli olduğuna dair heç bir fikri olmayan işlək bir tuneldir.

Bu boşluq məhz bu məqalənin mövzusu olan bütün qərardır. Ya server şəbəkəni təsvir edir, ya müştəri, və bayraq bu işi heç bir hissəsini sizin üçün etmədən müştəriyə verir.

Bayraq qoşulma zamanı nəyi söndürür

Çəkən OpenVPN müştərisi adətən autentifikasiyadan sonra serverdən paket alır: marşrutlar, standart şlüzün yönləndirilməsi, DNS serverləri və bir neçə tənzimləmə direktivi. route-nopull qüvvədə olduqda müştəri yenə sessiyanı qəbul edir, yenə sertifikatları yoxlayır, yenə şifrələri və keepalive-ları razılaşdırır və yenə interfeysi qaldırır. Atdığı şey göndərilən route sətirlərinin və göndərilən dhcp-option sətirlərinin tətbiqidir, DNS daxil olmaqla.

Qarışıqlıq ölü tətbiqin yanında duran yaşıl göstəricidən qaynaqlanır. Tunel mövcuddur; təyinatların o tunelə uyğunlaşdırılması isə yox. Müştərinin status panelində heç nə «qoşulub və yönləndirir» ilə «qoşulub və hərəkətsizdir» arasında fərq qoymur, çünki tunelin nöqteyi-nəzərindən hər ikisi eyni vəziyyətdir.

Niyə canlı tunel yenə də heç nəyi yönləndirə bilməz

İnterfeys öz ünvanı ilə görünür və nöqtədən nöqtəyə keçiddə çox vaxt həmyaşıdına host marşrutundan daha dəqiq heç nə olmur. Şəxsi alt şəbəkə yalnız hansısa marşrut düzgün prefikslə həmin interfeysə işarə etdikdə əlçatan olur və göndərmə söndürüldüyü üçün o marşrut heç vaxt gəlmir. Yüklənmiş profil də adətən kömək edə bilmir, çünki o, serverin məhz bu məlumatı verəcəyi fərziyyəsi ilə yazılıb. Buna görə interfeys sağlam görünə bilər, alt şəbəkə isə qaranlıq qalır.

Deməli, profili oxumaq çox az şey sübut edir. Bunun yerinə qoşulmuş maşında işləyən vəziyyəti oxuyun:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

İkinci əmrdə alt şəbəkə marşrutu olmayan ünvan bu problemin imzasıdır. Üçüncü əmr isə istifadəçilərin həqiqətən maraqlandığı suala cavab verir, çünki o, istifadə etməsini ümid etdiyiniz siyahını deyil, nüvənin konkret təyinat üçün seçəcəyi interfeysi bildirir. Əgər fiziki keçidinizdən cavab verirsə, tunel ümumiyyətlə yolda deyil.

Ad həlli ayrı bir səbəbdən deyil, əlaqəli bir səbəbdən uğursuz olur. Göndərilən dhcp-option DNS qeydləri eyni bayraqla atlanır, ona görə daxili hostlar üçün sorğular yerli şəbəkənin təqdim etdiyi həllediciyə gedir. Həmin həlledicinin ofis üçün zonası yoxdur, ona görə sorğu uğursuz olur və ya ictimai cavab qaytarır və nasazlıq server problemi kimi görünür, halbuki bu, müştəri konfiqurasiyası problemidir. İkisini ayıran şey addan əvvəl ünvanı sınaqdan keçirməkdir.

Bayraqla prefiks filtri arasında seçim

İki seçim eyni şikayətin fərqli formalarını həll edir və pis seçim məhz «qoşulub, amma faydasız» vəziyyətini yaradır. Biri göndərilən siyasəti tamamilə əvəz edir, digəri isə onu prefiksə görə redaktə edir. Cədvəl qısa variantı verir, ondan sonrakı abzas isə insanları çaşdıran hissəni əhatə edir.

pull-filter üç felli prefiks uyğunlaşdırıcısıdır, ona görə sətirlər ailəsini qəbul edə, onları səssizcə nəzərə almaya və ya prefiks göründükdə bağlantını tamamilə rədd edə bilər. Bu son davranış bilməyə dəyər olandır: rədd qaydası siyasət fərqini sakit bir buraxılmadan çox, uğursuz əl sıxışmasına çevirir. OpenVPN 2.6 təlimatı qəbul edilən prefiksləri və hər felin dəqiq semantikasını sadalayır.

Ümumi orta yol yalnız redirect-gateway sətrini rədd etmək və ofis marşrutlarının və DNS-in nəzərdə tutulduğu kimi gəlməsinə imkan verməkdir. Bu, serverin sizdən yaxşı başa düşdüyü hissələr üçün göndərməni işlək saxlayır və eyni zamanda standart marşrutunuzu ələ keçirəcək yeganə sətri qabaqlayır.

Marşrutları və həlledici əllə əlavə etmək

Bayrağı saxlayırsınızsa, profil serverin deyəcəyini deməlidir. Müştəri tərəfindəki route direktivləri bağlantı qurulduqdan sonra tətbiq olunur, ona görə bayraqla birgə işləyir, onun tərəfindən bloklanmır. Onları interaktiv əmr sətrində deyil, profildə saxlayın, əks halda növbəti yenidən qoşulma işlək vəziyyəti bərpa etməyəcək.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

DNS sətri narahat bir mövqedədir: bu, müştəri tərəfi direktividir, lakin bəzi müştərilər onu yalnız platformanın DNS inteqrasiyası vasitəsilə tətbiq edir və keçid dəyişdikdə onun üzərinə yaza bilər. systemd hostunda həlledici birbaşa tunel interfeysində təyin etmək, müştərinin prioritet yarışını qazanacağına ümid etməkdən daha proqnozlaşdırıla biləndir:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Yönləndirmə domeni ünvan qədər vacibdir. Onsuz ictimai adlar üçün sorğular da daxili həllediciyə göndərilə bilər və rekursiyadan imtina edən istənilən daxili həlledici şəxsi zonanı işlək qoyub gəzintini poza bilər. Onunla yalnız həmin şəkilçi altındakı adlar tunel həlledicisinə yönləndirilir, qalan hər şey fiziki keçidi izləyir.

Nəticəni yoxlamaq: ünvan, ad və xarici yol

Üç test mümkün nasazlıqları ayırır. Əvvəlcə şəxsi ünvanı IP ilə, sonra həmin hostu adla, sonra adi ictimai saytı götürün. İşləyən IP və uğursuz ad həllediciyə işarə edir; uğursuz IP və işləyən ad yönləndirməyə işarə edir; hər ikisinin uğursuz olması adətən tunelin yolda olmadığını bildirir.

Sonra içəriyə deyil, bayıra baxın. Tunelin son nöqtəsinin öz marşrutu dəyişikliyə tab gətirməlidir və hər hansı bloklama nasazlığı son nöqtəni tutmadan tunellə məhdudlaşdırılmalıdır. Tunel düşdükdən sonra gəzintiyə davam edən müştəri marşrut problemi deyil, siyasət problemidir və yuxarıdakı üç testin heç birində görünməyəcək.

Yekun siyahını profilin sənədləşməsinə yazın: marşrutlar, həlledici, domenlər və hər birinin mövcud olma səbəbi. Eyni cədvəli bərpa edən yenidən qoşulma yerli siyasətin tam olduğunun yeganə sübutudur. Tunel qalxarkən və üç testin hamısı keçərkən tətbiqlər hələ də uğursuz olursa, növbəti baxılacaq yer artıq yoxlanılmış sertifikatlar deyil, «qoşulub, amma oflayn» problemlər sinfidir.