VPN konteyneri tarmog‘ini ulashish: DNS bilan nima bo‘ladi

VPN konteynerining tarmoq nom maydonini ulashish ilovangizga tunnel interfeyslari va marshrutlarini beradi. U unga tunnel resolverini bermaydi, hostdagi boshqa narsaning birlashtirilgan nusxasini ham bermaydi. Bu bo‘shliq juda aniq nosozlik keltiradi: ommaviy nomlar hal qilinadi, ichki nomlar hal qilinmaydi, va muvaffaqiyatsiz ilova noto‘g‘ri DNS serverdan foydalanayotgandek ko‘rinadi, chunki haqiqatan ham shunday. Tuzatish odatda diagnostika taklif qilganidan kichikroq bo‘ladi.

1-qadam: Hostdan emas, ilovadan sinab ko‘ring

Qidiruvni muammoli konteyner ichida ishga tushiring, hostda ham, brauzerda ham emas. docker exec app-container getent hosts db.internal muhim bo‘lgan yagona savolga javob beradi: bu jarayonning resolveri nima qaytaradi.

Agar host nomni hal qilsa, konteyner esa hal qilmasa, nosozlikni topdingiz. Bundan keyingi hamma narsa uni tuzatishning qo‘llab-quvvatlanadigan usulini tanlashdir.

2-qadam: Runtime qo‘llab-quvvatlaydigan modelni o‘qing

Docker tarmoq hujjatlari boshqa konteynerning tarmoq rejimini ulashadigan konteynerlar uchun DNS bayroqlaridagi cheklovlarni qayd etadi. Compose da network_mode: service:vpn ilovani VPN konteynerining nom maydoniga bog‘laydi, va har bir xizmat uchun dns sozlamalar oddiy xizmatdagidek ishlamaydi. Siz olgan yechim umumiy nom maydonida mavjud bo‘lgan yechimdir.

Foydalanuvchi belgilagan ko‘prik tarmoqlari ham Dockerning ichki DNS ini standart ko‘prikdan boshqacha ishlatadi. Shuning uchun ishlaydigan ko‘prik misolidan ko‘chirilgan dns band umumiy stekda hech narsa qilmasligi mumkin. Bandni ko‘chirishdan oldin tartibni tekshiring.

Loopback manzili har doim tegishli tarmoq kontekstiga ishora qiladi. Umumiy nom maydoni ichida 127.0.0.1 hostning resolveri emas.

3-qadam: So‘rovni uning qabul qiluvchisigacha kuzatib boring

Ilovaning resolver konfiguratsiyasini, so‘ng ilova bilan keladigan har qanday ilovaga xos shifrlangan DNS ni o‘qing, chunki o‘z resolverini ishga tushirgan ilova siz tahrirlagan faylni e’tiborsiz qoldiradi. So‘ng tanlangan resolver VPN marshrutlari va firewall siyosati ostida yetib borishini tekshiring. Tunnelning narigi tomonidagi resolver manzili, agar nom maydonining u yerga marshruti bo‘lmasa, foydasiz. Har qanday faylni tahrirlashdan oldin qabul qiluvchini tasdiqlang.

Brauzerdagi IP tekshirish sahifasi nom so‘rovlari qayerga ketganini aytolmaydi. U bitta HTTP ulanishi qayerga ketganini aytadi.

4-qadam: Ikki nosozlik sinfini alohida tuzating

Agar ommaviy nomlar ishlayotganda xizmat nomlari muvaffaqiyatsiz bo‘lsa, muammo konteyner tarmog‘i ichidagi xizmatlarni aniqlashda, ommaviy resolverlar ro‘yxatida emas. Har bir ommaviy DNS manzilini o‘zgartirish tarmoqning aniqlash mexanizmidan hech qachon so‘ralmagan yozuvlarni yaratmaydi.

Agar ikkala sinf ham muvaffaqiyatsiz bo‘lsa, resolverga yetib borishdan boshlang. Agar faqat bittasi muvaffaqiyatsiz bo‘lsa, aniqlash mexanizmidan boshlang. Ikkalasining egalari boshqa, shuning uchun bitta tuzatish hech qachon ikkalasini qamrab olmaydi.

5-qadam: Qayta yaratgandan keyin qayta sinab ko‘ring

Konfiguratsiyani runtime qo‘llab-quvvatlaydigan mexanizm orqali o‘zgartiring, so‘ng ishlab turgan konteyner ichidagi fayllarni tahrirlash o‘rniga konteynerlarni qayta yarating. Yangi shaxsiy nom, yangi ommaviy nom va qidiruvdan keyingi ilova so‘rovini sinab ko‘ring. /etc/resolv.conf konteyner ichidagi tahrir qayta yaratishda yo‘qoladi va tuzatish ishlamagan bo‘lsa ham ishladi deb sizni ishontiradi.

Resolver egasini va kutilgan nom maydonini umumiy tarmoq ta’rifi yoniga yozib qo‘ying. Keyingi odamga ikkalasi ham kerak bo‘ladi.