Azure P2S DNS не работает, когда resolver находится в связанном VNet

Клиент может достучаться до своей виртуальной сети и всё равно не разрешать имена в связанной сети. Peering — не транзит шлюза, пока обе стороны не согласятся.

Отправьте ping на VM, и она ответит; спросите её имя, и клиент скажет, что узел неизвестен. Когда resolver находится в связанной виртуальной сети, а не в той, где расположен шлюз VPN, эта пара результатов ожидаема, и никакая диагностика resolver этого не меняет. Не хватает договорённости о маршрутизации, которую peering по умолчанию удерживает. Две топологии выглядят на бумаге почти одинаково, а разница между работающей и сломанной — это пара переключателей peering, выставленных в нужную сторону.

Представьте ноутбук, который строит туннель к шлюзу в VNet2, а контроллер домена, обслуживающий DNS, сидит в VNet1.

Две топологии, одно различие

Поместите resolver в собственную виртуальную сеть шлюза, и имя разрешится в момент поднятия туннеля. Ни одна настройка peering не участвует в этом поиске.

Перенесите тот же resolver за peering, и клиент по-прежнему получает ответ от VM, а имя остаётся неизвестным. Сертификат, туннель и клиент не изменились. Сдвинулось только одно — где живёт resolver. Peering дал ему маршрут к этому адресу, а не полномочие шлюзу нести туда трафик.

Сторона A: разрешите транзит шлюза у владельца шлюза

Peering соединяет две виртуальные сети, но соединение не транзитивно для трафика, приходящего через шлюз, а запрос «точка-сеть» приходит именно так. Поэтому шлюз в VNet2 не имеет оснований передать поиск в VNet1, пока проект этого не разрешит. Разрешением служит переключатель на peering, принадлежащем сети со шлюзом.

Установите Allow gateway transit на peering из VNet2 в сторону VNet1. Свойство принадлежит объекту peering, а не ресурсу шлюза, поэтому его читают и меняют в колонке peering. Это и есть вся сторона A.

Сторона B: используйте удалённые шлюзы на партнёре

Другая половина — зеркальное отражение: на peering из VNet1 обратно к VNet2 включите Use remote gateways. Включение того же флага на обоих концах или только на одном оставляет недоделанный путь и исходный симптом нетронутым. Только сеть со шлюзом VPN разрешает транзит, а партнёр — это сторона, которая им пользуется.

Читайте оба свойства на обеих сетях, вместо того чтобы доверять колонке портала, открытой последней.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

Увидеть пару рядом — самый быстрый способ поймать перевёрнутую настройку. Peering, сообщающий AllowGatewayTransit false на стороне шлюза, объясняет весь отказ без перехвата пакетов.

Что клиент всё ещё должен получить

Маршрутизация необходима, но недостаточна, потому что профиль «точка-сеть» должен также выдать клиенту DNS-адрес, который отвечает, когда транзит работает. Resolver платформы — не этот адрес: он отвечает за зоны Azure Private DNS, привязанные к виртуальной сети, но ничего для зоны, размещённой на ваших собственных серверах каталога, а именно это использует данное развёртывание. Направьте клиента туда, и публичные имена будут бодро разрешаться, пока внутренний узел остаётся неизвестным.

Спросите resolver с подключённого ноутбука, прежде чем менять что-то ещё.

nslookup dc01.corp.example 10.1.0.4

Тайм-аут говорит, что пути всё ещё нет. Авторитетный ответ отталкивает проблему обратно к клиенту, обычно это суффикс, который никогда не добавляется, поэтому короткие имена уходят к публичному resolver, который бодро их проваливает.

Сравните тот же договор на стороне «сеть-сеть»

Ничто из этого не относится именно к ноутбукам. Замените клиента филиалом «сеть-сеть», и двустороннее требование возвращается: филиал приходит прямо в сеть шлюза, а сервис в двух сетях от неё всё ещё за peering.

Транзит должен быть разрешён на обоих peering, а переключатель, который его даёт, живёт на peering, а не на типе клиента.

Прежде чем винить шлюз

Windows хранит список resolver для каждого адаптера, поэтому подтвердите, что интерфейс туннеля действительно получил, прежде чем винить шлюз.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

Отрицательный ответ переживает исправление маршрутизации в кэше, а устаревший список суффиксов продолжает отправлять запросы туда, где зона никогда не размещалась. Очистите, спросите снова и отметьте, какой сервер отвечает.

Два меньших условия решают, удержится ли путь: адресные пространства не должны пересекаться, а группа безопасности сети в подсети resolver должна пропускать пул клиентов, который является всего лишь ещё одним диапазоном источников. Докажите это проверкой действующих маршрутов со стороны VM плюс один прямой запрос от клиента, чтобы проблему зоны, проблему суффикса или фильтр никогда не путали с отсутствующим транзитом.

Похожие статьи