Privátny DNS v Azure cez VPN: koncový bod resolvera alebo forwarder
Oba návrhy odpovedajú na privátne zóny cez tunel. Porovnajte spravovaný prichádzajúci koncový bod s VM forwardera a potom skontrolujte cestu, ktorá musí existovať v oboch prípadoch.
Server v miestnej sieti dosiahne VM Azure cez privátnu adresu a napriek tomu nedokáže preložiť jej privátny názov hostiteľa, čo ľudí pošle hľadať pokazený tunel. Tunel je v poriadku. Chýba hranica DNS: nič na miestnej strane nevie, že na určitú privátnu zónu Azure má odpovedať resolver vo vnútri VNet. Dva návrhy túto medzeru uzatvárajú a líšia sa tým, čo nakoniec prevádzkujete, nie tým, či dopyty fungujú.
Tunel prenáša dopyty, nie znalosť zón
Prepojenie site-to-site dáva paketom trasu medzi oboma sieťami. Nehovorí miestnemu serveru DNS, ktorý menný priestor patrí Azure alebo ktorá adresa má odpovedať, takže dopyt buď ide do internetu a vráti sa prázdny, alebo nikdy neopustí miestny resolver.
Oprava má dve ľahko oddeliteľné polovice. Jedna polovica je resolver vo vnútri VNet, ktorý prijíma dopyty prichádzajúce tunelom. Druhá je podmienený forwarder na miestnej strane, ktorý posiela presne jeden menný priestor tomu resolveru. Ani jedna polovica nefunguje sama.
Pre zvyšok tohto opisu predpokladajme, že zóna je cloud.corp.example, a každú adresu berte ako ilustratívnu.
Možnosť A: spravovaný prichádzajúci koncový bod
Azure DNS Private Resolver poskytuje prichádzajúci koncový bod, ktorý prijíma dopyty DNS zvonku VNet. Nasadíte ho do vyhradenej delegovanej podsiete, prepojíte privátnu zónu s tou VNet a poznamenáte si prichádzajúcu adresu, ktorú služba pridelí.
Na miestnom serveri DNS potom vytvoríte podmienený forwarder pre presný menný priestor smerom na tú adresu:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Postup hybridného DNS od Microsoftu dokumentuje prepojenie zóny aj krok forwardera. Spravovaná cesta nezanecháva žiadny softvér DNS na záplatovanie a adresa koncového bodu zostáva stabilná po celú životnosť prostriedku.
Cena je, že teraz vlastníte prostriedok resolvera, jeho delegáciu podsiete a jeho náklady, ktoré sú reálne aj pri nepatrnom objeme dopytov.
Možnosť B: VM s forwarderom vo vnútri VNet
Starší návrh prevádzkuje softvér DNS na bežnej VM vo VNet: Windows DNS, BIND alebo dnsmasq, pričom privátna zóna je buď hostovaná lokálne, alebo preposielaná resolveru Azure na 168.63.129.16. Miestny podmienený forwarder ukazuje na privátnu adresu tejto VM.
Táto možnosť je známa tímom, ktoré už servery DNS prevádzkujú, a môže niesť ďalšiu logiku, napríklad logovanie alebo odpovede split-horizon. Zdedí aj všetky prevádzkové povinnosti servera DNS: záplatovanie, druhú inštanciu pre dostupnosť, monitorovanie a cestu prestavby, keď sa VM vymení a jej adresa sa zmení.
Bežný hostiteľ VNet nie je proxy DNS, kým služba nie je nainštalovaná a nesmie odpovedať týmto klientom, a práve tento krok ľudia pri klonovaní VM vynechávajú.
Ktorá sa hodí pre vašu prevádzku
Porovnanie nie je o tom, ktorý návrh je rýchlejší. Je o tom, či vôbec chcete prevádzkovať softvér DNS a či objem dopytov ospravedlní spravovaný prostriedok účtovaný podľa koncového bodu a podľa dopytu.
| 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 |
Nech rozhodne ktorýkoľvek riadok, pravidlo forwardera na miestnej strane vyzerá rovnako. To je časť, ktorá musí existovať v oboch návrhoch, a je to časť, ktorá najčastejšie chýba, keď niekto hlási, že preklad funguje zvnútra Azure, ale nie z kancelárie.
Skontrolujte cestu po poradí
Overte, že zóna je prepojená s VNet, ktorá obsahuje resolver, a že miestny forwarder pomenúva menný priestor, nie nadradenú doménu. Forwarder pre corp.example sa nebude zhodovať s cloud.corp.example, ak sám resolver nedeleguje, a tento nesúlad vytvára čistú negatívnu odpoveď, ktorá vyzerá ako chýbajúci záznam.
Potom overte, či dopyt dorazí ku koncovému bodu: miestny zdroj potrebuje trasu k adrese resolvera a spätnú cestu a port 53 by mal byť povolený pre UDP aj TCP tam, kde to politika dovoľuje. NSG nemôže dodať chýbajúci záznam zóny a správna zóna nemôže odpovedať na dopyt, ktorý nikdy nedorazí.
Pri diagnostike majte požadované FQDN vedľa zvoleného resolvera a odlište vypršanie časového limitu od negatívnej odpovede. Vypršanie je problém trasy alebo politiky. Negatívna odpoveď znamená, že dopyt dorazil a menný priestor nesedel. Poradie práce: prepojte zónu, pridajte podmienený forwarder, otvorte port 53 oboma smermi, otestujte jeden názov z miestnej siete a až potom sa pozrite na vlastnú autorizáciu aplikácie.