Частен DNS на Azure през VPN: резолверна крайна точка или форуърдър
И двата дизайна отговарят на частни зони през тунела. Сравнете управлявана входяща крайна точка с форуърдър виртуална машина, после проверете пътя, който трябва да съществува и в двата случая.
Сървър в локалната мрежа достига до виртуална машина в Azure по частен адрес и въпреки това не може да резолвне частното ѝ име, което кара хората да търсят счупен тунел. Тунелът е наред. Липсва граница на DNS: нищо от локалната страна не знае, че на определена частна зона в Azure трябва да отговаря резолвер вътре във VNet. Два дизайна запълват тази празнина и те се различават по това какво в крайна сметка експлоатирате, а не по това дали заявките работят.
Тунелът пренася заявки, а не знание за зоните
Връзка сайт-към-сайт дава на пакетите маршрут между двете мрежи. Тя не казва на локалния DNS сървър кое пространство от имена принадлежи на Azure и кой адрес трябва да отговаря, затова заявката или отива в интернет и се връща празна, или никога не напуска локалния резолвер.
Поправката има две половини, които лесно се разделят. Едната половина е резолвер във VNet, който приема заявки, идващи през тунела. Другата е условен форуърдър от локалната страна, който изпраща точно едно пространство от имена към този резолвер. Нито една половина не работи сама.
Приемете, че зоната е cloud.corp.example за остатъка от това описание, и третирайте всеки адрес като илюстративен.
Вариант A: управляваната входяща крайна точка
Azure DNS Private Resolver предоставя входяща крайна точка, която приема DNS заявки отвън VNet. Разполагате я в отделна делегирана подмрежа, свързвате частната зона с тази VNet и записвате входящия адрес, който услугата задава.
След това на локалния DNS сървър създавате условен форуърдър за точното пространство от имена към този адрес:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Процедурата за хибриден DNS на Microsoft документира както свързването на зоната, така и стъпката с форуърдъра. Управляваният път ви оставя без DNS софтуер за пачване, а адресът на крайната точка остава стабилен за целия живот на ресурса.
Цената е, че сега притежавате резолверен ресурс, делегирането на подмрежата му и разхода за него, който е реален дори когато обемът на заявките е малък.
Вариант B: форуърдър виртуална машина във VNet
По-старият дизайн пуска DNS софтуер на обикновена виртуална машина във VNet: Windows DNS, BIND или dnsmasq, като частната зона е или хоствана локално, или препратена към резолвера на Azure на 168.63.129.16. Локалният условен форуърдър сочи към частния адрес на тази машина.
Този вариант е познат на екипи, които вече поддържат DNS сървъри, и може да носи допълнителна логика като журналиране или отговори split-horizon. Той също наследява всички оперативни задължения на DNS сървър: пачване, втори екземпляр за наличност, мониторинг и път за преизграждане, когато машината се смени и адресът ѝ се промени.
Обикновен хост във VNet не е DNS прокси, докато услугата не е инсталирана и не получи разрешение да отговаря на тези клиенти — точно тази стъпка се пропуска при клониране на виртуална машина.
Кой вариант пасва на вашата експлоатация
Сравнението не е за това кой дизайн е по-бърз. А за това дали изобщо искате да експлоатирате 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 |
Който и ред да реши, правилото за форуърдъра от локалната страна изглежда същото. Именно тази част трябва да съществува и в двата дизайна и именно тя най-често липсва, когато някой съобщи, че резолвването работи отвътре в Azure, но не от офиса.
Проверете пътя по ред
Уверете се, че зоната е свързана с VNet, която държи резолвера, и че локалният форуърдър посочва пространството от имена, а не родителски домейн. Форуърдър за corp.example няма да съвпадне с cloud.corp.example, освен ако самият резолвер не делегира, а несъответствието дава чист отрицателен отговор, който изглежда като липсващ запис.
След това проверете дали заявката достига до крайната точка: локалният източник се нуждае от маршрут до адреса на резолвера и обратен път, а порт 53 за UDP и TCP трябва да е разрешен там, където политиката позволява. NSG не може да осигури липсващ запис в зоната, а правилната зона не може да отговори на заявка, която никога не пристига.
Дръжте заявеното FQDN до избрания резолвер, когато диагностицирате, и отделяйте таймаута от отрицателния отговор. Таймаутът е проблем с пътя или политиката. Отрицателният отговор означава, че заявката е пристигнала и пространството от имена не е съвпаднало. Ред на работа: свържете зоната, добавете условния форуърдър, отворете порт 53 в двете посоки, тествайте едно име от локалната страна и едва след това гледайте собствената авторизация на приложението.