Privata DNS en Azure tra VPN: solvila finpunkto aŭ plusendilo
Ambaŭ dezajnoj respondas privatajn zonojn tra la tunelo. Komparu administratajn envenan finpunkton kun plusendila VM, poste kontrolu la vojon, kiu devas ekzisti en ĉiu kazo.
Servilo en la loka reto atingas Azure-VM per privata adreso kaj tamen ne povas solvi ĝian privatan gastigantnomon, kio igas homojn serĉi rompitan tunelon. La tunelo estas en ordo. Mankas DNS-limo: nenio sur la loka flanko scias, ke difinita privata zono de Azure devas esti respondata de solvilo ene de la VNet. Du dezajnoj fermas tiun breĉon, kaj ili diferencas en tio, kion vi fine funkciigas, ne en tio, ĉu petoj funkcias.
La tunelo portas petojn, ne sciojn pri zonoj
Sitio-al-sitio-konekto donas al pakaĵoj itineron inter la du retoj. Ĝi ne diras al la loka DNS-servilo, kiu nomspaco apartenas al Azure aŭ kiu adreso devas respondi, do la peto aŭ iras al la interreto kaj revenas malplena, aŭ neniam forlasas la lokan solvilon.
La korekto havas du duonojn, kiujn oni facile apartigas. Unu duono estas solvilo ene de la VNet, kiu akceptas petojn alvenantajn tra la tunelo. La alia estas kondiĉa plusendilo sur la loka flanko, kiu sendas precize unu nomspacon al tiu solvilo. Neniu duono funkcias sola.
Supozu, ke la zono estas cloud.corp.example por la resto de ĉi tiu priskribo, kaj traktu ĉiun adreson kiel ilustran.
Opcio A: la administrata envena finpunkto
Azure DNS Private Resolver provizas envenan finpunkton, kiu akceptas DNS-petojn de ekster la VNet. Vi deplojas ĝin en dediĉita delegita subreto, ligas la privatan zonon al tiu VNet kaj notas la envenan adreson, kiun la servo asignas.
Sur la loka DNS-servilo vi poste kreas kondiĉan plusendilon por la preciza nomspaco al tiu adreso:
Namespace: cloud.corp.example
Forward to: 10.20.2.4La proceduro pri hibrida DNS de Microsoft dokumentas kaj la zonligon kaj la plusendilan paŝon. La administrata vojo lasas vin sen DNS-programaro por fliki, kaj la finpunkta adreso restas stabila dum la tuta vivo de la rimedo.
La prezo estas, ke vi nun posedas solvilan rimedon, ĝian subretan delegadon kaj ĝian koston, kiu estas reala eĉ kiam la peta volumeno estas malgrandega.
Opcio B: plusendila VM ene de la VNet
La pli malnova dezajno rulas DNS-programaron sur ordinara VM en la VNet: Windows DNS, BIND aŭ dnsmasq, kun la privata zono aŭ gastigata loke aŭ plusendata al la Azure-solvilo ĉe 168.63.129.16. La loka kondiĉa plusendilo montras al la privata adreso de tiu VM.
Ĉi tiu opcio estas konata al teamoj, kiuj jam funkciigas DNS-servilojn, kaj ĝi povas porti kroman logikon kiel protokoladon aŭ split-horizon-respondojn. Ĝi ankaŭ heredas ĉiun operacian devon de DNS-servilo: flikado, dua instanco por havebleco, monitorado kaj rekonstrua vojo kiam la VM estas anstataŭigata kaj ĝia adreso ŝanĝiĝas.
Ordinara VNet-gastiganto ne estas DNS-prokurilo ĝis la servo estas instalita kaj rajtas respondi al tiuj klientoj, kaj tio estas la paŝo, kiun homoj preterlasas kiam ili klonas VM.
Kiu taŭgas por via operacio
La komparo ne temas pri tio, kiu dezajno estas pli rapida. Ĝi temas pri tio, ĉu vi entute volas funkciigi DNS-programaron, kaj ĉu la peta volumeno pravigas administrata rimedon, kiu fakturas laŭ finpunkto kaj laŭ peto.
| 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 |
Kiu ajn vico decidas, la plusendila regulo loke aspektas same. Tio estas la parto, kiu devas ekzisti en ambaŭ dezajnoj, kaj ĝi estas la parto plej ofte mankanta kiam iu raportas, ke solvado funkcias de ene de Azure sed ne de la oficejo.
Kontrolu la vojon laŭorde
Konfirmu, ke la zono estas ligita al la VNet, kiu tenas la solvilon, kaj ke la loka plusendilo nomas la nomspacon anstataŭ gepatro-domajnon. Plusendilo por corp.example ne kongruos kun cloud.corp.example krom se la solvilo mem delegas, kaj la malkongruo produktas puran negativan respondon, kiu aspektas kiel mankanta rikordo.
Poste kontrolu, ke la peto atingas la finpunkton: la loka fonto bezonas itineron al la solvila adreso kaj revenan vojon, kaj kaj UDP kaj TCP pordo 53 devus esti permesataj kie la politiko permesas. NSG ne povas provizi mankantan zonrikordon, kaj ĝusta zono ne povas respondi peton, kiu neniam alvenas.
Tenu la petitan FQDN apud la solvilo, kiun vi elektis, kiam vi diagnozas, kaj apartigu tempolimon de negativa respondo. Tempolimo estas voja aŭ politika problemo. Negativa respondo signifas, ke la peto alvenis kaj la nomspaco ne kongruis. Ordo de laboro: ligu la zonon, aldonu la kondiĉan plusendilon, malfermu pordon 53 en ambaŭ direktojn, testu unu nomon de loke, kaj nur poste rigardu la propran rajtigon de la aplikaĵo.