Частный DNS Azure через VPN: конечная точка resolver или forwarder
Оба варианта отвечают на частные зоны через туннель. Сравните управляемую входящую конечную точку с VM с forwarder, а затем проверьте путь, который должен существовать в любом случае.
Сервер в локальной сети достигает виртуальной машины Azure по частному адресу и всё равно не может разрешить её частное имя хоста, из-за чего люди ищут сломанный туннель. Туннель в порядке. Не хватает границы DNS: ничто на локальной стороне не знает, что на определённую частную зону Azure должен отвечать resolver внутри VNet. Два варианта закрывают этот пробел, и они различаются тем, чем вы в итоге управляете, а не тем, работают ли запросы.
Туннель переносит запросы, а не знание зон
Соединение «сайт — сайт» даёт пакетам маршрут между двумя сетями. Оно не сообщает локальному DNS-серверу, какое пространство имён принадлежит Azure и какой адрес должен отвечать, поэтому запрос либо уходит в интернет и возвращается пустым, либо никогда не покидает локальный resolver.
Исправление состоит из двух легко разделяемых половин. Одна половина — resolver внутри VNet, который принимает запросы, приходящие через туннель. Другая — условный forwarder на локальной стороне, который отправляет ровно одно пространство имён этому resolver. Ни одна половина не работает сама по себе.
Для остальной части описания будем считать, что зона — cloud.corp.example, а все адреса приведены для примера.
Вариант A: управляемая входящая конечная точка
Azure DNS Private Resolver предоставляет входящую конечную точку, которая принимает DNS-запросы извне VNet. Вы развёртываете её в отдельной делегированной подсети, связываете частную зону с этой VNet и записываете входящий адрес, который назначает служба.
Затем на локальном DNS-сервере вы создаёте условный forwarder для точного пространства имён на этот адрес:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Процедура гибридного DNS от Microsoft описывает и привязку зоны, и шаг с forwarder. Управляемый путь не оставляет программного обеспечения DNS, которое нужно патчить, а адрес конечной точки остаётся стабильным на весь срок жизни ресурса.
Плата за это — ресурс resolver, его делегирование подсети и его стоимость, которые реальны даже при крошечном объёме запросов.
Вариант B: VM с forwarder внутри VNet
Более старый вариант запускает DNS-программное обеспечение на обычной виртуальной машине в VNet: Windows DNS, BIND или dnsmasq, причём частная зона либо размещается локально, либо пересылается в resolver Azure по адресу 168.63.129.16. Локальный условный forwarder указывает на частный адрес этой машины.
Этот вариант знаком командам, которые уже эксплуатируют 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 |
Какая бы строка ни решила, правило forwarder на локальной стороне выглядит одинаково. Именно эта часть должна существовать в обоих вариантах, и именно её чаще всего не хватает, когда кто-то сообщает, что разрешение имён работает изнутри Azure, но не из офиса.
Проверьте путь по порядку
Убедитесь, что зона связана с VNet, в которой находится resolver, и что локальный forwarder называет пространство имён, а не родительский домен. Forwarder для corp.example не совпадёт с cloud.corp.example, если сам resolver не делегирует, и это несовпадение даёт чистый отрицательный ответ, похожий на отсутствующую запись.
Затем проверьте, доходит ли запрос до конечной точки: локальному источнику нужен маршрут к адресу resolver и обратный путь, а порт 53 должен быть разрешён и для UDP, и для TCP там, где это позволяет политика. NSG не может предоставить отсутствующую запись зоны, а правильная зона не может ответить на запрос, который никогда не приходит.
При диагностике держите запрошенное FQDN рядом с выбранным resolver и отделяйте тайм-аут от отрицательного ответа. Тайм-аут — это проблема маршрута или политики. Отрицательный ответ означает, что запрос пришёл, а пространство имён не совпало. Порядок работы: свяжите зону, добавьте условный forwarder, откройте порт 53 в обе стороны, проверьте одно имя из локальной сети и только потом смотрите на собственную авторизацию приложения.