VPN DNS işləyir, amma .local adları yenə də uğursuz olur: onları kim həll edir?

Eyni VPN-də iki maşın, eyni host adı, amma onlardan yalnız biri onu həll edir: fərq adətən tuneldə deyil, hansı həlledicinin cavab verməsindədir. Linux masaüstündə bu ad ad xidməti keçidindən, systemd-resolved-in stubundan və ya tətbiqin özü ilə gətirdiyi həlledicidən keçə bilər və bunların hər biri eyni şəkilçiyə öz qaydasını tətbiq edir. Qaydaların ayrıldığı yer məhz şəkilçidir, çünki .local neytral etiket deyil. Bir şeyin hansı sırada işlədiyini dəyişməzdən əvvəl uğursuz proqramın həqiqətən hansı yolu getdiyini müəyyənləşdirin.

İki həlledici, iki fərqli cavab

Ənənəvi glibc axtarışı nsswitch.conf faylının hosts: sətrini gəzir və hər modulu bir-bir cavab verənə qədər sorğulayır. systemd-resolved ilə stub dinləyicisi vasitəsilə danışan müştəri isə əvəzində tək bir prosesi sorğulayır və həmin proses hər keçid üzrə siyasəti üstəgəl öz xüsusi hallarını tətbiq edir. Öz həlledicisini gətirən və ya bunu edən kitabxananı linkləyən tətbiq hər ikisini yan keçə bilər. Beləliklə, bir host adının bir maşında üç sahibi ola bilər və onlardan yalnız biri VPN-in nə nəzərdə tutduğunu bilir.

Hər şeyi dəyişməzdən əvvəl sahibi müəyyən edin, çünki düzəliş üçünün hər biri üçün fərqlidir. Eyni masaüstündə brauzer və əmr sətri aləti qanuni olaraq fərqli fikirdə ola bilər və bu fərq xəta deyil, ipucudur. Brauzer adı həll edirsə, alət etmirsə, siz VPN marşrutunu deyil, həlledici yolunu sazlayırsınız. Marşrutu ayrıca təsdiqləyin ki, marşrut xətası ad xidməti xətası ilə qarışdırılmasın. İkisi də razılaşdıqda xəta hostdan yuxarıda olur və buradakı həlledici konfiqurasiyası başqa bir düzəlişə dəyməz.

Hansı əmr həqiqətən sizin həlledicinizi sorğuladı

İki yalnız-oxuma əmri əlaqəli suallara cavab verir və onları müqayisə etmək konfiqurasiyanı oxumaqdan daha tez problemi lokallaşdırır. Real daxili ad istifadə edin və çıxışı məxfi saxlayın, çünki daxili qeydlər yenə daxili qalır. Hər ikisini uğursuz proqramın işlədiyi eyni sessiyada işlədin:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Birincisi konfiqurasiya edilmiş modullar vasitəsilə soruşur, tipik proqramın yaşadığı da budur. İkincisi birbaşa systemd-resolved-dən soruşur və cavab verən keçidi, protokolu və serveri bildirir. Korporativ serveri ünvanla sorğulamaq yalnız serverin qeydi saxladığını sübut edir, çünki tətbiqin ondan heç soruşub-soruşmadığı barədə heç nə demir. VPN-i daşıyan keçidi və onun iddia etdiyi domenləri oxuyun, sonra bu siyahını uğursuz addakı şəkilçi ilə müqayisə edin.

Niyə .local sizin unicast zonasını keçir

systemd-resolved sənədi deyir ki, .local ilə bitən çoxetiketli adlar mDNS aktiv olduqda adi unicast DNS-ə deyil, adətən multicast DNS-ə gedir. RFC 6762 bu ad sahəsini link-local multicast üçün ayırır, ona görə korporativ zona həmin şəkilçi üçün heç vaxt müraciət olunmayan düzgün qeyd saxlaya bilər. Tunel həlledicini mükəmməl yönləndirə və yenə də yarışı uduza bilər. Keşdən uğurlu ping, indicə baş verən axtarış haqqında heç nə demir.

Sənədləşdirilmiş bir istisna var və bu halların çoxunu həll edir: keçid həmin şəkilçini axtarış domeni və ya marşrutlaşdırma domeni kimi elan etdikdə, daemon onu unicast yolunda saxlayır və multicast xüsusi halını keçir. Bu, qlobal üstünlük deyil, hər keçid üzrə siyasətdir. Eyni VPN serveri olan iki maşın, bir şəbəkə profili domeni elan edib digəri etmədikdə fərqli davrana bilər, ona görə yaddaşınızda redaktə etdiyinizi deyil, aktiv profili oxuyun.

Dar istisna qlobal yenidən sıralamadan üstündür

Adını dəyişə bilmədiyiniz mövcud zona üçün həlledici və VPN sahiblərinə domeni onu daşıyan bağlantıda elan etməyi tapşırın. Həmin bir şəkilçi üçün marşrutlaşdırma domeni qeydi üstəgəl nəzərdə tutulan server ünvanı adlı sahibi olan kiçik bir dəyişiklikdir və əl ilə redaktə olunan faylda deyil, keçidlə birlikdə yaşayır.

O, həmçinin qopmadan sonra da qalır, çünki keçid qayıtdıqda keçid siyasəti yenidən tətbiq olunur. Ortaq nsswitch.conf faylını redaktə etmək cəlbedici və daha bahalı alternativdir, çünki o, maşındakı hər ad üçün axtarış davranışını, yerli kəşf daxil olmaqla, dəyişir. Multicast daemonunu söndürmək də ekvivalent deyil: o, yerli davranışı aradan qaldırır, amma heç bir həllediciyə korporativ zona haqqında öyrətmır. Xidmət miras qalmış deyil, yenidirsə, onu təşkilatınızın nəzarət etdiyi alt domenə qoyun və rəqabəti tamamilə keçin. Ad firmware-də sabitlənibsə və ya etiketdə çap olunubsa, dar istisnanı seçin; müştəriyə hələ də nəzarət edirsinizsə, yeni alt domen seçin.

Dəyişiklikdən sonra nəyi sübut etməli

Düzəlişi sınaq üçün quraşdırdığınız alətlə deyil, tətbiqin öz axtarışı ilə sübut edin və onun əvəzinə cavab verə biləcək hər hansı keşi təmizləyin. Sonra həlledici yolunu və cavabı verən keçidi təsdiqləyin. Nəhayət, yerli kəşfin dəyişiklikdən əvvəlki kimi davrandığını yoxlayın, çünki görünməkdən qalan printer insanların ən son fərq etdiyi hissədir. Bu üç əmr adı, yolu və TLS kimliyini bu sıra ilə yoxlayır:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Yanlış sertifikatlı düzgün ünvan ciddi müştəridə yenə də uğursuz olur, ona görə həll işlədikdən sonra tətbiqin gözlədiyi adı yoxlayın. Xidmətin yalnız ofis aralığından deyil, VPN ünvanından da bağlantı qəbul etdiyini təsdiqləyin. Domen əhatəsini, serveri və sahibi bağlantının sənədləşməsinə yazın. Əks halda bu uğursuzluqla qarşılaşan növbəti şəxs indicə qaçındığınız eyni qlobal redaktəyə əl atacaq.