Bir sətirdə həlledici ünvanı və şirkət domeni yazırsınız və yalnız həmin domendəki adların tunel həlledicisindən istifadə edəcəyini gözləyirsiniz. Apple müştərisində bütün adlar artıq oraya gedir və domendəki qısa adlar da həll olunur. Sətir iki ayrı iş görür və yalnız biri tunelin hansı sorğuları idarə etdiyinə aiddir. Digəri isə arzuolunan oxuma ilə siyasətə yüksəldilmiş yazma rahatlığıdır.

DNS sətri nəyə çevrilir

Müştəri girişi siyahı kimi oxuyur və hər elementi formasına görə təsnif edir. Ünvana oxşayan hər şey DNS serverinə çevrilir; domenə oxşayan hər şey axtarış şəkilçisinə çevrilir. Hər ikisi tunel parametrlərinə düşür, amma fərqli sahələrə. Şəxsi həlledici və bir daxili domen daşıyan tunel üçün nümunə sətir belə görünür.

DNS = 10.24.8.53, lab.internal.example

Ünvan həlledicini təmin edir. Domen müştəriyə qısa ad yazmağa və sistemin sorğudan əvvəl qalan hissəni əlavə etməsinə imkan verən şəkilçi təmin edir. Heç bir element həlledicinin həmin domenlə məhdudlaşdırılması barədə heç nə demir və insanların gözlədiyi, amma almadığı hissə məhz budur. Platformada yalnız bir sahə bu məhdudiyyəti ifadə edə bilər və bu, həmin sahə deyil.

İki Apple sahəsi, iki fərqli iş

Apple bu fərqi DNS parametrləri obyektində göstərir. Axtarış domeni siyahısı tək etiketli host adlarını kvalifikasiya etmək üçün istifadə olunan siyahı kimi sənədləşdirilib: çılpaq host adı yazın və sistem hər şəkilçini növbə ilə əlavə edə bilər. Bu tamamlama qaydasıdır, marşrutlaşdırma qaydası deyil. Həmin siyahıda heç nə hansı serverin soruşulacağını müəyyən etmir.

Uyğunluq domeni siyahısı fərqli bir xüsusiyyətdir. Hansı ad məkanlarının bu DNS parametrləri dəstindən istifadə edəcəyini müəyyən edir və boş giriş konkret şəkilçi deyil, standart domen deməkdir. paket tuneli parametrləri generatoru Apple müştərisində bu modelə əməl edir. Təhlil edilmiş axtarış şəkilçilərini axtarış siyahısına qoyur və serverlər varsa, uyğunluq siyahısını boş sətirə qoyur. Nəticə sistemin ona göndərdiyi hər şeyə cavab verən tunel həlledicisi və qısa adlara kömək edən bir şəkilçidir.

Yəni həmin sətirdəki domen ad məkanı seçicisi deyil. Başqa birini əlavə etmək tunelin istifadə etdiyi sorğuları daraltmır, onu silmək də genişləndirmir. Dəyişən yeganə şey neçə qısa adın tamamlandığıdır.

Niyə hər ad hələ də tunel həlledicisinə çatır

Boş uyğunluq girişi ilə tunel yalnız şirkət domeni üçün deyil, adi adlar üçün də namizəd həlledicidir. Tam tunel konfiqurasiyasında bunun əhəmiyyəti azdır, çünki bütün trafik onsuz da tuneldədir. Bölünmüş tuneldə bunun böyük əhəmiyyəti var. İctimai adlar indi yalnız şəxsi zona saxlayan həlledici tərəfindən həll oluna bilər və nasazlıq sınıq VPN kimi görünür, halbuki əslində ad məkanının yalnız bir hissəsinə cavab verən həlledicidir. Tunel qaydasındadır, sorğular çıxır və cavablar boş qayıdır.

İki düzəliş mövcuddur və bunlar fərqli qərarlardır. Tunel həlledicisini ictimai adları təsdiqlənmiş yoldan ötürən tam həlledici edin və ya ictimai adları ora göndərməyi dayandırın, domen siyahısı yerinə müştəri konfiqurasiyasını dəyişərək. Birincisi hər sorğunu tuneldə saxlayır və yuxarı axına güvənir. İkincisi bəzi sorğuları yerli saxlayır və tunel bağlı olanda şəxsi adların həll olunmaya biləcəyini qəbul edir.

Bölünmüş DNS əslində nəyi tələb edərdi

Ad məkanı ilə məhdudlaşan həlledici siyasəti onu ifadə etməyə imkan verən müştəri tələb edir: Apple platformalarında domenləri uyğunlaşdırın və ya istifadə etdiyiniz məhsulda ekvivalent parametr. Yalnız serverləri və şəkilçiləri qəbul edən konfiqurasiya sahəsi necə durğu işarələnsə də bunu ifadə edə bilməz. Profil bu siyasəti daşıya bilər, çünki o, qoşulma anı işarəsi deyil, idarə olunan konfiqurasiya təsvir edir. Domeni, serverləri və həmin domen əlçatmaz olduqda nə baş verməli olduğunu adlandıra bilər. Bu, parametrlə müqavilə arasındakı fərqdir.

İdarə olunan Apple cihazlarında bu, adətən domenə xas DNS parametrlərini daşıyan konfiqurasiya profili ilə verilir. Bu, WireGuard konfiqurasiya faylından fərqli mexanizmdir və ikisi yalnız müştəri profili hörmət edərsə birgə mövcud ola bilər. İki məhsulun eyni cür davrandığını güman etməzdən əvvəl müştərinizin sahəni həqiqətən necə adlandırdığını yoxlayın. Mac-dakı wg-quick skripti və iPhone-dakı WireGuard tətbiqi oxşar sətirləri oxuyur və onları fərqli qatlar vasitəsilə qurur.

Qurulmuş parametrləri oxuyun, konfiqurasiyanı yox

Mac-də sistemin nə ilə nəticələndiyini yoxlaya bilərsiniz, bu da yazdığınız faylı yenidən oxumaqdan daha çox məlumat verir. Həlledici siyahısı hansı serverlərin hansı domenlər üçün konfiqurasiya edildiyini göstərir və məhdud sorğular hansının qalib gəldiyini göstərir. Sətri təhrif edən müştəri bunu yazdığınız faylda deyil, burada göstərir. iOS-da ekvivalent əmr sətri yoxdur, ona görə də oradakı sübut nəticədir: tunel vasitəsilə həll olunan şəxsi ad və cavabı hansı həlledicinin cavab verdiyini göstərən ictimai ad.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Bu iki əmr cari həlledici konfiqurasiyasını və aktiv xidmətin DNS serverlərini çap edir. Tunel həlledicisi domen məhdudiyyəti olmayan standart həlledici kimi görünürsə, konfiqurasiya müştərinin istədiyini tam yerinə yetirir. Bunu mexanizmi dəyişərək düzəldin, ikinci şəkilçi əlavə edib davranışın dəyişəcəyinə ümid etməklə yox.

Əlaqəli məqalələr