openfortivpn qoşulduqda marşrutlara və DNS-ə kim sahib olmalıdır?

İşləyən openfortivpn sessiyasında dörd mərhələ bir-birinin üstünə yığılır. Müştəri şlüzdə autentifikasiyadan keçir və TLS bağlantısı başladır, sonra həmin bağlantı daxilində PPP işlədir, sonra ünvan və DNS məlumatı alır və nəhayət host marşrutlarını və resolver ayarlarını tətbiq edir. Hər mərhələ canlı ola bilər, halbuki növbəti deyil; buna görə də “qoşulub” sözü dəstək müzakirələrində bu qədər sürüşkəndir.

Qarışıqlığın çoxunu aradan qaldıran qərar son mərhələyə kimin sahib olmasıdır. Ya VPN müştərisi host dəyişikliklərini özü tətbiq edir, ya da başqa komponent bunu edir; ikisini yarı yolda qarışdırmaq marşrutların və resolver fayllarının fərqli sessiyaları təsvir etməsi ilə nəticələnir.

Bir bağlantı kimi görünən dörd mərhələ

Birinci mərhələ qəbuldur. adlandırılmış autentifikasiya domeni və ya birdəfəlik kod vasitəsilə davam etmək üçün lazım olan parametrləri alır. Müştəri şlüzə qoşulduğunu çap etdikdə, bu, TLS nəqlinin işlədiyini bildirir. Bu, PPP-nin razılaşdığını bildirmir və əlbəttə ki, daxili tətbiqin əlçatan olduğunu bildirmir.

İkinci mərhələ PPP bağlantısıdır. Müştəri tunel cihazına qarşı PPP prosesi başladır və tərəflər bağlantı seçimləri və ünvanlar barədə razılaşır. Yalnız bundan sonra host sessiyanın hansı yerli və uzaq ünvanları istifadə etdiyini bilir və yalnız o zaman tunelə yönələn marşrut məna kəsb edə bilər.

Üçüncü mərhələ həmin məlumatı hosta tətbiq etməkdir və sahiblik burada önəm daşıyır. Müştəri marşrutları əlavə edib resolver konfiqurasiyasını yenidən yaza bilər, ya da geri çəkilib hər ikisini həmin maşında şəbəkəni idarə edən digər şeyə buraxa bilər. Layihənin README bunları bir avtomatik davranış deyil, ayrı məsuliyyətlər kimi təsvir edir.

Marşrut cədvəlini kim redaktə edir

Susmaya görə sahib müştəridir. Fiziki interfeys vasitəsilə şlüzə doğru marşrut, tunelin qarşı tərəfi üçün marşrut və sessiyanın istifadəsinə icazə verilən şəbəkələr üçün marşrutlar əlavə edir, sonra proses çıxdıqda onları silir. Bu susmaya görə davranış tək şəbəkə meneceri olan və başqa VPN proqramı olmayan noutbukda rahatdır.

Təhvili yalnız başqa bir şey həqiqətən marşrutlaşdırmaya sahib olduqda seçin. Şəbəkə meneceri inteqrasiyası, konteyner şəbəkə ad sahəsi və ya sayt miqyaslı marşrutlaşdırma agenti eyni prefiksləri quraşdırmağı və təmizləməyi artıq bilə bilər. no-routes seçimini ötürmək onda iki yazıçının eyni cədvəl üzərində çəkişməsinin qarşısını alır; bu, təmiz nasazlıq əvəzinə bir subnetin fasilələrlə itkisi kimi görünən yarışdır.

Üst-üstə düşmə təhvil verməyin ikinci səbəbidir. Əgər ötürülən marşrutlara yerli şəbəkənin artıq istifadə etdiyi prefiks daxildirsə, müştəri konflikti sizin üçün həll edə bilməz. Kimsə həmin prefiksin tunel vasitəsilə, fiziki bağlantı vasitəsilə yoxsa daha konkret marşrut vasitəsilə əlçatan olduğuna qərar verməlidir və bu qərar topologiyaya sahib olanın işidir.

Təmizləmə üçüncüdür. Marşrutlarını silməzdən əvvəl çökən müştəri sessiyadan uzun yaşayan qara dəlik qoyur və növbəti bağlantı onun üstünə dublikat əlavə edə bilər. Marşrutlaşdırmaya sahib olan köhnə qeydlərin getdiyini yoxlamağa da sahibdir. Bu yoxlamanı başlanğıc yolunun hissəsi et, könüllü təmizləmə addımı deyil.

DNS-ə və resolver faylına kim sahibdir

DNS daha kəskin kənarları olan eyni qərardır. Müştəri şlüzün və ya PPP qarşı tərəfinin bildirdiyi DNS serverlərini qəbul edib onları host resolver konfiqurasiyasına yaza bilər. Sadə maşında bu tam istədiyiniz şeydir, çünki daxili adlar yalnız tunel işləyərkən həll olunur.

Müasir Linux hostunda resolveri yerli stub idarə edə bilər və resolver faylını həmin stubun arxasında yenidən yazmaq düzgün görünən, lakin uyğunsuz davranan konfiqurasiya yaradır. Əgər host artıq resolver meneceri işlədirsə, DNS-ə onun sahib olmasına icazə verin və tunelin serverlərini onun dəstəklənən interfeysi vasitəsilə ona ötürün. Müştərinin no-dns seçimi orada düzgün seçimdir, iş ətrafı deyil.

Split DNS faylı kimin yazmasından ayrı bir sualdır. Hər sorğunu tunel vasitəsilə göndərmək sadə və yavaşdır; yalnız daxili zonaları onun vasitəsilə göndərmək əksər sadə müştərilərin təqdim etmədiyi domen üzrə konfiqurasiya tələb edir. Müştərinin resolver dəyişikliklərini aktivləşdirməzdən əvvəl hostun hansı davranışa ehtiyacı olduğuna qərar verin. Burada yanlış seçim tunel özü yaxşı olsa da ad həllinin kəsilməsi kimi görünür.

İmtiyaz, hazırlıq və təhvil

Tunel cihazını yaratmaq və host marşrutlarını və ya resolver vəziyyətini redaktə etmək yüksək şəbəkə səlahiyyəti tələb edir. Ümumi səhv bundan nəticə çıxarmaqdır ki, buna görə hər şey root kimi işləməlidir, o cümlədən brauzer və ya tuneldən istifadə edən tətbiq. İmtiyazlı hissəni kiçik saxlayın: müştəri və onun konfiqurasiya faylı administratora məxsus olsun, istifadəçi tətbiqləri isə normal hesablarını saxlasın.

Hazırlıq hər istehlakçı üçün ayrıca müəyyən edilməlidir. Nəzarətçi xidmətin başladığını müştəri prosesi işləyəndə və tunel cihazı mövcud olduqda hesab edə bilər. Ehtiyat nüsxə işi VPN-i yalnız saxlanma son nöqtəsi tunel vasitəsilə cavab verdikdə istifadə oluna bilən hesab etməlidir. Bunlar fərqli yoxlamalardır və zəifini daha güclü məqsəd üçün istifadə etmək çox erkən başlayan və fasilələrlə uğursuz olan işlər yaradır. Seçilmiş tərifi yazın, çünki hazırlıq barədə razılaşmayan nəzarətçi və iş gözləyən dəstək bileti deməkdir.

Müqaviləni dörd müşahidə ilə yoxlayın: şlüz mərhələsi tamamlanır, PPP ünvanlar təyin edir, nəzərdə tutulan marşrut mövcuddur və daxili hosta sorğu uğur qazanır. Sonra müştərini dayandırın və bunların hər birinin silindiyini və ya bərpa olunduğunu təsdiqləyin. Əgər tunel bağlandıqdan sonra host hələ də daxili adları həll edirsə və ya hələ də marşrut saxlayırsa, sahiblik təhvili natamamdır.