DNS privat i Azure mbi VPN: pika fundore e resolver-it ose forwarder
Të dy dizajnet u përgjigjen zonave private përmes tunelit. Krahasoni pikën fundore hyrëse të menaxhuar me një VM forwarder, pastaj kontrolloni rrugën që duhet të ekzistojë në të dyja rastet.
Një server në ambientin lokal arrin një VM të Azure me adresë private dhe prapë nuk mund të zgjidhë emrin e tij privat të hostit, gjë që i shtyn njerëzit të kërkojnë një tunel të prishur. Tuneli është në rregull. Ajo që mungon është një kufi DNS: asgjë në anën lokale nuk e di se një zonë private e caktuar e Azure duhet të përgjigjet nga një resolver brenda VNet. Dy dizajne e mbyllin atë boshllëk, dhe ato ndryshojnë në atë që në fund administroni, jo në atë nëse pyetjet funksionojnë.
Tuneli mbart pyetje, jo njohuri për zonat
Një lidhje site-to-site u jep paketave një rrugë midis dy rrjeteve. Ajo nuk i thotë serverit DNS lokal se cila hapësirë emrash i përket Azure ose cila adresë duhet të përgjigjet, kështu që pyetja ose shkon në internet dhe kthehet bosh, ose nuk e lë kurrë resolver-in lokal.
Rregullimi ka dy gjysma që ndahen lehtë. Njëra gjysmë është një resolver brenda VNet që pranon pyetjet që vijnë përmes tunelit. Tjetra është një forwarder i kushtëzuar në anën lokale që dërgon saktësisht një hapësirë emrash te ai resolver. Asnjëra gjysmë nuk funksionon vetëm.
Supozoni se zona është cloud.corp.example për pjesën tjetër të këtij shpjegimi dhe trajtoni çdo adresë si ilustruese.
Opsioni A: pika fundore hyrëse e menaxhuar
Azure DNS Private Resolver ofron një pikë fundore hyrëse që pranon pyetje DNS nga jashtë VNet. Ju e vendosni atë në një nënrrjet të deleguar të dedikuar, lidhni zonën private me atë VNet dhe shënoni adresën hyrëse që cakton shërbimi.
Në serverin DNS lokal më pas krijoni një forwarder të kushtëzuar për hapësirën e saktë të emrave drejt asaj adrese:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Procedura e DNS hibrid e Microsoft dokumenton si lidhjen e zonës ashtu edhe hapin e forwarder-it. Rruga e menaxhuar nuk lë asnjë softuer DNS për t'u rregulluar, dhe adresa e pikës fundore mbetet e qëndrueshme gjatë gjithë jetës së burimit.
Çmimi është se tani zotëroni një burim resolver, delegimin e nënrrjetit të tij dhe koston e tij, e cila është reale edhe kur vëllimi i pyetjeve është shumë i vogël.
Opsioni B: një VM forwarder brenda VNet
Dizajni më i vjetër ekzekuton softuer DNS në një VM të zakonshme brenda VNet: Windows DNS, BIND ose dnsmasq, me zonën private ose të strehuar lokalisht ose të përcjellë te resolver-i i Azure në 168.63.129.16. Forwarder-i i kushtëzuar lokal tregon adresën private të asaj VM.
Ky opsion është i njohur për ekipet që tashmë operojnë serverë DNS dhe mund të mbajë logjikë shtesë si regjistrim ose përgjigje split-horizon. Ai trashëgon gjithashtu çdo detyrë operacionale të një serveri DNS: rregullime, një instancë të dytë për disponueshmëri, monitorim dhe një rrugë rindërtimi kur VM zëvendësohet dhe adresa e tij ndryshon.
Një host i zakonshëm VNet nuk është proxy DNS derisa shërbimi të instalohet dhe të lejohet të përgjigjet atyre klientëve, dhe ky është hapi që njerëzit e kapërcejnë kur klonojnë një VM.
Cili i përshtatet operacionit tuaj
Krahasimi nuk ka të bëjë me atë se cili dizajn është më i shpejtë. Ka të bëjë me atë nëse dëshironi të operoni softuer DNS fare, dhe nëse vëllimi i pyetjeve justifikon një burim të menaxhuar që faturohet për pikë fundore dhe për pyetje.
| 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 |
Cilado rresht vendos, rregulli i forwarder-it lokal duket i njëjtë. Kjo është pjesa që duhet të ekzistojë në të dy dizajnet, dhe është pjesa që mungon më shpesh kur dikush raporton se zgjidhja funksionon brenda Azure por jo nga zyra.
Kontrolloni rrugën me radhë
Konfirmoni se zona është e lidhur me VNet që mban resolver-in, dhe se forwarder-i lokal përmend hapësirën e emrave dhe jo një domen prind. Një forwarder për corp.example nuk do të përputhet me cloud.corp.example nëse vetë resolver-i nuk delegon, dhe mospërputhja prodhon një përgjigje negative të pastër që duket si një regjistrim që mungon.
Më pas kontrolloni nëse pyetja arrin pikën fundore: burimi lokal ka nevojë për një rrugë drejt adresës së resolver-it dhe një rrugë kthimi, dhe porta 53 si për UDP ashtu edhe për TCP duhet të lejohet aty ku politika e lejon. Një NSG nuk mund të sigurojë një regjistrim zone që mungon, dhe një zonë e saktë nuk mund të përgjigjet për një pyetje që nuk arrin kurrë.
Mbajeni FQDN-në e kërkuar pranë resolver-it që zgjidhni kur diagnostikoni, dhe ndani një skadim kohe nga një përgjigje negative. Skadimi i kohës është problem rruge ose politike. Një përgjigje negative do të thotë që pyetja arriti dhe hapësira e emrave nuk përputhej. Rendi i punës: lidhni zonën, shtoni forwarder-in e kushtëzuar, hapni portën 53 në të dy drejtimet, provoni një emër nga lokali dhe vetëm pastaj shikoni autorizimin e vetë aplikacionit.