Azureko DNS pribatua VPN bidez: resolver mutur-puntua edo forwarderra
Bi diseinuek zona pribatuak erantzuten dituzte tuneletik. Konparatu kudeatutako sarrerako mutur-puntu bat forwarder VM batekin, eta gero egiaztatu beti egon behar duen bidea.
Lokaleko zerbitzari batek Azureko VM bat helbide pribatuaz iristen da eta oraindik ezin du bere host-izen pribatua ebatzi, eta horrek jendea tunel hautsia bilatzera bultzatzen du. Tunela ondo dago. Falta dena DNS muga bat da: lokaleko aldean ez daki ezer Azureko zona pribatu jakin bat VNet barruko resolver batek erantzun behar duenik. Bi diseinuk betetzen dute hutsune hori, eta desberdinak dira azkenean zer ustiatzen duzun, ez ea kontsultak funtzionatzen duten.
Tunelak kontsultak garraiatzen ditu, ez zonen ezagutza
Gune arteko konexioak paketeei bi sareen arteko ibilbidea ematen die. Ez dio lokaleko DNS zerbitzariari zein izen-espazio dagokion Azurei edo zein helbidek erantzun behar duen, beraz kontsulta Internetera joaten da eta hutsik itzultzen da, edo ez da inoiz resolver lokala uzten.
Konponbideak erraz bereizten diren bi erdi ditu. Erdietako bat VNet barruko resolver bat da, tuneletik iristen diren kontsultak onartzen dituena. Bestea lokaleko aldean dagoen baldintzapeko forwarder bat da, izen-espazio zehatz bat resolver horri bidaltzen diona. Ez erdi batek ez besteak ez du bakarka funtzionatzen.
Demagun zona cloud.corp.example dela gainerako azalpenean, eta har ezazu helbide bakoitza ilustrazio gisa.
A aukera: kudeatutako sarrerako mutur-puntua
Azure DNS Private Resolverrek sarrerako mutur-puntu bat eskaintzen du, VNetetik kanpoko DNS kontsultak onartzen dituena. Subnet delegatu dedikatu batean zabaltzen duzu, zona pribatua VNet horri lotzen diozu eta zerbitzuak esleitzen duen sarrerako helbidea apuntatzen duzu.
Ondoren, lokaleko DNS zerbitzariak baldintzapeko forwarder bat sortzen duzu izen-espazio zehatzarentzat helbide horretarantz:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoftek DNS hibridoaren prozeduran dokumentatzen ditu zona-lotura eta forwarder urratsa. Bide kudeatuak ez dizu adabakitzeko DNS softwarearik uzten, eta mutur-puntuaren helbidea egonkor mantentzen da baliabidearen bizitza osoan.
Prezioa da orain resolver baliabide bat, haren subnet delegazioa eta haren kostua dituzula, benetakoa baita kontsulta bolumena oso txikia denean ere.
B aukera: forwarder VM bat VNet barruan
Diseinu zaharrenak DNS softwarea exekutatzen du VNet barruko VM arrunt batean: Windows DNS, BIND edo dnsmasq, zona pribatua lokaleko ostalari gisa edo 168.63.129.16 helbideko Azure resolverrera birbidalita. Lokaleko baldintzapeko forwarderrak VM horren helbide pribatura seinalatzen du.
Aukera hau ezaguna da jada DNS zerbitzariak ustiatzen dituzten taldeentzat, eta loga edo split-horizon erantzunak bezalako logika gehigarria eraman dezake. DNS zerbitzari baten ustiapen-eginbehar guztiak ere heredatzen ditu: adabakiak, bigarren instantzia erabilgarritasunerako, monitorizazioa eta berreraikitzeko bidea VM ordezkatu eta haren helbidea aldatzen denean.
VNet ostalari arrunta ez da DNS proxy zerbitzua instalatu eta bezero horiei erantzuteko baimena eman arte, eta VM bat klonatzean jendeak saltatzen duen urratsa horixe da.
Zein egokitzen zaion zure ustiapenari
Konparazioa ez da zein diseinu azkarriena den. Gainean dago ea DNS softwarea ustiatu nahi duzun ala ez, eta ea kontsulta bolumenak justifikatzen duen mutur-puntuaren eta kontsultaren arabera fakturatzen duen baliabide kudeatu bat.
| 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 |
Edozein errenkadak erabakitzen badu ere, lokaleko forwarder araua berdin ikusten da. Hori da bi diseinuetan egon behar duen zatia, eta horixe da sarrien falta den zatia norbaitek Azure barruan ebazpena funtzionatzen duela baina bulegotik ez duela esaten duenean.
Egiaztatu bidea ordenan
Egiaztatu zona resolverra daukan VNetari lotuta dagoela, eta lokaleko forwarderrak izen-espazioa aipatzen duela, ez guraso domeinua. corp.example-ren forwarder bat ez dator bat cloud.corp.example-rekin resolverrak berak delegatzen ez badu, eta desadostasunak erantzun negatibo garbia sortzen du, erregistro faltak bezala itxura egiten duena.
Gero egiaztatu kontsulta mutur-puntura iristen dela: lokaleko iturriak resolverren helbiderako ibilbidea eta itzulera-bidea behar ditu, eta 53 portuak UDP zein TCP bidez baimenduta egon behar luke politikak uzten duen tokian. NSG batek ezin du zona-erregistro falta bat eman, eta zona zuzen batek ezin dio inoiz iristen ez den kontsulta bati erantzun.
Eduki eskatutako FQDN aukeratutako resolverraren ondoan diagnostikatzean, eta bereizi denbora-muga erantzun negatibotik. Denbora-muga bide edo politika arazoa da. Erantzun negatiboak esan nahi du kontsulta iritsi zela eta izen-espazioak ez zuela bat egin. Lan-ordena: lotu zona, gehitu baldintzapeko forwarderra, ireki 53 portua bi norabideetan, probatu izen bat lokaletik, eta orduan bakarrik begiratu aplikazioaren berezko baimena.