Приватний 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-програмне забезпечення на звичайній VM у VNet: Windows DNS, BIND або dnsmasq, причому приватна зона або розміщується локально, або пересилається до resolver Azure за адресою 168.63.129.16. Локальний умовний forwarder указує на приватну адресу цієї VM.
Цей варіант знайомий командам, які вже експлуатують 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 в обидва боки, перевірте одне ім'я з локальної мережі й лише потім дивіться на власну авторизацію застосунку.