ip netns exec va DNS: nega nomlar nom maydoni ichida ishlamaydi

Buyruq VPN nom maydoni ichida 10.8.0.5 manziliga hech qanday shikoyatsiz yetib boradi, xuddi shu buyruq xost nomidan foydalangan lahzada muvaffaqiyatsiz bo’ladi. Nom maydonining o’z interfeyslari, marshrutlari va soketlari bor; o’zining hal qiluvchi fayli yo’q. Agar biror narsa u yerga bittasini qo’ymasa, ichkaridagi jarayon xostning /etc/resolv.conf faylini o’qiydi va o’sha tarmoq stekidan yetib bo’lmaydigan serverdan so’raydi.

Bu marshrutlash emas, fayl tanlash muammosi, va raqamli manzil hanuz ishlashining sababi aynan shu.

Jarayon haqiqatda oladigan hal qiluvchi ko’rinishini tekshiring

Ishlatgan qobig’ingiz siz tuzatayotgan jarayon bilan bir xil deb o’ylamang. Grafik ilova, systemd birligi va konteyner har biri boshqa o’rnatish yoki tarmoq kontekstiga kirishi mumkin. Qidiruvni xuddi shu ishga tushirish yo’li orqali bajaring va hal qiluvchi faylini ichkaridan chop eting.

ip netns add bilan yaratilgan nom maydoni uchun faqat o’qish tekshiruvi qisqa:

ip netns exec vpn cat /etc/resolv.conf

Natija yetib boriladigan manzilni, loopback stubni yoki boshqa yetib borish imkoniyatiga ega joyga ishora qiluvchi ramziy havolani nomlaydimi, e’tibor bering.

exec yordamchisi aslida nimani o’rnatadi

ip-netns asbobi har bir nom maydoni konfiguratsiyasini /etc/netns/NAME/ ostida hujjatlashtiradi. Jarayonni ishga tushirganda yordamchi o’rnatish nom maydonini yaratadi va o’sha fayllarni odatdagi yo’llari ustiga bind-mount qiladi, shuning uchun jarayon nom maydoniga xos nusxani ko’radi. Bu aynan shu ishga tushirgichning qulayligi. Tarmoq nom maydoniga boshqa yo’l bilan, masalan unshare yoki konteyner runtime orqali kirish buni avtomatik takrorlamaydi.

Bu yerda tuzoq loopback hal qiluvchisi: 127.0.0.53 nom maydonining o’z loopbackini bildiradi, xostning stubini emas. Faqat xost nom maydonida tinglaydigan stub yangisida xizmatga aylanmaydi.

Nom maydoni yetib bora oladigan hal qiluvchini tanlang

Fayl qaysi serverni nomlasa ham, unga hali ham o’sha nom maydonidan marshrut kerak. Ommaviy hal qiluvchi ommaviy nomlarga javob berib, ichki zona uchun baribir muvaffaqiyatsiz bo’lishi mumkin, chunki xususiy xizmatga faqat tunnel orqali yetib boriladi. Marshrutni manzil bilan bir vaqtda tekshiring, qidiruv allaqachon muvaffaqiyatsiz bo’lgandan keyin emas.

O’z hal qiluvchisiga ega ilovalar, masalan DNS over HTTPS ishlatadigan biri, faylni butunlay e’tiborsiz qoldirishi mumkin. Agar asbobning o’z DNS sozlamasi bo’lsa, resolv.conf ni o’zgartirish unga ta’sir qilmaydi, va nom maydoni hech qachon muammo bo’lmagan.

Faylni to’g’ri joyga yozing

/etc/netns/NAME/resolv.conf ostida nom maydoniga xos fayl yarating va ishga tushirgich uni taqdim etsin. Uni minimal saqlang: bitta yoki ikkita yetib boriladigan server va topshiriqqa kerakli qidiruv domenlari. Bitta jarayonlar guruhi uchun mo’ljallangan ko’rinishni tuzatish uchun xostning yaratilgan hal qiluvchi faylini tahrirlamang, chunki bu mashinadagi har bir ilovani o’zgartiradi. Agar xost hal qiluvchi menejeridan foydalansa, nom maydoni yo’lini u bilan kurashish o’rniga o’sha menejer orqali sozlang.

Fayl mazmunini runbook’ga yozib qo’ying. Aks holda keyingi odam xostning hal qiluvchisini sinab ko’radi, ishlaydigan javobni ko’radi va nom maydoni joyida degan xulosaga keladi.

Butun yo’lni qaytadan sinab ko’ring

Nom maydoni ichida raqamli manzil, ichki nom va ommaviy nom bilan sinab ko’ring. Bu ketma-ketlik yetib borishni hal qilishdan ajratadi va ichki zonalarni ommaviylardan ajratadi. Keyin nom maydonini qaytadan yarating va takrorlang, chunki faqat ishlab turgan nusxada mavjud fayl u bilan birga yo’qoladi.

Faylni qobiq emas, jarayon olayotganini tasdiqlang. Interaktiv qobiqdan ishlab, xizmatdan muvaffaqiyatsiz bo’ladigan qidiruv o’rnatish konteksti haqidagi topilma, va uni keyingi hodisadan oldin noldan qayta kashf qilish o’rniga yozib qo’yishga arziydi.