DNS privado de Azure sobre VPN: punto de extremo do resolutor ou forwarder
Os dous deseños responden zonas privadas polo túnel. Compare un punto de extremo de entrada xestionado cunha VM forwarder e despois revise a ruta que debe existir en calquera caso.
Un servidor local chega a unha VM de Azure por enderezo privado e aínda así non pode resolver o seu nome de host privado, o que leva a xente a buscar un túnel roto. O túnel está ben. O que falta é unha fronteira de DNS: nada no lado local sabe que unha zona privada concreta de Azure debe ser respondida por un resolutor dentro da VNet. Dous deseños pechan esa fenda, e difiren no que acabas operando, non en se as consultas funcionan.
O túnel transporta consultas, non coñecemento de zonas
Unha conexión de sitio a sitio dá aos paquetes unha ruta entre as dúas redes. Non lle di ao servidor DNS local que espazo de nomes pertence a Azure nin que enderezo debe responder, así que a consulta ou vai a Internet e volve baleira ou nunca sae do resolutor local.
A solución ten dúas metades fáciles de separar. Unha metade é un resolutor dentro da VNet que acepta consultas que chegan polo túnel. A outra é un forwarder condicional no lado local que envía exactamente un espazo de nomes a ese resolutor. Ningunha metade funciona soa.
Supón que a zona é cloud.corp.example durante o resto deste percorrido, e trata cada enderezo como ilustrativo.
Opción A: o punto de extremo de entrada xestionado
Azure DNS Private Resolver ofrece un punto de extremo de entrada que acepta consultas DNS desde fóra da VNet. Desprégase nunha subrede delegada dedicada, vincula a zona privada a esa VNet e anota o enderezo de entrada que asigna o servizo.
No servidor DNS local creas entón un forwarder condicional para o espazo de nomes exacto cara a ese enderezo:
Namespace: cloud.corp.example
Forward to: 10.20.2.4O procedemento de DNS híbrido de Microsoft documenta tanto o vínculo da zona como o paso do forwarder. A ruta xestionada déixache sen software DNS que parchear, e o enderezo do punto de extremo mantense estable durante toda a vida do recurso.
O prezo é que agora posúes un recurso de resolutor, a súa delegación de subrede e o seu custo, que é real mesmo cando o volume de consultas é mínimo.
Opción B: unha VM forwarder dentro da VNet
O deseño máis antigo executa software DNS nunha VM corrente dentro da VNet: Windows DNS, BIND ou dnsmasq, coa zona privada aloxada localmente ou reenviada ao resolutor de Azure en 168.63.129.16. O forwarder condicional local apunta ao enderezo privado desa VM.
Esta opción é familiar para os equipos que xa operan servidores DNS, e pode levar lóxica extra como rexistro ou respostas split-horizon. Tamén herda todos os deberes operativos dun servidor DNS: parchear, unha segunda instancia para a dispoñibilidade, monitorización e unha ruta de reconstrución cando a VM se substitúe e o seu enderezo cambia.
Un host corrente de VNet non é un proxy DNS ata que o servizo está instalado e se lle permite responder a eses clientes, e ese é o paso que a xente se salta ao clonar unha VM.
Cal encaixa coa túa operación
A comparación non vai de que deseño é máis rápido. Vai de se queres operar software DNS ou non, e de se o volume de consultas xustifica un recurso xestionado que factura por punto de extremo e por 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 |
Sexa cal sexa a fila que o decida, a regra do forwarder local é a mesma. Esa é a parte que debe existir en ambos deseños, e é a que máis a miúdo falta cando alguén informa de que a resolución funciona desde dentro de Azure pero non desde a oficina.
Comproba a ruta por orde
Confirma que a zona está vinculada á VNet que contén o resolutor e que o forwarder local nomea o espazo de nomes e non un dominio pai. Un forwarder para corp.example non coincidirá con cloud.corp.example a menos que o propio resolutor delegue, e a discrepancia produce unha resposta negativa limpa que parece un rexistro ausente.
Despois comproba que a consulta chega ao punto de extremo: a orixe local necesita unha ruta cara ao enderezo do resolutor e unha ruta de volta, e tanto o porto 53 UDP como o TCP deberían estar permitidos onde a política o permita. Un NSG non pode fornecer un rexistro de zona ausente, e unha zona correcta non pode responder a unha consulta que nunca chega.
Mantén o FQDN solicitado xunto ao resolutor que escolliches cando diagnostiques, e separa un tempo de espera dunha resposta negativa. Un tempo de espera é un problema de ruta ou de política. Unha resposta negativa significa que a consulta chegou e o espazo de nomes non coincidía. Orde de traballo: vincula a zona, engade o forwarder condicional, abre o porto 53 en ambos sentidos, proba un nome desde local e só entón mira a autorización propia da aplicación.