Прыватны DNS Azure праз VPN: канцавая точка resolver ці forwarder
Абедзве схемы адказваюць на прыватныя зоны праз тунель. Параўнайце кіраваную ўваходную канцавую точку з forwarder на VM, а затым праверце шлях, які павінен існаваць у любым выпадку.
Сервер у лакальнай сетцы дасягае віртуальнай машыны 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: forwarder на VM унутры VNet
Старэйшая схема запускае праграмнае забеспячэнне DNS на звычайнай VM у VNet: Windows DNS, BIND або dnsmasq, прычым прыватная зона альбо размяшчаецца лакальна, альбо перасылаецца ў resolver Azure па адрасе 168.63.129.16. Лакальны ўмоўны forwarder паказвае на прыватны адрас гэтай VM.
Гэты варыянт знаёмы камандам, якія ўжо трымаюць серверы DNS, і ён можа несці дадатковую логіку, напрыклад журналіраванне або адказы split-horizon. Ён таксама ўспадкоўвае ўсе эксплуатацыйныя абавязкі сервера DNS: латанне, другі асобнік для даступнасці, маніторынг і шлях перабудовы, калі VM замяняюць і яе адрас змяняецца.
Звычайны хост VNet не з’яўляецца проксі DNS, пакуль служба не ўсталяваная і не мае дазволу адказваць гэтым кліентам; менавіта гэты крок прапускаюць, калі клануюць VM.
Які варыянт падыходзіць вашай эксплуатацыі
Параўнанне не пра тое, якая схема хутчэйшая. Яно пра тое, ці хочаце вы наогул эксплуатаваць праграмнае забеспячэнне 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 у абодва бакі, праверце адно імя з лакальнага боку і толькі потым глядзіце на ўласную аўтарызацыю праграмы.