Niyə /etc/hosts qeydiniz VPN-in DNS-inə çatmır

/etc/hosts faylına bir ad əlavə etdiniz, VPN-ə qoşuldunuz və qeydin hamı üçün görünəcəyini gözlədiniz. Belə olmur və sürpriz adətən ikinci simptomla gəlir: ad sizin maşınınızda həll olunur, həmkarınızda isə alınmır; bu, sınıq VPN DNS xidməti kimi görünür, əslində isə hosts faylı məhz dizayn edildiyi işi görür. Hosts faylı yerli ad həlli konfiqurasiyasıdır, zona yeniləməsi deyil və normal VPN bağlantısında heç nə onu yükləmir.

Hosts yerli üstünlükdür, zona yeniləməsi deyil

Fayl ad xidməti kitabxanalarının DNS serverinə müraciət etməzdən əvvəl və ya onun əvəzinə baxdığı uyğunlaşdırmalar siyahısıdır. 10.40.0.20 build.corp.example kimi bir sətir yalnız həmin maşındakı tətbiqlərin nəticəsini dəyişir. O, qeyd yaratmır, tuneldən keçmir və tunelin göstərdiyi DNS serverinin onun varlığından xəbəri olmur.

Uğursuzluğun asimmetrik olmasının səbəbi budur. Sizin müştəriniz fayldan cavab alır. Başqa müştəri VPN DNS serverinə sorğu göndərir, server heç nə qaytarmır və tətbiq adın mövcud olmadığını bildirir. Hər iki maşın düzgün davranır; yalnız birində digərinin heç vaxt görmədiyi üstünlük var.

İki əmr, iki fərqli komponent

Bu mübahisəni dayandırmağın ən sürətli yolu fərqi iki əmrdə görünən etməkdir; hər ikisi hosts qeydi olan müştəridə işlədilir:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Birincisi sistemin öz axtarış yolunu soruşur, tipik glibc sistemində bu, DNS-dən əvvəl yerli faylları oxuyur. İkincisi DNS sorğusunu birbaşa həmin ünvandakı serverə göndərir və yerli fayllara heç müraciət etmir. Birinci sizin qeydinizi, ikinci NXDOMAIN qaytardıqda, qeydin DNS-də olmadığını və maşınınızın yerli üstünlükdən cavab verdiyini sübut etmiş olursunuz.

Sıra konfiqurasiya oluna bilir və müəyyən bir distributiv haqqında nəticə çıxarmazdan əvvəl bunu yoxlamağa dəyər. /etc/nsswitch.conf faylındakı hosts: sətrinə baxın; hosts: files dns fayllara əvvəl baxır. Yalnız sıranı dəyişmək üçün bu nümunəni işlək konfiqurasiyanın üzərinə köçürməyin, çünki real sistemlər çox vaxt nümunədə olmayan əlavə mənbələr və şərti xidmət qeydləri sadalayır.

systemd-resolved testi bulandırır

systemd-resolved istifadə edən sistemdə yerli stub həm də hosts verilənlər bazasından adlar təqdim edir. Buna görə 127.0.0.53 ünvanına sorğu göndərmək uzaq serverin müstəqil testi deyil, hərçənd DNS sorğusuna bənzəyir və elə davranır. Resolverin nə bildiyini və hansı serverlərə müraciət edəcəyini bununla təsdiqləyə bilərsiniz:

resolvectl query build.corp.example
resolvectl status

Status çıxışı hər link üzrə DNS serverlərini göstərir və VPN linkinin ümumiyyətlə resolver alıb-almadığını belə öyrənirsiniz. Bu sual hosts qeydindən ayrıdır və şəxsi ad bir istifadəçi üçün deyil, bütün istifadəçilər üçün alınmadıqda verilməyə dəyər sualdır.

Tətbiqlər yenə başqa qat əlavə edə bilər. Öz DNS-over-HTTPS parametrinə malik brauzer, öz resolver konfiqurasiyası olan konteyner və ya prosesin ömrü boyu axtarışları keşləyən icra mühiti sistemdən fərqli cavab verə bilər. Bir əmrin maşındakı hər proqramı təsvir etdiyini fərz etmək əvəzinə sizi maraqlandıran tətbiqi sınaqdan keçirin.

VPN üzərində adı əslində nə paylaşır

Şəxsi ad hamı üçün işləməlidirsə, hamının resolverinin çata biləcəyi bir sahibə ehtiyacı var. Təmiz cavab qeydi idarə olunan zonada dərc etmək və həmin zonanı nəzərdə tutulan VPN DNS yolu ilə həll oluna bilən etməkdir. Sonra qeydin bir həqiqət mənbəyi, audit izi və həyat dövrü olur və heç kim hansı noutbukun yerli üstünlük daşıdığını xatırlamağa məcbur olmur.

Hosts fayllarını paylamaq qanuni alternativdir və bu, ad xidməti deyil, son nöqtə idarəetməsidir. Əgər bunu seçsəniz, fayl donanmanı idarə edən tərəfindən yerləşdirilməli, versiyalanmalı və silinməlidir və dizaynda məhz belə təsvir olunmalıdır. “VPN bunu həll edir” bu prosesin təsviri deyil.

Dinamik DNS qeydiyyatı öz icazələri, yeniləmə autentifikasiyası və qeyd ömrü ilə üçüncü mexanizmdir. O, hosts qeydindən irəli gəlmir və sadəcə qoşulan müştəridən də irəli gəlmir, məgər server və müştəri hər ikisi bunun üçün konfiqurasiya olunmayıbsa. Öz-özünə görünən qeyd kiminsə təhlükəsiz yeniləmələri aktivləşdirdiyinin və müştərinin özünü qeydiyyata aldığının əlamətidir və bu konfiqurasiya problem həlli müzakirəsinə deyil, dizayn qeydinə aiddir. Heç kim bu parametrin sahibini deyə bilmirsə, avtomatik qeydi təsdiqlənməmiş sayın və həqiqət mənbəyi kimi idarə olunan zonanı saxlayın.

Həll olunmuş ad marşrut deyil

Ad həlli və çatımlılıq ayrı şeylərdir və köhnəlmiş yerli uyğunlaşdırma onları qarışdırmağın klassik yoludur. Köçmüş ünvana işarə edən hosts qeydi DNS düzəldildikdən çox sonra da köhnəlmiş hostu seçməyə davam edəcək və simptom yaxşı həll olunan adda marşrut xətası kimi görünəcək.

Yəni hesabat “ad həll olunur, amma xidmət əlçatmazdır” olduqda, sistem axtarışını VPN DNS serverinə açıq sorğu ilə müqayisə edin, sonra aldığınız ünvanı xidmətin faktiki istifadə etdiyi ünvanla yoxlayın. systemd-resolved sənədi onun müraciət etdiyi yerli mənbələri sənədləşdirir və bu, həmin müqayisə üçün lazım olan xəritədir.

Sonra üstünlüyü onun sahibi vasitəsilə düzəldin. Öz hosts faylınızdan bir sətri silmək, eyni sətri yerləşdirmə skriptindən almış on iki noutbuk üçün heç nə etmir və insanların əslində yaşadığı bu problemin məhz həmin versiyasıdır.