Privatni DNS u Azureu preko VPN-a: završna točka resolvera ili forwarder
Oba dizajna odgovaraju na privatne zone kroz tunel. Usporedite upravljanu ulaznu završnu točku s forwarder VM-om, a zatim provjerite put koji mora postojati u svakom slučaju.
Poslužitelj u lokalnoj mreži doseže Azure VM preko privatne adrese i ipak ne može razriješiti njezino privatno ime hosta, što ljude šalje u potragu za pokvarenim tunelom. Tunel je u redu. Nedostaje DNS granica: ništa na lokalnoj strani ne zna da na određenu privatnu Azure zonu mora odgovoriti resolver unutar VNet-a. Dva dizajna zatvaraju taj jaz i razlikuju se po tome što na kraju upravljate, a ne po tome rade li upiti.
Tunel prenosi upite, ne znanje o zonama
Veza site-to-site daje paketima rutu između dviju mreža. Ne govori lokalnom DNS poslužitelju koji prostor imena pripada Azureu ni koja adresa treba odgovoriti, pa upit ili ode na internet i vrati se prazan ili nikad ne napusti lokalni resolver.
Ispravak ima dvije polovice koje je lako razdvojiti. Jedna polovica je resolver unutar VNet-a koji prihvaća upite koji dolaze kroz tunel. Druga je uvjetni forwarder na lokalnoj strani koji šalje točno jedan prostor imena tom resolveru. Nijedna polovica ne radi sama.
Pretpostavite da je zona cloud.corp.example za ostatak ovog opisa i svaku adresu smatrajte ilustrativnom.
Opcija A: upravljana ulazna završna točka
Azure DNS Private Resolver pruža ulaznu završnu točku koja prihvaća DNS upite izvan VNet-a. Postavljate je u namjensku delegiranu podmrežu, povezujete privatnu zonu s tim VNet-om i bilježite ulaznu adresu koju usluga dodjeljuje.
Na lokalnom DNS poslužitelju zatim stvarate uvjetni forwarder za točan prostor imena prema toj adresi:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoftov postupak hibridnog DNS-a dokumentira i povezivanje zone i korak forwardera. Upravljani put ne ostavlja nikakav DNS softver za krpanje, a adresa završne točke ostaje stabilna tijekom cijelog vijeka resursa.
Cijena je da sada posjedujete resolver resurs, njegovo delegiranje podmreže i njegov trošak, koji je stvaran čak i kad je volumen upita vrlo mali.
Opcija B: forwarder VM unutar VNet-a
Stariji dizajn pokreće DNS softver na običnom VM-u u VNet-u: Windows DNS, BIND ili dnsmasq, a privatna zona je ili lokalno hostana ili proslijeđena Azure resolveru na 168.63.129.16. Lokalni uvjetni forwarder pokazuje na privatnu adresu tog VM-a.
Ova je opcija poznata timovima koji već pokreću DNS poslužitelje i može nositi dodatnu logiku poput zapisivanja u dnevnik ili split-horizon odgovora. Nasljeđuje i svaku operativnu obvezu DNS poslužitelja: krpanje, drugu instancu za dostupnost, nadzor i put ponovne izgradnje kad se VM zamijeni i njegova adresa promijeni.
Običan VNet host nije DNS proxy dok usluga nije instalirana i dok joj nije dopušteno odgovarati tim klijentima, a to je korak koji ljudi preskaču pri kloniranju VM-a.
Koja odgovara vašem radu
Usporedba nije o tome koji je dizajn brži. Riječ je o tome želite li uopće upravljati DNS softverom i opravdava li volumen upita upravljani resurs koji se naplaćuje po završnoj točki i po upitu.
| 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 |
Koji god red prevagne, pravilo forwardera na lokalnoj strani izgleda isto. To je dio koji mora postojati u oba dizajna i to je dio koji najčešće nedostaje kad netko prijavi da razrješavanje radi iz Azurea, ali ne iz ureda.
Provjerite put redom
Potvrdite da je zona povezana s VNet-om koji drži resolver i da lokalni forwarder navodi prostor imena, a ne roditeljsku domenu. Forwarder za corp.example neće se podudarati s cloud.corp.example ako sam resolver ne delegira, a nesklad daje čist negativan odgovor koji izgleda kao zapis koji nedostaje.
Zatim provjerite dolazi li upit do završne točke: lokalni izvor treba rutu do adrese resolvera i povratni put, a port 53 za UDP i TCP trebao bi biti dopušten gdje politika to dopušta. NSG ne može osigurati zapis zone koji nedostaje, a ispravna zona ne može odgovoriti na upit koji nikad ne stigne.
Držite traženi FQDN uz odabrani resolver kad dijagnosticirate i razdvojite istek vremena od negativnog odgovora. Istek vremena problem je rute ili politike. Negativan odgovor znači da je upit stigao, a prostor imena nije odgovarao. Redoslijed rada: povežite zonu, dodajte uvjetni forwarder, otvorite port 53 u oba smjera, isprobajte jedno ime s lokalne strane i tek onda pogledajte vlastito ovlaštenje aplikacije.