DNS privat d'Azure sobre VPN: punt de extrem del resolutor o forwarder
Tots dos dissenys responen zones privades pel túnel. Compareu un punt de extrem d'entrada gestionat amb una VM forwarder i, després, comproveu el camí que ha d'existir en qualsevol cas.
Un servidor local arriba a una VM d'Azure per adreça privada i tot i així no pot resoldre el seu nom d'amfitrió privat, cosa que fa que la gent busqui un túnel trencat. El túnel està bé. El que falta és una frontera de DNS: res a la banda local no sap que una zona privada concreta d'Azure ha de ser respost per un resolutor dins de la VNet. Dos dissenys tanquen aquesta escletxa, i es diferencien en el que acabes operant, no en si les consultes funcionen.
El túnel transporta consultes, no coneixement de zones
Una connexió de lloc a lloc dóna als paquets una ruta entre les dues xarxes. No diu al servidor DNS local quin espai de noms pertany a Azure ni quina adreça ha de respondre, així que la consulta o va a Internet i torna buida o no surt mai del resolutor local.
La solució té dues meitats fàcils de separar. Una meitat és un resolutor dins de la VNet que accepta consultes que arriben pel túnel. L'altra és un forwarder condicional a la banda local que envia exactament un espai de noms a aquest resolutor. Cap de les dues meitats funciona sola.
Suposem que la zona és cloud.corp.example per a la resta d'aquest recorregut, i tracteu cada adreça com a il·lustrativa.
Opció A: el punt de extrem d'entrada gestionat
Azure DNS Private Resolver proporciona un punt de extrem d'entrada que accepta consultes DNS de fora de la VNet. El desplegueu en una subxarxa delegada dedicada, enllaceu la zona privada a aquesta VNet i anoteu l'adreça d'entrada que assigna el servei.
Al servidor DNS local, després creeu un forwarder condicional per a l'espai de noms exacte cap a aquesta adreça:
Namespace: cloud.corp.example
Forward to: 10.20.2.4El procediment de DNS híbrid de Microsoft documenta tant l'enllaç de la zona com el pas del forwarder. El camí gestionat us deixa sense cap programari DNS per pedaçar, i l'adreça del punt de extrem es manté estable durant tota la vida del recurs.
El preu és que ara teniu un recurs de resolutor, la seva delegació de subxarxa i el seu cost, que és real fins i tot quan el volum de consultes és minúscul.
Opció B: una VM forwarder dins de la VNet
El disseny més antic executa programari DNS en una VM corrent dins de la VNet: Windows DNS, BIND o dnsmasq, amb la zona privada allotjada localment o reenviada al resolutor d'Azure a 168.63.129.16. El forwarder condicional local apunta a l'adreça privada d'aquesta VM.
Aquesta opció és familiar per als equips que ja operen servidors DNS, i pot portar lògica extra com ara registre o respostes split-horizon. També hereta tots els deures operatius d'un servidor DNS: pedaçar, una segona instància per a la disponibilitat, monitoratge i un camí de reconstrucció quan la VM se substitueix i la seva adreça canvia.
Un amfitrió corrent de VNet no és un proxy DNS fins que el servei s'instal·la i se li permet respondre a aquests clients, i aquest és el pas que la gent omet en clonar una VM.
Quin encaixa amb la vostra operació
La comparació no va de quin disseny és més ràpid. Va de si voleu operar programari DNS o no, i de si el volum de consultes justifica un recurs gestionat que factura per punt de extrem i per consulta.
| 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 |
Sigui quina sigui la fila que decideixi, la regla del forwarder local és la mateixa. Aquesta és la part que ha d'existir en tots dos dissenys, i és la part que més sovint falta quan algú informa que la resolució funciona des de dins d'Azure però no des de l'oficina.
Comproveu el camí per ordre
Confirmeu que la zona està enllaçada a la VNet que conté el resolutor, i que el forwarder local anomena l'espai de noms i no un domini pare. Un forwarder per a corp.example no coincidirà amb cloud.corp.example tret que el resolutor mateix delegui, i la discrepància produeix una resposta negativa neta que sembla un registre absent.
Després comproveu que la consulta arriba al punt de extrem: l'origen local necessita una ruta cap a l'adreça del resolutor i un camí de tornada, i tant el port 53 UDP com el TCP haurien d'estar permesos on la política ho permeti. Una NSG no pot proporcionar un registre de zona absent, i una zona correcta no pot respondre una consulta que no arriba mai.
Manteniu l'FQDN sol·licitat al costat del resolutor que heu triat quan diagnostiqueu, i separeu un temps d'espera d'una resposta negativa. Un temps d'espera és un problema de ruta o de política. Una resposta negativa vol dir que la consulta va arribar i l'espai de noms no coincidia. Ordre de treball: enllaceu la zona, afegiu el forwarder condicional, obriu el port 53 en tots dos sentits, proveu un nom des de local, i només llavors mireu l'autorització pròpia de l'aplicació.