Niyə resolv.conf VPN DNS-ini göstərir, axtarışlar isə ona məhəl qoymur

Jurnallarda qəribə heç nə yoxdur: interfeys işləyir, həlledici VPN-in DNS serverini bildirir və diskdəki fayl onu sadalayır. Yenə də daxili host adı lokal marşrutlaşdırıcı vasitəsilə həll olunur. Bu üç ifadə bir-birinə zidd deyil, çünki fayl, hər keçidin vəziyyəti və axtarış yolu eyni adı təsadüfən bölüşən fərqli obyektlərdir. Aşağıda systemd-resolved işləyən hostda sorğunun həqiqətən keçdiyi yol göstərilir.

resolv.conf adlı üç obyekt

resolved işləyən hostda /etc/resolv.conf adətən /run/systemd/resolve/stub-resolv.conf faylına simvolik keçiddir. Həmin hədəf lokal stub dinləyicisinin ünvanını, 127.0.0.53, üstəgəl resolved-in hesabladığı axtarış domenlərini saxlayır. Bu, vəziyyətin özü deyil, onun görünüşüdür.

Vəziyyət resolved-in hər keçid üzrə konfiqurasiyasında yaşayır, buna görə də resolvectl status faylla ziddiyyət təşkil edə və yenə də haqlı ola bilər. Hər keçid öz serverlərini və öz marşrut domenlərini daşıyır, stub isə sorğu gələndə həmin keçid məlumatına müraciət edir. systemd-resolved təlimatı yaradılan faylları və hər keçid modelini təsvir edir; görünüşlə vəziyyət arasındakı ayrılıq yadda saxlamağa dəyər hissədir. Simvolik keçidin hədəfini dəyişmək ənənəvi müştərilərin oxuduğunu dəyişir, həlledicinin bildiyini yox.

Üçüncü obyekt, /run/systemd/resolve/resolv.conf, hər keçidi bir server siyahısına düzür. Həmin fayla yönəlmiş proqram sorğuları birbaşa sadalanan serverlərə göndərir və stub-u keçir, ona görə hər keçid siyasəti artıq ona aid deyil. Beləliklə, eyni maşındakı iki proqram eyni ada fərqli cavab verə bilər və heç biri pozulmayıb.

NSS vasitəsilə bir axtarışı izləyin

glibc ada kimin cavab verəcəyini müəyyən etmək üçün /etc/nsswitch.conf faylını oxuyur. Tərkibində resolve olan hosts sətri sualı nss-resolve ünvanına yönəldir, o da resolved-dən D-Bus üzərindən soruşur və hər keçid cavabını alır. Yalnız files dns olan sətir sorğunu /etc/resolv.conf-in saxladığı ünvana göndərir.

Bu bir sətir brauzerla dig arasındakı ziddiyyətlərin çoxunu izah edir. dig resolv.conf faylını birbaşa oxuyur və NSS-ə heç toxunmur, ona görə tətbiqin istifadə etdiyi yolu deyil, stub-u və ya yuxarı serveri yoxlayır. getent hosts internal.example isə NSS-dən keçir və onun cavabını dig-inki ilə müqayisə etmək ilk faydalı ölçmədir.

Öz həlledicisini daşıyan və ya sabit son nöqtəyə HTTPS üzərindən DNS danışan tətbiqlər hər iki yolu yan keçir. Nə resolv.conf, nə də resolved vəziyyəti onları məhdudlaşdırır.

Faylın kimə aid olduğunu və hara yönəldiyini yoxlayın

Nəyisə dəyişməzdən əvvəl keçid zəncirini oxuyun, çünki hansı faylın səlahiyyətli olduğunu mülkiyyət həll edir. Aşağıdakı hər əmr yalnız vəziyyəti oxuyur.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Birinci sətir keçidi və hədəfini birlikdə çap edir və VPN skriptinə aid adi fayl həlledicinin o yazını heç vaxt giriş kimi qəbul etməməsi deməkdir. Status çıxışı hər keçid serverlərini və hər sorğunun hara getdiyini müəyyən edən marşrut domenlərini sadalayır. nsswitch sətri stub-a ümumiyyətlə müraciət edilib-edilmədiyini bildirir, yəni faylda stub ünvanı var, amma orada resolve yoxdursa, sorğular lokal dinləyiciyə çatır, ayrılığı isə heç nə idarə etmir. Son sadalama da vacibdir, çünki stub-resolv.conf olmayan host burada təsvir olunan quruluşu işlətmir.

Zəncir başqa paketin idarə etdiyi faylda bitirsə, VPN müştərisi və həmin paket barışdırılmalı iki sahibdir. Keçidi dəyişdirmək bir sahibin işini atır, digərininkini isə yerində qoyur.

Keçid sahibində bərpa edin

VPN bağlantısı serverlərini və domenlərini öz keçidində qeydiyyata almalı, sonra qoşulma kəsiləndə onları geri götürməlidir. NetworkManager-in resolved inteqrasiyası və müştərinin öz köməkçisi bu cür işləyir; yalnız resolv.conf faylını yenidən yazan skript isə yox.

Artıq mövcud olan keçiddə işləmə vaxtı ayarları mexanizmi göstərir. resolvectl dns tun0 10.40.0.53 bir server qoşur, resolvectl domain tun0 '~corp.example' isə marşrut domeni qoşur. Tilda daşıyıcı simvoldur: həmin şəkilçi üzrə sorğuları bu keçidlə məhdudlaşdırır və qalan hər şeyi toxunulmaz qoyur, onsuz isə eyni dəyər axtarış domeninə çevrilir və ayrılıq buxarlanır. Həmin ünvanlar laboratoriya nümunələridir, daimi konfiqurasiya deyil. resolvectl query host.corp.example ilə təsdiqləyin və hansı keçidin cavab verdiyini oxuyun.

Qeydiyyata alınmış server yenə də marşruta ehtiyac duyur. Sorğu düzgün keçidə çatıb vaxt aşımına uğrayırsa, qüsur həlledici mülkiyyətində deyil, tuneldən keçən əlaqədədir.

İşlək vəziyyət necə görünür

Sağlam nəticə üç görünüşün hamısında uyğundur: hər keçid serverləri VPN-in verdiyi ilə üst-üstə düşür, marşrut domenləri yalnız daxili şəkilçiləri əhatə edir və vacib tətbiq daxili adı həll edir, açıq ad isə yenə lokal yolu izləyir. Bir uğurlu sorğu bu razılaşmadan daha az şey sübut edir.

Sonra bağlantını kəsin və hər iki sorğunu təkrarlayın. Sökülmədən sonra domenlərini qeydiyyatda saxlayan müştəri saatlar sonra daxili axtarışları uğursuz olan maşın yaradır, nə açıq tunel, nə də aydın səbəb olur.