Privat DNS i Azure over VPN: resolver-endepunkt eller forwarder
Begge designene besvarer private soner over tunnelen. Sammenlign et administrert inngående endepunkt med en forwarder-VM, og kontroller deretter veien som må finnes i begge tilfeller.
En server på stedet når en Azure-VM på en privat adresse og kan fortsatt ikke slå opp det private vertsnavnet, noe som får folk til å lete etter en ødelagt tunnel. Tunnelen er i orden. Det som mangler er en DNS-grense: ingenting på den lokale siden vet at en bestemt privat Azure-sone skal besvares av en resolver inne i VNet. To design lukker gapet, og de skiller seg i hva du ender med å drifte, ikke i om spørringene virker.
Tunnelen bærer spørringer, ikke sonekunnskap
En site-til-site-forbindelse gir pakkene en rute mellom de to nettene. Den forteller ikke den lokale DNS-serveren hvilket navnerom som tilhører Azure eller hvilken adresse som skal svare, så spørringen går enten ut på internett og kommer tom tilbake, eller forlater aldri den lokale resolveren.
Rettingen har to halvdeler som er lette å skille. Den ene halvdelen er en resolver inne i VNet som tar imot spørringer som kommer over tunnelen. Den andre er en betinget forwarder på den lokale siden som sender nøyaktig ett navnerom til den resolveren. Ingen av halvdelene virker alene.
Anta at sonen er cloud.corp.example resten av denne gjennomgangen, og behandle hver adresse som illustrativ.
Alternativ A: det administrerte inngående endepunktet
Azure DNS Private Resolver tilbyr et inngående endepunkt som tar imot DNS-spørringer fra utsiden av VNet. Du distribuerer det i et dedikert delegert subnett, kobler den private sonen til det VNet-et og noterer den inngående adressen tjenesten tildeler.
På den lokale DNS-serveren oppretter du deretter en betinget forwarder for det nøyaktige navnerommet mot den adressen:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsofts hybride DNS-prosedyre dokumenterer både sonekoblingen og forwarder-trinnet. Den administrerte veien etterlater ingen DNS-programvare å patche, og endepunktadressen holder seg stabil gjennom hele ressursens levetid.
Prisen er at du nå eier en resolver-ressurs, subnettdelegeringen og kostnaden, som er reell selv når spørringsvolumet er bittelite.
Alternativ B: en forwarder-VM inne i VNet
Det eldre designet kjører DNS-programvare på en vanlig VM i VNet: Windows DNS, BIND eller dnsmasq, med den private sonen enten hostet lokalt eller videresendt til Azure-resolveren på 168.63.129.16. Den lokale betingede forwarderen peker på VM-ens private adresse.
Dette alternativet er kjent for team som allerede drifter DNS-servere, og det kan bære ekstra logikk som logging eller split-horizon-svar. Det arver også enhver driftsplikt en DNS-server har: patching, en andre instans for tilgjengelighet, overvåking og en gjenoppbyggingsvei når VM-en erstattes og adressen endres.
En vanlig VNet-vert er ikke en DNS-proxy før tjenesten er installert og har tillatelse til å svare de klientene, og det er trinnet folk hopper over når de kloner en VM.
Hvilken passer driften din
Sammenligningen handler ikke om hvilket design som er raskest. Den handler om hvorvidt du vil drifte DNS-programvare i det hele tatt, og om spørringsvolumet rettferdiggjør en administrert ressurs som faktureres per endepunkt og per spørring.
| 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 |
Uansett hvilken rad som avgjør, ser forwarder-regelen lokal lik ut. Det er den delen som må finnes i begge design, og det er den delen som oftest mangler når noen rapporterer at oppslag virker fra Azure, men ikke fra kontoret.
Kontroller veien i rekkefølge
Bekreft at sonen er koblet til VNet-et som holder resolveren, og at den lokale forwarderen navngir navnerommet og ikke et overordnet domene. En forwarder for corp.example vil ikke matche cloud.corp.example med mindre resolveren selv delegerer, og avviket gir et rent negativt svar som ser ut som en manglende oppføring.
Kontroller deretter at spørringen når endepunktet: den lokale kilden trenger en rute til resolver-adressen og en returvei, og både UDP- og TCP-port 53 bør være tillatt der policyen tillater det. En NSG kan ikke skaffe en manglende soneoppføring, og en korrekt sone kan ikke svare på en spørring som aldri kommer.
Hold det etterspurte FQDN-et ved siden av resolveren du valgte når du diagnostiserer, og skille en timeout fra et negativt svar. En timeout er et rute- eller policyproblem. Et negativt svar betyr at spørringen kom og navnerommet ikke passet. Arbeidsrekkefølge: koble sonen, legg til den betingede forwarderen, åpne port 53 begge veier, test ett navn fra det lokale nettet, og se først deretter på applikasjonens egen autorisasjon.