Privátní DNS Azure přes VPN: koncový bod resolveru, nebo forwarder
Oba návrhy odpovídají na privátní zóny přes tunel. Porovnejte spravovaný příchozí koncový bod s forwarderem na virtuálním počítači a pak zkontrolujte cestu, která musí existovat v obou případech.
Server v místní síti dosáhne virtuálního počítače Azure přes privátní adresu a přesto nedokáže přeložit jeho privátní název hostitele, což lidi pošle hledat rozbitý tunel. Tunel je v pořádku. Chybí hranice DNS: nic na místní straně neví, že na určitou privátní zónu Azure má odpovídat resolver uvnitř VNet. Tuto mezeru zacelují dva návrhy a liší se v tom, co nakonec provozujete, ne v tom, zda dotazy fungují.
Tunel přenáší dotazy, ne znalost zón
Spojení site-to-site dává paketům trasu mezi oběma sítěmi. Neříká však místnímu serveru DNS, který jmenný prostor patří Azure a která adresa má odpovídat, takže dotaz buď odejde do internetu a vrátí se prázdný, nebo nikdy neopustí místní resolver.
Oprava má dvě poloviny, které lze snadno oddělit. Jedna polovina je resolver uvnitř VNet, který přijímá dotazy přicházející tunelem. Druhá je podmíněný forwarder na místní straně, který posílá právě jeden jmenný prostor tomuto resolveru. Ani jedna polovina nefunguje sama.
Pro zbytek tohoto postupu předpokládejte, že zóna je cloud.corp.example, a každou adresu berte jako ilustrativní.
Možnost A: spravovaný příchozí koncový bod
Azure DNS Private Resolver poskytuje příchozí koncový bod, který přijímá dotazy DNS zvenčí VNet. Nasadíte ho do vyhrazené delegované podsítě, propojíte privátní zónu s touto VNet a poznamenáte si příchozí adresu, kterou služba přidělí.
Na místním serveru DNS pak vytvoříte podmíněný forwarder pro přesný jmenný prostor směrem k této adrese:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Postup hybridního DNS od Microsoftu dokumentuje jak propojení zóny, tak krok forwarderu. Spravovaná cesta vám nezanechá žádný software DNS k záplatování a adresa koncového bodu zůstává stabilní po celou dobu životnosti prostředku.
Cena je, že nyní vlastníte prostředek resolveru, jeho delegaci podsítě a jeho náklady, což je reálné i tehdy, když je objem dotazů nepatrný.
Možnost B: forwarder na virtuálním počítači uvnitř VNet
Starší návrh provozuje software DNS na běžném virtuálním počítači ve VNet: Windows DNS, BIND nebo dnsmasq, přičemž privátní zóna je buď hostována lokálně, nebo předávána resolveru Azure na 168.63.129.16. Místní podmíněný forwarder ukazuje na privátní adresu tohoto počítače.
Tato možnost je známá týmům, které už servery DNS provozují, a může nést další logiku, například logování nebo odpovědi split-horizon. Zdědí také všechny provozní povinnosti serveru DNS: záplatování, druhou instanci pro dostupnost, monitorování a cestu přestavby, když je počítač nahrazen a jeho adresa se změní.
Běžný hostitel VNet není proxy DNS, dokud není služba nainstalována a nesmí odpovídat těmto klientům, a právě tento krok lidé při klonování virtuálního počítače vynechávají.
Která se hodí pro váš provoz
Srovnání není o tom, který návrh je rychlejší. Je o tom, zda vůbec chcete provozovat software DNS a zda objem dotazů ospravedlní spravovaný prostředek účtovaný podle koncového bodu a podle dotazů.
| 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 |
Ať rozhodne kterýkoli řádek, pravidlo forwarderu na místní straně vypadá stejně. To je část, která musí existovat v obou návrzích, a je to část, která nejčastěji chybí, když někdo hlásí, že překlad funguje zevnitř Azure, ale ne z kanceláře.
Zkontrolujte cestu popořadě
Ověřte, že zóna je propojena s VNet, která obsahuje resolver, a že místní forwarder jmenuje jmenný prostor, nikoli nadřazenou doménu. Forwarder pro corp.example nebude odpovídat cloud.corp.example, pokud sám resolver nedeleguje, a tento nesoulad vytváří čistě negativní odpověď, která vypadá jako chybějící záznam.
Pak ověřte, že dotaz dorazí ke koncovému bodu: místní zdroj potřebuje trasu k adrese resolveru a zpětnou cestu a port 53 pro UDP i TCP by měl být povolen tam, kde to politika dovoluje. NSG nemůže dodat chybějící záznam zóny a správná zóna nemůže odpovědět na dotaz, který nikdy nedorazí.
Při diagnostice mějte požadované FQDN vedle zvoleného resolveru a odlište vypršení časového limitu od negativní odpovědi. Vypršení je problém cesty nebo politiky. Negativní odpověď znamená, že dotaz dorazil a jmenný prostor neseděl. Pořadí práce: propojte zónu, přidejte podmíněný forwarder, otevřete port 53 oběma směry, otestujte jeden název z místní sítě a teprve potom se podívejte na vlastní autorizaci aplikace.