VPN orqali Azure maxfiy DNS: resolver so‘nggi nuqtasi yoki forwarder
Ikkala dizayn ham tunnel orqali maxfiy zonalarga javob beradi. Boshqariladigan kiruvchi so‘nggi nuqtani forwarder VM bilan solishtiring, so‘ngra ikkala holatda ham bo‘lishi kerak bo‘lgan yo‘lni tekshiring.
Mahalliy tarmoqdagi server Azure VM ga maxfiy manzil orqali yetib boradi, lekin baribir uning maxfiy xost nomini hal qila olmaydi, bu esa odamlarni buzilgan tunnel qidirishga undaydi. Tunnel joyida. Yetishmayotgan narsa DNS chegarasi: mahalliy tomonda hech kim ma’lum bir Azure maxfiy zonasiga VNet ichidagi resolver javob berishi kerakligini bilmaydi. Bu bo‘shliqni ikki dizayn yopadi va ular oxir-oqibat nimani boshqarishingiz bilan farqlanadi, so‘rovlar ishlashi bilan emas.
Tunnel so‘rovlarni tashiydi, zona bilimini emas
Sayt-sayt ulanish paketlarga ikki tarmoq orasida yo‘l beradi. U mahalliy DNS serverga qaysi nom maydoni Azurega tegishli ekanini yoki qaysi manzil javob berishini aytmaydi, shuning uchun so‘rov yo internetga chiqib bo‘sh qaytadi, yo mahalliy resolverdan hech qachon chiqmaydi.
Tuzatishning oson ajratiladigan ikki yarmi bor. Bir yarmi tunneldan keladigan so‘rovlarni qabul qiladigan VNet ichidagi resolver. Ikkinchisi mahalliy tomondagi shartli forwarder bo‘lib, aynan bitta nom maydonini o‘sha resolverga yuboradi. Hech bir yarmi yolg‘iz ishlamaydi.
Ushbu tavsifning qolgan qismi uchun zona cloud.corp.example deb faraz qiling va har bir manzilni misol sifatida ko‘ring.
A varianti: boshqariladigan kiruvchi so‘nggi nuqta
Azure DNS Private Resolver VNet tashqarisidan keladigan DNS so‘rovlarini qabul qiladigan kiruvchi so‘nggi nuqta taqdim etadi. Siz uni alohida delegatsiya qilingan quyi tarmoqqa joylashtirasiz, maxfiy zonani o‘sha VNet ga bog‘laysiz va xizmat beradigan kiruvchi manzilni qayd etasiz.
So‘ngra mahalliy DNS serverda aniq nom maydoni uchun o‘sha manzilga qaratilgan shartli forwarder yaratasiz:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoftning gibrid DNS tartibi zona bog‘lanishini ham, forwarder qadamini ham hujjatlashtiradi. Boshqariladigan yo‘l yamoqlash uchun DNS dasturiy ta’minotini qoldirmaydi va so‘nggi nuqta manzili resursning butun umri davomida barqaror qoladi.
Narxi shundaki, endi sizda resolver resursi, uning quyi tarmoq delegatsiyasi va xarajati bor, bu so‘rov hajmi juda kichik bo‘lsa ham realdir.
B varianti: VNet ichidagi forwarder VM
Eski dizayn VNet dagi oddiy VM da DNS dasturiy ta’minotini ishga tushiradi: Windows DNS, BIND yoki dnsmasq, maxfiy zona yo mahalliy joylashtiriladi, yo 168.63.129.16 manzilidagi Azure resolveriga yuboriladi. Mahalliy shartli forwarder o‘sha VM ning maxfiy manziliga ishora qiladi.
Bu variant allaqachon DNS serverlarini boshqaradigan jamoalarga tanish va jurnal yozish yoki split-horizon javoblari kabi qo‘shimcha mantiqni ko‘tara oladi. Shuningdek, DNS serverning barcha operatsion majburiyatlarini meros oladi: yamoqlash, mavjudlik uchun ikkinchi nusxa, monitoring va VM almashtirilib manzili o‘zgarganda qayta qurish yo‘li.
Oddiy VNet xosti xizmat o‘rnatilmaguncha va o‘sha mijozlarga javob berishga ruxsat berilmaguncha DNS proksisi emas, va VM ni klonlashda odamlar aynan shu qadamni tashlab ketadi.
Qaysi biri ishingizga mos keladi
Taqqoslash qaysi dizayn tezroq ekani haqida emas. Bu DNS dasturiy ta’minotini umuman boshqarishni xohlaysizmi va so‘rov hajmi so‘nggi nuqta va so‘rov bo‘yicha hisob-kitob qiladigan boshqariladigan resursni oqlaydimi degan savol haqida.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Qaysi qator hal qilsa ham, mahalliy forwarder qoidasi bir xil ko‘rinadi. Aynan shu qism ikkala dizaynda ham bo‘lishi kerak va odam Azure ichidan hal qilish ishlaydi, lekin ofisdan ishlamaydi deb xabar berganida eng ko‘p yetishmaydigan qism ham shu.
Yo‘lni tartib bilan tekshiring
Zona resolver joylashgan VNet ga bog‘langanini va mahalliy forwarder ota-domenni emas, nom maydonini nomlashini tasdiqlang. corp.example uchun forwarder, resolver o‘zi delegatsiya qilmasa, cloud.corp.example bilan mos kelmaydi va bu nomuvofiqlik yo‘qolgan yozuvga o‘xshaydigan toza salbiy javob beradi.
So‘ngra so‘rov so‘nggi nuqtaga yetib borishini tekshiring: mahalliy manbaga resolver manziliga yo‘l va qaytish yo‘li kerak, siyosat ruxsat bergan joyda 53 port UDP va TCP uchun ochiq bo‘lishi kerak. NSG yo‘qolgan zona yozuvini bera olmaydi, to‘g‘ri zona esa hech qachon kelmaydigan so‘rovga javob bera olmaydi.
Diagnostika qilayotganda so‘ralgan FQDN ni tanlangan resolver yonida saqlang va vaqt tugashini salbiy javobdan ajrating. Vaqt tugashi yo‘l yoki siyosat muammosi. Salbiy javob so‘rov yetib kelganini va nom maydoni mos kelmaganini bildiradi. Ish tartibi: zonani bog‘lang, shartli forwarder qo‘shing, 53 portni ikki tomonga oching, mahalliy tomondan bitta nomni sinab ko‘ring va shundan keyingina ilovaning o‘z avtorizatsiyasiga qarang.