VPN-ээр Azure-ийн хувийн DNS: resolver-ийн төгсгөлийн цэг эсвэл forwarder
Хоёр загвар туннелээр дамжуулан хувийн бүсүүдэд хариу өгдөг. Удирдлагатай орж ирэх төгсгөлийн цэгийг forwarder VM-тэй харьцуулж, дараа нь хоёр тохиолдолд байх ёстой замыг шалгана уу.
Локал сүлжээний сервер Azure VM-д хувийн хаягаар хүрдэг ч түүний хувийн хост нэрийг шийдэж чадахгүй, энэ нь хүмүүсийг эвдэрсэн туннель хайхад хүргэдэг. Туннель хэвийн. Дутагдаж байгаа нь DNS хил: локал талд тодорхой нэг Azure хувийн бүсэд VNet доторх resolver хариу өгөх ёстойг хэн ч мэдэхгүй. Энэ цоорхойг хоёр загвар нөхөж, тэд эцэст нь юу ажиллуулж байгаагаараа ялгаатай, асуултууд ажиллаж байгаа эсэхээр биш.
Туннель асуултуудыг зөөдөг, бүсийн мэдлэгийг биш
Site-to-site холболт пакетуудад хоёр сүлжээний хооронд маршрут өгдөг. Энэ нь локал DNS серверт аль нэрийн орон зай Azure-д хамаарах, аль хаяг хариу өгөхийг хэлэхгүй, тиймээс асуулт нэг бол интернет рүү явж хоосон буцаж ирнэ, эсвэл локал resolver-ээс хэзээ ч гарахгүй.
Засварыг хялбар салгах хоёр хагастай. Нэг хагас нь туннелээр ирж буй асуултыг хүлээн авдаг VNet доторх resolver. Нөгөө нь локал талд байх нөхцөлт forwarder бөгөөд яг нэг нэрийн орон зайг тэр resolver руу илгээдэг. Аль нэг хагас нь ганцаараа ажиллахгүй.
Энэ тайлбарын үлдсэн хэсэгт бүс нь cloud.corp.example гэж үзээд хаяг бүрийг жишээ гэж үзээрэй.
А хувилбар: удирдлагатай орж ирэх төгсгөлийн цэг
Azure DNS Private Resolver нь VNet-ээс гаднаас ирэх DNS асуултыг хүлээн авдаг орж ирэх төгсгөлийн цэгийг санал болгодог. Та үүнийг тусгай делегацлагдсан дэд сүлжээнд байрлуулж, хувийн бүсийг тухайн VNet-тэй холбож, үйлчилгээний олгосон орж ирэх хаягийг тэмдэглэнэ.
Дараа нь локал DNS сервер дээр яг нэрийн орон зайд зориулсан нөхцөлт forwarder-ийг тухайн хаяг руу үүсгэнэ:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft-ийн гибрид DNS журам бүсийг холбох болон forwarder алхмыг хоёуланг нь баримтжуулдаг. Удирдлагатай зам танд засахаар DNS програм хангамж үлдээхгүй, төгсгөлийн цэгийн хаяг нөөцийн бүх насны туршид тогтвортой байна.
Үнэ нь одоо танд resolver нөөц, түүний дэд сүлжээний делегац, зардал бий болсон, асуултын хэмжээ маш бага байсан ч энэ бодит юм.
Б хувилбар: VNet доторх forwarder VM
Хуучин загвар VNet дэх энгийн VM дээр DNS програм хангамж ажиллуулдаг: Windows DNS, BIND эсвэл dnsmasq, хувийн бүс нь локалд байршина эсвэл 168.63.129.16 дахь Azure resolver руу дамжина. Локал нөхцөлт forwarder тэр VM-ийн хувийн хаяг руу заана.
Энэ хувилбар нь DNS сервер аль хэдийн ажиллуулдаг багуудад танил бөгөөд лог бичих эсвэл split-horizon хариу зэрэг нэмэлт логик авч болно. Мөн DNS серверийн бүх үйл ажиллагааны үүргийг өвлөнө: засвар, хүртээмжид зориулсан хоёр дахь хувилбар, хяналт, VM солигдож хаяг нь өөрчлөгдөх үеийн дахин бүтээх зам.
Энгийн VNet хост нь үйлчилгээ суулгаж, тэдгээр клиентэд хариу өгөх зөвшөөрөл авах хүртэл DNS прокси биш бөгөөд VM хувилах үед хүмүүсийн алгасдаг алхам нь энэ.
Аль нь таны үйл ажиллагаанд тохирох вэ
Харьцуулалт аль загвар хурдан бэ гэсэн юм биш. DNS програм хангамжийг ерөөсөө ажиллуулахыг хүсэж байгаа эсэх, асуултын хэмжээ төгсгөлийн цэг болон асуултаар төлбөр авдаг удирдлагатай нөөцийг зөвтгөж байгаа эсэх тухай юм.
| 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 |
Аль мөр шийдсэн ч локал forwarder-ийн дүрэм ижил харагдана. Энэ хэсэг хоёр загварт заавал байх ёстой бөгөөд Azure дотроос шийдэл ажиллаж байгаа ч оффисоос ажиллахгүй гэж хэн нэгэн мэдээлэх үед хамгийн их дутагддаг хэсэг нь энэ.
Замыг дарааллаар нь шалгана уу
Бүс нь resolver агуулсан VNet-тэй холбогдсон эсэх, локал forwarder эцэг домэйн биш нэрийн орон зайг нэрлэж байгаа эсэхийг баталгаажуулна. corp.example-ийн forwarder нь resolver өөрөө делегац хийхгүй бол cloud.corp.example-тэй таарахгүй бөгөөд энэ зөрүү нь алга болсон бичлэг мэт харагдах цэвэр сөрөг хариу үүсгэдэг.
Дараа нь асуулт төгсгөлийн цэгт хүрч байгаа эсэхийг шалгана: локал эх сурвалжид resolver-ийн хаяг руу маршрут болон буцах зам хэрэгтэй, бодлого зөвшөөрсөн газарт 53 порт UDP болон TCP-ээр нээлттэй байх ёстой. NSG алга болсон бүсийн бичлэг өгч чадахгүй, зөв бүс хэзээ ч ирэхгүй асуултад хариу өгч чадахгүй.
Оношилгоо хийхдээ хүссэн FQDN-ийг сонгосон resolver-ийн хажууд байлгаж, тайм-аутыг сөрөг хариунаас ялгана уу. Тайм-аут нь зам эсвэл бодлогын асуудал. Сөрөг хариу гэдэг нь асуулт ирсэн боловч нэрийн орон зай таараагүй гэсэн үг. Ажлын дараалал: бүсийг холбох, нөхцөлт forwarder нэмэх, 53 портыг хоёр чиглэлд нээх, локалаас нэг нэрийг турших, зөвхөн дараа нь аппын өөрийн зөвшөөрлийг харах.