Nima uchun ichki xost nomlari dig da hal bo’ladi, lekin curl da VPN da muvaffaqiyatsiz bo’ladi

Noutbukungiz VPN da, dig service.internal.example 10.x manzili bilan javob beradi, curl esa hali ham Could not resolve host bilan chiqadi. Tunnel muammo emas: u dig so’rovini shikoyatsiz yetkazdi. Farq savolni kim berishida. dig siz nomlagan bitta serverga bitta so’rov yuboradi, curl esa operatsion tizimning qidiruv zanjiridan o’tadi va bu zanjirning qaysi serverdan so’ralishiga oid o’z qoidalari bor.

Bitta nom uchun ikki qidiruv

dig — o’zining stub resolver i. U /etc/resolv.conf faylini o’qiydi, nom serverini tanlaydi, bitta A yoki AAAA so’rovini yuboradi va javobni chop etadi. U nsswitch ni butunlay chetlab o’tadi va systemd-resolved yoki NetworkManager shu fayldan tashqarida saqlaydigan bog’lanish bo’yicha holat haqida hech narsa bilmaydi, shuning uchun dig javobi to’g’ri bo’lishi mumkin, ammo baribir dasturingiz nima ko’rishi haqida hech narsa aytmasligi mumkin.

Dasturlar getaddrinfo ni chaqiradi, getaddrinfo esa uzunroq zanjirdan o’tadi: nsswitch modullarining tartibi, keyin nomni qayta ishlovchi modul va nihoyat joriy bog’lanish konfiguratsiyasidan qurilgan resolver. systemd mashinasida so’rov 127.0.0.53 ga ketadi va systemd-resolved tun interfeysiga bog’langan marshrutlash domeniga qarab har bir bog’lanish uchun yuqori server tanlaydi.

Ikki buyruq bu qatlamlarni taxmin qilmasdan ajratadi:

getent ahosts service.internal.example
resolvectl query service.internal.example

getent curl kabi bir xil yo’ldan foydalanadi, shuning uchun ishlayotgan dig yonidagi getent xatosi nosozlikni paket marshrutlashida emas, qidiruv siyosatida aniqlaydi. resolvectl query ham javob bergan interfeys va yuqori serverni chop etadi, bu qarorni tunnel bog’lanishi yoki jismoniy bog’lanish yutganini ko’rsatadi.

Dastur haqiqatan ishlatadigan resolver ni o’qing

/etc/resolv.conf aksariyat ish stollarida yaratiladi va VPN mijozi u bilan muloqot qilishning uch yo’li bor: nom serverini oldiga qo’yish, faylni qayta yozish yoki o’z serverlarini NetworkManager ga berib, demon uni qayta yozishiga ruxsat berish. Faqat uchinchi uslub bog’lanish bo’yicha DNS ni saqlaydi, chunki serverlar bitta global ro’yxatga tekislanib ketish o’rniga interfeysga bog’langan holda qoladi.

NetworkManager tizimlarida natija /etc/NetworkManager/NetworkManager.conf dagi backend ga bog’liq:

[main]
dns=systemd-resolved

dns=default bilan mijoz serverlari resolv.conf ga yutuvchi tartibda qo’shiladi va xususiy so’rov hali ham ommaviy resolver ga ketishi mumkin. Bog’lanishlarni tushunadigan backend bilan, systemd-resolved yoki dnsmasq, tunnel serverlari tunnel bilan cheklanib qoladi va u yerga faqat uning marshrutlash domeniga mos nomlar boradi. Bu cheklash split DNS amalda bildirgan narsa bo’lib, mijoz uni qo’llab-quvvatlayman deb da’vo qilganda eng ko’p yetishmaydigan qismdir.

Nimadirni o’zgartirishdan oldin holatni o’qing:

resolvectl status
resolvectl dns tun0

Siz tun interfeysining DNS server va xususiy suffiks uchun marshrutlash domeni bilan ro’yxatga olinganini, ~internal.example ko’rinishida ko’rsatilishini xohlaysiz. Bog’lanishda server yo’qligi mijoz hech narsa yubormaganini bildiradi. Domeni yo’q server so’rovlarning yo barchasi u yerga ketishini, yo hech biri ketmasligini bildiradi, mijozga qarab, va ikkalasi ham split DNS emas.

nsswitch qidiruvni juda erta tugatadigan joy

Oddiy ish stoli satri shunday ko’rinadi:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

mdns4_minimal multicast DNS bilan shug’ullanadi va .local bilan tugaydigan har qanday nomga da’vo qiladi. api.infra.svc.cluster.local kabi Kubernetes xizmati ham .local bilan tugaydi. mDNS moduli NOTFOUND xabar berganda, [NOTFOUND=return] amali dns moduliga o’tish o’rniga butun qidiruvni tugatadi, shuning uchun nom hech qachon VPN resolver iga yuborilmaydi. dig faylni butunlay chetlab o’tadi va aynan shu sababdan ikki vosita kelishmaydi.

Bu bu muammodagi eng keskin qarama-qarshilik bo’lib, VPN ingizdan eski konfiguratsiya faylidagi bitta so’zga borib taqaladi. Amalni [NOTFOUND=continue] ga o’zgartirish printerlar va mahalliy qurilmalar uchun mDNS ni saqlaydi, DNS esa nomni ko’ra oladi. Satrni hosts: files dns bilan almashtirish ham ishlaydi va qo’polroq: haqiqatan ishlatadigan printeringiz uchun .local hal qilinishini bekor qiladi.

Aynan bitta tarmoqda yashaydigan nomlar

Xususiy zonalar aynan bitta joyda vakolatli. ip-10-0-4-31.eu-west-1.compute.internal kabi AWS nomi o’sha regionning VPC resolver i orqali javob beriladi va faqat VPN oxirgi nuqtangiz resurs bilan bir regionda bo’lganda. Frankfurt oxirgi nuqtasiga ulanib, Irlandiyadagi compute.internal nomini so’rang va hech qanday mahalliy sozlama yordam bermaydi: yozuvni saqlaydigan zona u yerdan yetib bo’lmaydigan joyda.

Qidiruv domenlari oyna tasvirini beradi. Yalang’och service resolver mos deb hisoblagan suffiks bilan to’ldiriladi va VPN bog’lanishida mahalliy domen korporativ domenni yutishi mumkin. Taxminni olib tashlash uchun oxirida nuqta bilan so’rang, getent ahosts service.internal.example., va bu ishlab, qisqa nom ishlamasa, tuzatish — tunneldagi qidiruv domeni, server manzili emas.

Boshqariladigan mijozlar tizim resolver i ustiga uchinchi qatlam qo’shadi. Windows VPN profili o’z nom hal qilish siyosatini, dastur bo’yicha qoidalarni va tunnel o’chirilganda ham amal qiladigan NRPT jadvalini olib yurishi mumkin. O’z DNS keshiga ega dasturlar, .NET va Java muhitlarida keng tarqalgan, zanjir tuzatilgandan keyin ham eskirgan nosozlikni uzoq saqlaydi. Apple mijozlari split DNS ni DNS sozlamalaridagi moslik domenlari orqali sozlaydi, resolv.conf orqali emas, Chromium yoki Firefox xavfsiz DNS rejimida ommaviy nomlar uchun tizim resolver ini chetlab o’tishi mumkin. Microsoft ning VPN nom hal qilish ma’lumotnomasi bu siyosat qatlamining Windows tomonini tasvirlaydi.

Qaysi qatlamni tuzatishni hal qiling

Tuzatishlarni navbat bilan sinash o’rniga simptomdan qatlamga qarab ishlang:

Ikki satr asosiy yukni ko’taradi. Taym-aut — yetib borish muammosi: xususiy resolver tunnel orqali javob bermaydi, shuning uchun uning manziliga marshrutni va bog’lanishdagi DNS server siz o’ylagan server ekanini tekshiring. NXDOMAIN — vakolat muammosi: nimadir javob berdi va nomni bilmaydi, bu esa zonaga, regionga yoki so’rovni hech qachon olmasligi kerak bo’lgan resolver ga ishora qiladi.

Oxirgi satr — odamlar o’tkazib yuboradigan satr, chunki ikkala yarmi ham muvaffaqiyatga o’xshaydi. FQDN dan boshqacha hal bo’ladigan qisqa nom — suffiks nomuvofiqligi, va tunnelni qayta ulash mijoz yuboradigan suffiksni o’zgartirmaydi.

Konfiguratsiya faylini tahrirlashdan oldin holatni yozib oling, shunda tahrir nimadir o’zgartirganini ayta olasiz:

resolvectl status > before.txt
getent ahosts service.internal.example >> before.txt

Tekshiruvlarni shu tartibda bajaring va birinchi muvaffaqiyatsizda to’xtang. getent va resolvectl query mos kelishi kerak; agar getent muvaffaqiyatsiz bo’lib, dig javob bersa, qidiruv zanjirida qoling va marshrutlashga tegmang. resolvectl status tun interfeysida DNS server va marshrutlash domenini ko’rsatishi kerak. nsswitch tekshirilayotgan suffiks uchun NOTFOUND bilan erta qaytmasligi kerak. Nom oxirgi nuqtangiz ulangan tarmoqda vakolatli bo’lishi kerak, oxirida nuqta bilan tekshirilgan. Dastur o’z keshini yoki xavfsiz DNS bekor qilinishini saqlamasligi kerak.

Faqat birinchi muvaffaqiyatsiz qatlamni tuzating, keyin o’sha buyruqlarni qayta bajaring. Bir vaqtda ikkita o’zgarish qaysi biri muhim bo’lganini aytishga imkon bermaydi va keyingi nosozlik tekshiruvni noldan boshlaydi.