Azure private DNS oor VPN: resolver-eindpunt of forwarder
Beide ontwerpe beantwoord private zones oor die tonnel. Vergelyk 'n bestuurde inkomende eindpunt met 'n forwarder-VM, en kyk dan na die pad wat in elk geval moet bestaan.
'n Bediener op die perseel bereik 'n Azure-VM per private adres en kan steeds nie sy private gasheernaam oplos nie, wat mense laat soek na 'n stukkende tonnel. Die tonnel is reg. Wat ontbreek, is 'n DNS-grens: niks aan die perseel se kant weet dat 'n bepaalde Azure private zone deur 'n resolver binne die VNet beantwoord moet word nie. Twee ontwerpe vul daardie gaping, en hulle verskil in wat jy uiteindelik bedryf, nie in of navrae werk nie.
Die tonnel dra navrae, nie zone-kennis nie
'n Werf-tot-werf-verbinding gee pakkette 'n roete tussen die twee netwerke. Dit sê nie vir die DNS-bediener op die perseel watter naamruimte aan Azure behoort of watter adres dit moet beantwoord nie, so die navraag gaan óf na die internet en kom leeg terug, óf verlaat nooit die plaaslike resolver nie.
Die oplossing het twee helftes wat maklik skeibaar is. Een helfte is 'n resolver binne die VNet wat navrae aanvaar wat oor die tonnel aankom. Die ander helfte is 'n voorwaardelike forwarder aan die perseel se kant wat presies een naamruimte na daardie resolver stuur. Nie een helfte werk alleen nie.
Aanvaar dat die zone cloud.corp.example is vir die res van hierdie uiteensetting, en beskou elke adres as illustratief.
Opsie A: die bestuurde inkomende eindpunt
Azure DNS Private Resolver bied 'n inkomende eindpunt wat DNS-navrae van buite die VNet aanvaar. Jy ontplooi dit in 'n toegewyde gedelegeerde subnet, koppel die private zone aan daardie VNet, en noteer die inkomende adres wat die diens toeken.
Op die DNS-bediener op die perseel skep jy dan 'n voorwaardelike forwarder vir die presiese naamruimte na daardie adres:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft se hibriede DNS-prosedure dokumenteer beide die zone-koppeling en die forwarder-stap. Die bestuurde pad laat jou met geen DNS-sagteware om te pleister nie, en die eindpuntadres bly stabiel vir die lewensduur van die hulpbron.
Die prys is dat jy nou 'n resolver-hulpbron, sy subnet-delegering en sy koste besit, wat werklik is selfs wanneer die navraagvolume gering is.
Opsie B: 'n forwarder-VM binne die VNet
Die ouer ontwerp hardloop DNS-sagteware op 'n gewone VM in die VNet: Windows DNS, BIND of dnsmasq, met die private zone óf plaaslik gehuisves óf deurgestuur na die Azure-resolver by 168.63.129.16. Die voorwaardelike forwarder op die perseel wys na daardie VM se private adres.
Hierdie opsie is bekend vir spanne wat reeds DNS-bedieners bedryf, en dit kan ekstra logika soos joernaalvoering of split-horizon-antwoorde dra. Dit erf ook elke bedryfsplig van 'n DNS-bediener: pleister, 'n tweede instansie vir beskikbaarheid, monitering, en 'n herbouepad wanneer die VM vervang word en sy adres verander.
'n Gewone VNet-gasheer is nie 'n DNS-volmag nie voordat die diens geïnstalleer is en toegelaat word om daardie kliënte te beantwoord nie, en dit is die stap wat mense oorslaan wanneer hulle 'n VM kloon.
Watter een pas by jou bedryf
Die vergelyking gaan nie oor watter ontwerp vinniger is nie. Dit gaan oor of jy hoegenaamd DNS-sagteware wil bedryf, en of die navraagvolume 'n bestuurde hulpbron regverdig wat per eindpunt en per navraag faktureer.
| 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 |
Watter ry ook al die besluit neem, die forwarder-reël op die perseel lyk dieselfde. Dit is die deel wat in beide ontwerpe moet bestaan, en dit is die deel wat die meeste ontbreek wanneer iemand rapporteer dat oplossing binne Azure werk maar nie vanuit die kantoor nie.
Kontroleer die pad in volgorde
Bevestig die zone is gekoppel aan die VNet wat die resolver huisves, en bevestig die forwarder op die perseel noem die naamruimte eerder as 'n ouer domein. 'n Forwarder vir corp.example pas nie by cloud.corp.example nie, tensy die resolver self delegeer, en die wanverhouding lewer 'n skoon negatiewe antwoord wat soos 'n ontbrekende rekord lyk.
Kontroleer dan dat die navraag die eindpunt bereik: die bron op die perseel het 'n roete na die resolver-adres en 'n terugpad nodig, en beide UDP- en TCP-poort 53 moet toegelaat word waar die beleid dit toelaat. 'n NSG kan nie 'n ontbrekende zone-rekord voorsien nie, en 'n korrekte zone kan nie 'n navraag beantwoord wat nooit aankom nie.
Hou die versoekte FQDN langs die resolver wat jy gekies het wanneer jy diagnoseer, en skei 'n tydverstreke van 'n negatiewe antwoord. 'n Tydverstreke is 'n pad- of beleidsprobleem. 'n Negatiewe antwoord beteken die navraag het aangekom en die naamruimte het nie gepas nie. Volgorde van werk: koppel die zone, voeg die voorwaardelike forwarder by, open poort 53 in beide rigtings, toets een naam vanaf die perseel, en kyk eers dan na die toepassing se eie magtiging.