Bölünmüş tunel sənədləri hər marşrutun yanında DNS qaydası tələb edir
Marşrut ünvana görə, həlledici isə ada görə qərar verir. Hər axın üçün hər iki seçicini bir sınaqla sənədləşdirin, əks halda DNS dəyişəndə qeyd uğursuz olur.
«Ofis trafiki VPN-dən keçir» deyən split-tunnel qeydi bir qərarı sənədləşdirmiş və daha üçünü nəzərdə tutmuş olur. Paket qatında marşrut cədvəli interfeysi təyinat ünvanına görə seçir; ad qatında həlledici serveri sorğuya görə seçir və bu iki seçim bir-birindən asılı olmayaraq edilir. Buna görə düzgün sənədləşdirilmiş prefiks yenə də daxili adı ictimai ünvana həll edən, ya da marşrut mükəmməl görünərkən heç nə həll etməyən maşın yarada bilər.
İki seçici, bir bağlantı cəhdi
Tətbiq files.corp.example ünvanına qoşulduqda, paket yaranmazdan əvvəl iki axtarış baş verir. Həlledici sorğunu hansı serverin alacağına axtarış domenləri, hər keçid üçün marşrut domenləri və ya açıq profil qaydası ilə qərar verir. Sonra marşrut cədvəli yaranan ünvanın hara gedəcəyini təyinatla ən uzun prefiks uyğunluğuna görə qərar verir.
Bu iki qərarı heç nə birləşdirmir. Şəxsi zona 10.20.4.11 ilə cavab verə bilər, marşrut cədvəli isə 10.20.0.0/16 aralığını tunelə göndərir və bağlantı işləyir. Hər hansı birini çevirin və digərinə bənzəyən şəkildə uğursuz olur: düzgün DNS siyasəti üstəgəl itkin marşrut həll olunmuş ad və fasilə verir, düzgün marşrut üstəgəl ictimai həlledici isə təmiz şəkildə yanlış yerə yönələn ünvan verir.
Split-horizon DNS bunu daha da kəskinləşdirir. Eyni ad daxili həlledicidən şəxsi ünvan, internetə baxan həlledicidən isə ictimai ünvan qaytara bilər, ona görə yalnız prefiksi qeyd edən qeyd müştərinin faktiki hansı ünvandan istifadə edəcəyini proqnozlaşdıra bilməz. Həlledici yolunu yazın, əks halda ünvan təxmindir.
Yalnız marşrut qeydinin buraxdığı şeylər
Yalnız marşrut qeydi ən çox yayılmış split-tunnel nasazlığı üçün yararsızdır: adlar. İstifadəçi bildirir ki daxili şəbəkə açılmır, tunel qalxıb və prefiks mövcuddur. Təkmili götürən şəxsin hansı həlledicinin cavab verməli olduğuna dair qeydi yoxdur, səhv axtarış şəkilçisini bloklanmış serverdən ayırmağın yolu yoxdur və müqayisə üçün baza xətti yoxdur.
İkinci buraxılış istisnalar siyahısıdır. Split-tunnel dizaynı tunelə nəyin girdiyi qədər tuneldən kənarda nəyin qaldığı ilə də müəyyən edilir və xaric edilmiş aralıqlar adətən ilk pozulanlardır, çünki daha konkret yerli marşrut və ya müştəri tərəfindəki filtr profilə toxunmadan niyyəti üstələyə bilər.
Üçüncüsü tunelin uzaq tərəfidir. Müştəri marşrutu paketi yalnız naqilə qoyur; şlüz hələ də onu yönləndirməli və geri yol olmalıdır. strongSwan-ın yönləndirmə təlimatı şlüzdəki yönləndirmə və firewall qaydalarının xüsusiyyətin hissəsi olduğunu, güman edə biləcəyiniz santexnika olmadığını xatırladır.
Qeydi icra edilə bilən edən sahələr
Hər axın üçün bir sətir, axın isə təyinat üstəgəl ad üstəgəl sahibdir. Bunlar real hadisə ilə təmasda davam edən sahələrdir:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
"Harada yaşayır" sətri insanların atladığı sətirdir. Serverin itələdiyi prefiks, müştəri profilinə əlavə edilən marşrut və shellə yazılan marşrut onları kimin dəyişə biləcəyi və yenidən qoşulmadan sonra qalıb-qalmadığı ilə fərqlənir. Bu sahə olmadan növbəti mühəndis üçündən hansına baxdığını deyə bilməz.
Hər qayda üçün bir sınaq, hər tunel üçün deyil
Hər sətir iki zərərsiz yoxlama tələb edir: biri marşrutu, biri adı işlədir. Marşrut üçün tuneldən keçməli olan bir şey istəyin və çatımlılığı deyil, yolu təsdiqləyin, məsələn tracert -d 10.20.4.11 Windows-da və ya ip route get 10.20.4.11 Linux-da. Ad üçün şəxsi adı sorğulayın və hansı serverin cavab verdiyini qeyd edin, qeydin göstərdiyi həllediciyə qarşı resolvectl query files.corp.example və ya dig files.corp.example istifadə edərək.
Mənfi gözlənti də əlavə edin: tunel söndükdə nə olmalıdır. VPN olmadan blokla aktivləşdirilmiş Android və ya iOS cihazındakı xaric edilmiş tətbiqin ümumiyyətlə bağlantısı olmaya bilər, iş masası müştərisi isə tunel yenidən qoşularkən həmin tətbiqi işlək saxlaya bilər. Nəzərdə tutulan cavabı qeyd etmək "VPN tətbiqimi pozdu" ifadəsini yoxlanıla bilən ifadəyə çevirir.
Qeydi konfiqurasiya ilə saxlayın
Qeydi təsvir etdiyi profilin yanında saxlayın və onu həmin profillə versiyalayın. Heç kimin yeniləmədiyi wikidəki sənəd şaiyədir; itələnmiş marşrutlarla və həlledici siyasəti ilə eyni repozitoriyadakı cədvəl eyni dəyişiklikdə nəzərdən keçirilə bilər.
Nəsə pozulanda, başqa istisna əlavə etməzdən əvvəl tətbiq olunmuş marşrutu və effektiv həlledicini qeydlə müqayisə edin. Üç ümumi səbəbdən ikisi — köhnə ad sahəsi qaydası və tətbiq siyasətindən kənar köməkçi proses — tam olaraq VPN nasazlığı kimi görünür və qeyd yalnız prefiksləri sadalayırsa görünməz qalır.
Qeydi bitmiş saymazdan əvvəl onun bunlara yazılı cavab verdiyini təsdiqləyin: hansı prefiks, hansı ünvan ailəsi üçün; hansı şəxsi ad sahəsi, hansı həlledici tərəfindən cavablandırılır; hansı adlar qəsdən ictimai qalır; hər qayda harada konfiqurasiya olunur və kimə aiddir; və marşrutu sübut edən bir əmr və adı sübut edən bir əmr. Bunlardan hər hansı biri yoxdursa, növbəti hadisə sıfırdan diaqnoz ediləcək.