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 плюс один прямий запит від клієнта, щоб проблему зони, проблему суфікса або фільтр ніколи не плутали з відсутнім транзитом.

Схожі статті