Nega resolv.conf VPN DNS'ini ko'rsatadi, qidiruvlar esa uni e'tiborsiz qoldiradi

Jurnallarda hech narsa xato ko'rinmaydi: interfeys ishlayapti, hal qiluvchi VPN'ning DNS serverini xabar qiladi va diskdagi fayl uni sanab o'tadi. Shunga qaramay ichki xost nomi hanuz mahalliy router orqali hal qilinadi. Bu uch bayonot bir-biriga zid emas, chunki fayl, har bir ulanish holati va qidiruv yo'li tasodifan bir xil nomni bo'lishadigan turli obyektlardir. Quyida systemd-resolved ishlaydigan xostda so'rov aslida bosib o'tadigan yo'l tasvirlangan.

resolv.conf deb ataladigan uch obyekt

resolved ishlaydigan xostda /etc/resolv.conf odatda /run/systemd/resolve/stub-resolv.conf ga ramziy havola bo'ladi. Bu nishonda mahalliy stub tinglovchining manzili, 127.0.0.53, va resolved hisoblagan qidiruv domenlari bor. Bu holatning ko'rinishi, holatning o'zi emas.

Holat resolved'ning har bir ulanish bo'yicha konfiguratsiyasida yashaydi, shuning uchun resolvectl status faylga zid bo'lib ham haq bo'lishi mumkin. Har bir ulanish o'z serverlarini va o'z marshrutlash domenlarini olib yuradi, stub esa so'rov kelganda o'sha ma'lumotlarga murojaat qiladi. systemd-resolved qo'llanmasi yaratilgan fayllar va har bir ulanish modelini tavsiflaydi; ko'rinish bilan holatni ajratish eslab qolishga arziydigan qismdir. Ramziy havola nishonini o'zgartirish an'anaviy mijozlar o'qiydigan narsani o'zgartiradi, hal qiluvchi biladigan narsani emas.

Uchinchi obyekt, /run/systemd/resolve/resolv.conf, har bir ulanishni bitta server ro'yxatiga tekislaydi. O'sha faylga yo'naltirilgan dastur so'rovlarni to'g'ridan-to'g'ri sanab o'tilgan serverlarga yuboradi va stub'ni chetlab o'tadi, shuning uchun har bir ulanish siyosati unga endi taalluqli emas. Shu sababli bir mashinadagi ikki dastur bir xil nomga turlicha javob berishi mumkin va hech biri buzilmagan.

NSS orqali bitta qidiruvni kuzatib boring

glibc nomga kim javob berishini aniqlash uchun /etc/nsswitch.conf faylini o'qiydi. Tarkibida resolve bo'lgan hosts satri savolni nss-resolve ga yo'naltiradi, u D-Bus orqali resolved'dan so'raydi va har bir ulanish javobini oladi. Faqat files dns bo'lgan satr so'rovni /etc/resolv.conf tutgan manzilga yuboradi.

Aynan shu bitta satr brauzer bilan dig o'rtasidagi kelishmovchiliklarning ko'pini tushuntiradi. dig resolv.conf ni to'g'ridan-to'g'ri o'qiydi va NSS ga hech qachon tegmaydi, shuning uchun dastur ishlatadigan yo'lni emas, stub yoki yuqori serverni sinaydi. getent hosts internal.example NSS orqali o'tadi va uning javobini dig javobi bilan solishtirish birinchi foydali o'lchovdir.

O'z hal qiluvchisini olib yuradigan yoki qat'iy yakuniy nuqtaga HTTPS orqali DNS gapiradigan dasturlar ikkala yo'lni ham chetlab o'tadi. resolv.conf da ham, resolved holatida ham ularni cheklaydigan narsa yo'q.

Fayl kimga tegishli va qayerga ishora qilishini tekshiring

Biror narsani o'zgartirishdan oldin havolalar zanjirini o'qing, chunki qaysi fayl vakolatli ekanini egalik hal qiladi. Quyidagi har bir buyruq faqat holatni o'qiydi.

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

Birinchi satr havola va uning nishonini birga chop etadi, VPN skriptiga tegishli oddiy fayl esa hal qiluvchi bu yozuvni hech qachon kiritish sifatida qabul qilmasligini bildiradi. Holat chiqishi har bir ulanish serverlarini va har bir so'rov qayerga ketishini belgilaydigan marshrutlash domenlarini sanab o'tadi. nsswitch satri stub'ga umuman murojaat qilinadimi-yo'qmi aytadi, shuning uchun faylda stub manzili bo'lib, u yerda resolve bo'lmasa, so'rovlar mahalliy tinglovchiga yetadi, ammo bo'linishni hech narsa boshqarmaydi. Oxirgi ro'yxat ham muhim, chunki stub-resolv.conf bo'lmagan xost bu yerda tasvirlangan tuzilmani ishlatmaydi.

Agar zanjir boshqa paket boshqaradigan faylda tugasa, VPN mijozi va o'sha paket kelishtirilishi kerak bo'lgan ikki egadir. Havolani almashtirish bir egasining ishini tashlab, ikkinchisinikini joyida qoldiradi.

Havola egasida tuzating

VPN ulanishi o'z serverlari va domenlarini o'z ulanishida ro'yxatdan o'tkazishi, so'ng uzilganda ularni qaytarib olishi kerak. NetworkManager'ning resolved integratsiyasi va mijozning o'z yordamchisi ikkalasi ham shunday ishlaydi; faqat resolv.conf ni qayta yozadigan skript unday emas.

Allaqachon mavjud ulanishda mexanizmni ish vaqtidagi sozlamalar ko'rsatadi. resolvectl dns tun0 10.40.0.53 server biriktiradi, resolvectl domain tun0 '~corp.example' marshrutlash domenini biriktiradi. Tilda — yuk ko'taruvchi belgi: u o'sha qo'shimchaning so'rovlarini shu ulanish bilan cheklaydi va qolgan hamma narsani tinch qo'yadi, usiz esa xuddi shu qiymat qidiruv domeniga aylanadi va bo'linish bug'lanib ketadi. O'sha manzillar laboratoriya misollari, doimiy konfiguratsiya emas. resolvectl query host.corp.example bilan tasdiqlang va qaysi ulanish javob berganini o'qing.

Ro'yxatdan o'tgan serverga baribir marshrut kerak. So'rov to'g'ri ulanishga yetib, vaqt tugasa, xato hal qiluvchi egaligida emas, tunnel orqali yetib borishdadir.

Ishlaydigan holat qanday ko'rinadi

Sog'lom natija uch ko'rinishda ham izchil: har bir ulanish serverlari VPN berganiga mos keladi, marshrutlash domenlari faqat ichki qo'shimchalarni qamrab oladi va muhim dastur ichki nomni hal qiladi, ommaviy nom esa hanuz mahalliy yo'lni davom ettiradi. Bitta muvaffaqiyatli so'rov bu kelishuvdan kamroq narsani isbotlaydi.

So'ng uzib, ikkala so'rovni takrorlang. Uzilishdan keyin ham domenlarini ro'yxatda qoldirgan mijoz bir necha soatdan keyin ichki qidiruvlarda muvaffaqiyatsizlikka uchraydigan mashina yaratadi, ochiq tunnelsiz va aniq sababsiz.