Nima uchun Docker konteynerlari VPN ning DNS hal qiluvchisini e'tiborsiz qoldiradi

VPN ishlayapti, brauzer ichki saytlarga yetib boradi, lekin konteyner hali ham o'sha nomlarni hal qila olmaydi. Paket o'rnatish EAI_AGAIN kabi nom hal qilish xatosi bilan o'ladi, yoki ilova xost mashinasi hech qanday shikoyatsiz hal qiladigan ma'lumotlar bazasi xostini topa olmaydi. Konteyner VPN o'rnatgan hal qiluvchidan foydalanmayapti. Docker konteyner yaratilganda xostning hal qiluvchi konfiguratsiyasini nusxalagan, va bundan keyin hech narsa uni qayta nusxalamagan.

Bitta mashinada hal qiluvchining ikki ko'rinishi

Linux da Docker yaratish paytida har bir konteynerga xostning hal qiluvchi konfiguratsiyasi ning nusxasini beradi, loopback manzillarni filtrlaydi va 127.0.0.11 da tashqariga so'rovlarni uzatadigan ichki DNS serverni ishga tushiradi. Konteyner ishga tushgandan keyin /etc/resolv.conf ni qayta yozadigan VPN mijozi uning ichida hech narsani o'zgartirmaydi. Konteynerni qayta ishga tushirish faqat o'sha paytda xost hal qiluvchisi tasodifan to'g'ri bo'lsa yordam beradi.

macOS yoki Windows dagi Docker Desktop bir qatlam qo'shadi, chunki daemon virtual mashinada yashaydi. Xostning VPN hal qiluvchisi o'sha VM ga hech qachon ko'rinmasligi mumkin, shuning uchun qayta ishga tushirish hech narsani o'zgartirmaydi. Yechim tanlashdan oldin ikki ko'rinishni solishtiring: xostning hal qiluvchilar ro'yxati yonida docker exec mycontainer cat /etc/resolv.conf.

Xost ichki hal qiluvchini sanab turganda konteyner ommaviy hal qiluvchini sanasa, u ommaviy nomlarni hal qiladi va ichkilarida muvaffaqiyatsiz bo'ladi. Bu bo'linish bu muammoning imzosi.

A variant: tunnel hal qiluvchisini har bir konteynerga uzatish

Docker har bir konteyner uchun DNS sozlamalarini qabul qiladi, va bu ishlaydigan eng kichik o'zgarish. Avval VPN ning hal qiluvchi manzillarini o'qing: macOS da scutil --dns, Linux da resolvectl status yoki mijozning o'z holat chiqishi. Keyin konteynerni ular bilan ishga tushiring, masalan docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Compose da o'sha sozlama xizmat ostidagi ro'yxat bo'lib, u yerda kimningdir shell tarixi o'rniga versiya nazoratida yashaydi.

/etc/docker/daemon.json dagi dns massivi har bir yangi konteynerga qo'llaniladi, bu tartibliroq tuyuladi va unday emas. Tunnel o'chirilganda ham qo'llaniladi, va o'shanda faqat VPN orqali yetib boriladigan hal qiluvchi odatdagi obraz tortishni buzadi. Har bir konteyner uchun sozlamalarni asoslash ham, bekor qilish ham osonroq.

B variant: konteyner xost tarmog'ini baham ko'rsin

Xost tarmog'i nusxani butunlay chetlab o'tadi, chunki konteyner xostning hal qiluvchisi va xostning tunnelidan foydalanadi. U siz xohlagan tarmoq izolyatsiyasini ham olib tashlaydi, va Docker Desktop ostida bir xil ishlamaydi. Linux da ichki nomlarni hal qilishi kerak bo'lgan bir martalik vosita uchun bu pragmatik tanlov.

Build lar uchun ikkala variant ham qo'llanilmaydi, chunki build bosqichlari ish vaqti bayroqlarini meros olmaydi. Platforma ruxsat bergan joyda xost tarmog'i bilan build qiling, yoki bog'liqliklar o'rnatishni tunnel kerak bo'lmagan bosqichda saqlang.

Ikkala variant ham tuzatmaydigan narsa

Agar konteynerning u yerga yo'li bo'lmasa, DNS manzili foydasiz. VPN hal qiluvchisi odatda tunnelning manzil fazosida o'tiradi, shuning uchun konteynerga o'sha prefiksga yo'l kerak. Docker ning standart ko'prigi odatda xost orqali tashqariga yo'naltiradi, va xostda tunnel yo'li bo'lib, yo'naltirish yoqilgan bo'lsa bu yetarli. O'z manzil hovuzlariga ega maxsus ko'prik tarmoqlari VPN subnetwork bilan to'qnashishi mumkin, va o'shanda so'rovlar butunlay boshqa joyga ketadi.

Hal qiluvchining o'zini tuzatishdan oldin Docker tarmog'ining subnetworkini VPN subnetworki bilan solishtiring. Ustma-ust tushish buzilgan DNS serverga aynan o'xshaydigan nosozlik keltiradi.

Konteyner ichida tekshiring

Brauzer yoki til ish vaqti o'rniga konteyner ichida getent hosts db.internal bilan sinab ko'ring, chunki ular o'z DNS siyosati va o'z keshini qo'llaydi. Agar getent nomni hal qilsa va ilova hali ham muvaffaqiyatsiz bo'lsa, hal qiluvchi endi to'g'ri va qolgan muammo ilova darajasida. Agar u hal qilmasa, DNS bosqichi tugamagan.

DNS sozlamalarini o'zgartirgandan keyin konteynerni qayta yarating. Ishlab turgan konteyner ichida /etc/resolv.conf ni tahrirlash u bilan birga yo'qoladi va konfiguratsiya muammosini kimdir uni qayta ishga tushirishiga qadar yashiradi.