VPN DNS ishlaydi, lekin .local nomlari hali ham ishlamayapti: ularni kim hal qiladi?

Bitta VPNdagi ikki mashina, bir xil xost nomi, va ulardan faqat biri uni hal qiladi: farq odatda tunnelda emas, qaysi hal qiluvchi javob berganida. Linux ish stolida bu nom nom xizmati kaliti orqali, systemd-resolved stubi orqali yoki ilova o'zi bilan olib kelgan hal qiluvchi orqali o'tishi mumkin, va ularning har biri bir xil suffiksga o'z qoidasini qo'llaydi. Qoidalar aynan suffiksda ajraladi, chunki .local betaraf yorliq emas. Biror narsaning qanday tartibda ishlashini o'zgartirishdan oldin muvaffaqiyatsiz dastur aslida qaysi yo'lni bosib o'tishini aniqlang.

Ikki hal qiluvchi, ikki xil javob

An'anaviy glibc qidiruvi nsswitch.conf ning hosts: satrini bosib o'tadi va bittasi javob berguncha har bir moduldan navbat bilan so'raydi. Stub tinglovchisi orqali systemd-resolved bilan gaplashadigan mijoz buning o'rniga bitta jarayondan so'raydi, va bu jarayon har bir ulanish uchun siyosatni hamda o'zining maxsus holatlarini qo'llaydi. O'z hal qiluvchisini olib keladigan yoki shunday qiladigan kutubxonani bog'laydigan ilova ikkalasini ham chetlab o'tishi mumkin. Shunday qilib bitta xost nomining bitta mashinada uchta egasi bo'lishi mumkin, va ulardan faqat bittasi VPN nima niyat qilganini biladi.

Biror narsani o'zgartirishdan oldin egasini aniqlang, chunki tuzatish uchalasining har biri uchun boshqacha. Bitta ish stolidagi brauzer va buyruq satri vositasi qonuniy ravishda kelishmasligi mumkin, va bu kelishmovchilik belgi, xato emas. Agar brauzer nomni hal qilsa, vosita esa qilmasa, siz hal qiluvchi yo'lini tuzatyapsiz, VPN yo'lini emas. Yo'lni alohida tasdiqlang, shunda marshrutlash nosozligi nom xizmati nosozligi bilan aralashtirilmasin. Ikkalasi kelishsa, nosozlik xostdan yuqorida va bu yerdagi hal qiluvchi konfiguratsiyasi yana bir tuzatishga arzimaydi.

Qaysi buyruq haqiqatan sizning hal qiluvchingizdan so'radi

Faqat o'qish uchun ikki buyruq bog'liq savollarga javob beradi, va ularni solishtirish konfiguratsiyani o'qishdan tezroq muammoni joylashtiradi. Haqiqiy ichki nomdan foydalaning va natijani maxfiy saqlang, chunki ichki yozuvlar ichki bo'lib qoladi. Ikkalasini ham muvaffaqiyatsiz dastur ishlayotgan o'sha sessiyada ishga tushiring:

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

Birinchisi sozlangan modullar orqali so'raydi, oddiy dastur shuni boshdan kechiradi. Ikkinchisi systemd-resolveddan to'g'ridan-to'g'ri so'raydi va javob bergan ulanish, protokol va serverni xabar qiladi. Serverdan manzil bo'yicha so'rash faqat serverda yozuv borligini isbotlaydi, chunki u ilova hech qachon so'raganmi yo'qmi haqida hech narsa demaydi. VPNni olib yuruvchi ulanishni va u da'vo qilayotgan domenlarni o'qing, so'ng bu ro'yxatni muvaffaqiyatsiz nomdagi suffiks bilan solishtiring.

Nega .local sizning unicast zonangizni chetlab o'tadi

systemd-resolved ma'lumotnomasi ga ko'ra .local bilan tugaydigan ko'p yorliqli nomlar mDNS yoqilganda odatdagi unicast DNSga emas, odatda multicast DNSga boradi. RFC 6762 bu nom maydonini link-local multicast uchun ajratadi, shuning uchun korporativ zona o'sha suffiks uchun hech qachon so'ralmaydigan to'g'ri yozuvni saqlashi mumkin. Tunnel hal qiluvchini mukammal marshrutlay oladi va baribir poygada yutqazadi. Keshdan muvaffaqiyatli ping hozirgina bo'lgan qidiruv haqida hech narsa demaydi.

Hujjatlashtirilgan istisno bor, va u bu holatlarning ko'pini hal qiladi: ulanish o'sha suffiksni qidiruv domeni yoki marshrutlash domeni deb e'lon qilsa, daemon uni unicast yo'lda ushlab turadi va multicast maxsus holatini o'tkazib yuboradi. Bu har bir ulanish uchun siyosat, global afzallik emas. Bir xil VPN serveriga ega ikki mashina bitta tarmoq profili domenni e'lon qilib, ikkinchisi qilmasa, turlicha harakat qilishi mumkin, shuning uchun yodda qolgan profilni emas, faol profilni o'qing.

Tor istisno global qayta tartiblashdan ustun

Nomini o'zgartira olmaydigan mavjud zona uchun hal qiluvchi va VPN egalari domenni uni olib yuruvchi ulanishda e'lon qilsin. O'sha bitta suffiks uchun marshrutlash domeni yozuvi va mo'ljallangan server manzili nomlangan egasi bilan kichik o'zgarish, va u qo'lda tahrirlangan faylda emas, ulanish bilan birga yashaydi.

U uzilishdan keyin ham saqlanadi, chunki ulanish qaytganda ulanish siyosati qayta qo'llanadi. Umumiy nsswitch.conf faylini tahrirlash jozibali va qimmatroq muqobil, chunki u mashinadagi har bir nom uchun qidiruv xatti-harakatini, jumladan mahalliy aniqlashni o'zgartiradi. Multicast daemonini o'chirish ham teng emas: u mahalliy xatti-harakatni olib tashlaydi, lekin hech bir hal qiluvchiga korporativ zonani o'rgatmaydi. Agar xizmat meros emas, yangi bo'lsa, uni tashkilotingiz boshqaradigan subdomenga joylashtiring va raqobatni butunlay chetlab o'ting. Nom firmwareda qotib qolgan yoki yorliqqa bosilgan bo'lsa tor istisnoni tanlang, va mijozni hali boshqarayotgan bo'lsangiz yangi subdomenni tanlang.

O'zgarishdan keyin nimani isbotlash kerak

Tuzatishni sinash uchun o'rnatgan asbob bilan emas, ilovaning o'z qidiruvi bilan isbotlang va uning o'rniga javob berishi mumkin bo'lgan har qanday keshni tozalang. So'ng hal qiluvchi yo'lini va javob bergan ulanishni tasdiqlang. Oxirida mahalliy aniqlash o'zgarishdan oldingidek harakat qilishini tekshiring, chunki ko'rinmay qolgan printer odamlar eng oxirida payqaydigan qismdir. Bu uch buyruq nom, yo'l va TLS identifikatorini aynan shu tartibda tekshiradi:

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

To'g'ri manzil noto'g'ri sertifikat bilan qat'iy mijozni baribir muvaffaqiyatsiz qiladi, shuning uchun hal qilish ishlagandan keyin ilova kutgan nomni tekshiring. Xizmat ulanishlarni faqat ofis diapazonidan emas, VPN manzilidan ham qabul qilishini tasdiqlang. Domen doirasi, server va egasini ulanish hujjatlariga yozing. Aks holda bu nosozlikka duch kelgan keyingi odam siz hozir chetlab o'tgan o'sha global tahrirga murojaat qiladi.