Bölünmüş DNS və VPN: domen qaydaları IP marşrutları deyil

Noutbukunuz intranet.corp adresini tunel vasitəsilə həll edir, gitlab.com isə provayderin həlledicisinə getməyə davam edir və bu, nəzərdə tutulduğu kimi işləyən quruluşdur. Bunu iki ayrı qərar yaratdı: ad uyğunluğu qaydası həlledicini seçdi, marşrut isə cavabı geri gətirdi. Hər hansı birini pozun, brauzer xaricdən eyni görünən nasazlıq göstərir. Bölünmüş DNS hesabatlarının əksəriyyəti ikinci nasazlığı təsvir edərkən birincisi barədə sübut gətirir.

İki yarım müxtəlif yerlərdə yaşayır və adətən müxtəlif insanlar tərəfindən redaktə olunur. Biri VPN profilə bağlanmış DNS siyasətidir, digəri tunelin quraşdırdığı və ya saxladığı marşrutdur. Heç kim hansı yarımın həqiqətən dəyişdiyini müəyyən etmədikdə sazlama dayanır.

Bir sorğuda gizlənən iki qərar

Ad yarısı marşrut deyil, siyasət obyektidir. Windows-da bu, VPN profildə ad həlli siyasətidir; Apple platformalarında DNS parametrlər obyektində uyğun domenlər toplusu; Linux-da marşrutlaşdırma domeni, bölünmüş həlledici sətri və ya ad xidməti keçid sırasıdır. Yol yarısı adi marşrutlaşdırmadır, tunel və ya əl ilə quraşdırılır və onun host adı barədə heç bir təsəvvürü yoxdur. Şəkilçiyə icazə verən profil yalnız kimin cavab verəcəyini həll edir; cavabı heç vaxt əlçatan etmir.

Sürətli simptom testi onları ayırır: adı ünvanla əvəz edin. Ünvan işləyirsə, yol qaydasındadır və qayda səhvdir. Ünvan da uğursuz olursa, qayda doğru, yol isə çatışmayan ola bilər.

Hər platforma eyni ad qaydasını necə ifadə edir

Məqsəd eynidir, sahə adları isə deyil. Bir müştəridən digərinə köçürülən nümunə təmiz şəkildə təhlil olunur və heç vaxt uyğun gəlmir. Üç forma belə görünür:

Uyğunluq və ya marşrutlaşdırma domeni şəkilçi testidir, yəni intranet.corp git.intranet.corp-u əhatə edir, corp.intranet-i isə əhatə etmir və onu tərsinə çevirmək bütün quruluşda ən çox rast gəlinən səhvdır. Windows bu xəritələməni profilə bağlanmış ad həlli siyasəti kimi daşıyır və interfeysin artıq malik olduğu şəkilçi siyahısına qarşı öz üstünlük sırasına malikdir. Apple platformaları uyğun domenləri şəbəkə uzantısının DNS parametrlər obyektinə bağlayır və sistem onları hər əhatəli həlledici üzrə tətbiq edir. Bu formaların heç biri marşrut deyil və heç biri əlçatmaz ünvanı əlçatan edə bilməz. Windows ad həlli siyasəti arayışı həmin platforma üçün sahə adlarını və üstünlük qaydalarını sadalayır və onlar Apple və ya systemd sənədlərinin istifadə etdiyi qaydalar deyil.

Düzgün cavab yenə də yol tələb edir

Həlledici cavabı sadəcə ünvandır və tətbiq yenə də ora çatmalıdır. Bölünmüş tunel dizaynı adətən 10.20.0.0/16 marşrutunu itələyir və standart marşrutu saxlayır, beləliklə daxili ad həll olunur, sonra isə bağlantı asılır. Əks hal da eyni dərəcədə geniş yayılmışdır: marşrut mövcuddur, ictimai həlledici şəxsi ada NXDOMAIN cavabı verir və nasazlıq marşrut problemi kimi qeydə alınır. Əvvəlcə yolu test etmək sizi heç vaxt həll olunmayacaq bir ad üçün marşrutlara baxmağa məcbur edir.

Hər iki yarımın əhatə etmədiyi üçüncü bir qapı da var. Şlüzdəki ACL, firewall qaydası və ya müştəri tərəfindəki siyasət hər iki qərar düzgün olduqdan sonra bağlantını qopa bilər. Ad həll olunur, marşrut mövcuddur və bağlantı yenə də vaxt aşımına uğrayırsa, DNS-i test etməyi dayandırın.

Adları və yolları sabit sıra ilə test etmək

Bir sıra seçin və ona əməl edin, əks halda ən son uğursuz olan addımı təqib edəcəksiniz. Sənədləşdirilmiş tam daxili adı həll edin, cavabın marşrut cədvəlinin daşıya biləcəyi ünvan olduğunu təsdiqləyin, sonra tunelin hər şeyi tutmadığını sübut etmək üçün ictimai adla təkrarlayın. systemd hostunda sorğu ilə həlledicinin marşrutlaşdırma domeni bir əmr aralığındadır:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Windows müştərisi eyni iki sualı fərqli cmdlet-lərlə soruşur. İkincisi sistemin həqiqətən istifadə edəcəyi interfeysi bildirir:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Axtarış ünvan qaytarır və yol yoxlaması fiziki interfeysi göstərirsə, ad qaydası işlədi, marşrut isə işləmədi. Qısa ad uğursuz olur, tam ad isə həll olunursa, şəkilçi siyahısı səhvdir, həlledici deyil.

Müqayisənin adətən səhv getdiyi yer

Birinci səhv əlaqəsiz ictimai həlledicidən şəxsi ad barədə soruşmaq və imtinanı VPN barədə sübut kimi oxumaqdır. İkincisi işləyən ictimai axtarışın tunelin həlledici yolunu sübut etdiyini güman etməkdir. Üçüncüsü bölünmüş tunel və bölünmüş DNS-i tək dizayn qərarı kimi qəbul etməkdir, halbuki yerləşdirmə birində düzgün, digərində pozulmuş ola bilər. Hər səhv heç vaxt günahlandırılan hissəni sınaqdan keçirməyən testdən inamlı nəticələr çıxarır.

Öz təhlükəsiz DNS-i olan brauzer də sistem qaydasını yan keçə bilər, buna görə bir brauzerin uğursuz, digərinin uğurlu olması ziddiyyət deyil. Cavab verən həlledici ilə müqayisə edin, şikayət edən brauzerlə deyil.

Hər iki yarım görünən olduqda, qalan sual texniki deyil, siyasət sualıdır: hansı ad məkanları təşkilata aiddir, hər cavaba kim sahibdir və onlardan hansı maşından ümumiyyətlə çıxmalıdır. Bunu profilin yanında yazın, çünki qaydaya toxunacaq növbəti şəxsə bu lazım olacaq.