Einka-DNS Azure yfir VPN: endapunktur resolvers eða framsendingarþjónn
Báðar hönnunargrindur svara einkasvæðum gegnum göngin. Berið saman stýrðan inngangsendapunkt við framsendingar-VM og athugið síðan leiðina sem verður að vera til í báðum tilfellum.
Netþjónn á staðnum nær í Azure VM á einkafangi og getur samt ekki leyst einkanafn hans, sem sendir fólk að leita að biluðum göngum. Göngin eru í lagi. Það sem vantar er DNS-mörk: ekkert á staðnum veit að tiltekið einkasvæði Azure eigi að vera svarað af resolver inni í VNetinu. Tvær hönnunargrindur loka þessu eyðu, og þær eru ólíkar að því sem þú rekur að lokum, ekki að því hvort fyrirspurnir virka.
Göngin flytja fyrirspurnir, ekki þekkingu á svæðum
Tengi staðar-í-stað gefur pökkunum leið milli netanna tveggja. Það segir DNS-þjóninum á staðnum ekki hvaða nafnrými tilheyrir Azure eða hvaða vistfang eigi að svara, svo fyrirspurnin fer annaðhvort út á netið og kemur tóm til baka, eða yfirgefur aldrei staðbundna resolverinn.
Lagfæringin hefur tvo helminga sem auðvelt er að skilja að. Annar helmingurinn er resolver inni í VNetinu sem tekur við fyrirspurnum sem berast um göngin. Hinn er skilyrtur framsendingarþjónn á staðnum sem sendir nákvæmlega eitt nafnrými til þess resolver. Enginn helmingur virkar einn.
Gefðu þér að svæðið sé cloud.corp.example í restina af þessari lýsingu, og meðhöndlaðu hvert vistfang sem dæmi.
Val A: stýrði inngangsendapunkturinn
Azure DNS Private Resolver býður inngangsendapunkt sem tekur við DNS-fyrirspurnum utan VNetsins. Þú setur hann í sérstakt framselt undirnet, tengir einkasvæðið við það VNet og skráir inngangsvistfangið sem þjónustan úthlutar.
Á DNS-þjóninum á staðnum býrðu síðan til skilyrtan framsendingarþjón fyrir nákvæma nafnrýmið í átt að því vistfangi:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Hýbríð DNS-aðferð Microsoft skjalfestir bæði svæðistenginguna og framsendingarskrefið. Stýrða leiðin skilur ekkert DNS-hugbúnað eftir til að plástra, og vistfang endapunktsins helst stöðugt alla ævi auðlindarinnar.
Verðið er að þú átt nú resolver-auðlind, undirnetsframselingu hennar og kostnað, sem er raunverulegur jafnvel þótt fyrirspurnamagnið sé örlítið.
Val B: framsendingar-VM inni í VNetinu
Eldri hönnunin keyrir DNS-hugbúnað á venjulegri VM í VNetinu: Windows DNS, BIND eða dnsmasq, og einkasvæðið er annaðhvort hýst á staðnum eða sent á Azure-resolverinn á 168.63.129.16. Skilyrti framsendingarþjónninn á staðnum bendir á einkavistfang þeirrar VM.
Þessi valkostur er kunnuglegur teymum sem reka þegar DNS-þjóna, og hann getur borið viðbótarrökfræði eins og skráningu eða split-horizon svör. Hann erfir líka hverja rekstrarskyldu DNS-þjóns: plástrun, annað eintak fyrir framboð, vöktun og enduruppbyggingarleið þegar VM er skipt út og vistfang hennar breytist.
Venjulegur VNet-hýsing er ekki DNS-vegvísir fyrr en þjónustan er uppsett og hefur leyfi til að svara þeim biðlurum, og það er skrefið sem fólk sleppir þegar það klónar VM.
Hvor passar rekstrinum þínum
Samanburðurinn snýst ekki um hvor hönnunin er hraðari. Hann snýst um hvort þú viljir yfirhöfuð reka DNS-hugbúnað, og hvort fyrirspurnamagnið réttlæti stýrða auðlind sem rukkar eftir endapunkti og eftir fyrirspurn.
| 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 |
Hvaða röð sem ræður, reglan um framsendingarþjón á staðnum er sú sama. Það er hlutinn sem verður að vera til í báðum hönnunum, og það er hlutinn sem oftast vantar þegar einhver segir að upplausn virki innan frá Azure en ekki frá skrifstofunni.
Athugaðu leiðina í réttri röð
Staðfestu að svæðið sé tengt VNetinu sem hýsir resolverinn, og að framsendingarþjónninn á staðnum nefni nafnrýmið en ekki yfirsvæði. Framsendingarþjónn fyrir corp.example passar ekki við cloud.corp.example nema resolverinn framselji sjálfur, og misræmið gefur hreint neikvætt svar sem lítur út eins og vanti færslu.
Athugaðu síðan að fyrirspurnin nái endapunktinum: uppruninn á staðnum þarf leið að vistfangi resolversins og leið til baka, og port 53 ætti að vera leyft fyrir bæði UDP og TCP þar sem stefnan leyfir það. NSG getur ekki útvegað svæðisfærslu sem vantar, og rétt svæði getur ekki svarað fyrirspurn sem kemur aldrei.
Haltu fyrirspurninni FQDN við hlið resolversins sem þú valdir þegar þú greinir, og aðgreindu tímanýtingu frá neikvæðu svari. Tímanýting er leiðar- eða stefnuvandamál. Neikvætt svar þýðir að fyrirspurnin kom og nafnrýmið passaði ekki. Vinnsluröð: tengdu svæðið, bættu við skilyrta framsendingarþjóninum, opnaðu port 53 í báðar áttir, prófaðu eitt nafn frá staðnum, og skoðaðu svo fyrst heimild forritsins sjálfs.