Azure'i privaatne DNS VPN-i kaudu: resolveri lõpp-punkt või forwarder
Mõlemad lahendused vastavad privaatsetele tsoonidele tunnelit mööda. Võrrelge hallatavat sissetulevat lõpp-punkti forwarder-VM-iga ja kontrollige seejärel teed, mis peab mõlemal juhul olemas olema.
Kohaliku võrgu server jõuab Azure'i VM-ini privaatse aadressi kaudu ja ei suuda ikkagi selle privaatset hostinime lahendada, mis paneb inimesi otsima katkist tunnelit. Tunnel on korras. Puudu on DNS-i piir: kohalikul poolel ei tea keegi, et teatud Azure'i privaatsele tsoonile peab vastama resolver VNeti sees. Kaks lahendust seda lünka täidavad ja need erinevad selle poolest, mida te lõpuks haldad, mitte selle poolest, kas päringud töötavad.
Tunnel kannab päringuid, mitte teadmisi tsoonidest
Site-to-site ühendus annab pakettidele marsruudi kahe võrgu vahel. See ei ütle kohalikule DNS-serverile, milline nimeruum kuulub Azure'ile või milline aadress peaks vastama, seega päring kas läheb internetti ja tuleb tühjalt tagasi või ei lahku kunagi kohalikust resolverist.
Parandusel on kaks poolt, mida on lihtne eraldada. Üks pool on resolver VNeti sees, mis võtab vastu tunnelist saabuvaid päringuid. Teine on tingimuslik forwarder kohalikul poolel, mis saadab täpselt ühe nimeruumi sellele resolverile. Kumbki pool üksi ei tööta.
Eeldage ülejäänud kirjelduse jaoks, et tsoon on cloud.corp.example, ja käsitlege iga aadressi näitlikuna.
Valik A: hallatav sissetulev lõpp-punkt
Azure DNS Private Resolver pakub sissetulevat lõpp-punkti, mis võtab vastu DNS-i päringuid väljastpoolt VNeti. Te paigutate selle spetsiaalsesse delegeeritud alamvõrku, linkite privaatse tsooni selle VNetiga ja märgite üles sissetuleva aadressi, mille teenus määrab.
Seejärel loote kohalikus DNS-serveris tingimusliku forwarderi täpse nimeruumi jaoks selle aadressi suunas:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsofti hübriid-DNS-i protseduur dokumenteerib nii tsooni lingi kui ka forwarderi sammu. Hallatav tee ei jäta teile ühtegi DNS-tarkvara, mida paigata, ja lõpp-punkti aadress püsib kogu ressursi eluea jooksul stabiilsena.
Hind on see, et teil on nüüd resolveri ressurss, selle alamvõrgu delegeerimine ja selle kulu, mis on reaalne ka siis, kui päringute maht on tilluke.
Valik B: forwarder-VM VNeti sees
Vanim lahendus käitab DNS-tarkvara VNeti tavalises VM-is: Windows DNS, BIND või dnsmasq, kusjuures privaatne tsoon on kas lokaalselt majutatud või suunatud Azure'i resolverile aadressil 168.63.129.16. Kohalik tingimuslik forwarder osutab selle VM-i privaatsele aadressile.
See valik on tuttav meeskondadele, kes juba DNS-servereid käitavad, ja see võib kanda lisaloogikat, näiteks logimist või split-horizon vastuseid. See pärib ka DNS-serveri kõik operatiivsed kohustused: paikamine, teine instants kättesaadavuse jaoks, monitooring ja ülesehitamise tee, kui VM välja vahetatakse ja selle aadress muutub.
Tavaline VNeti host ei ole DNS-proxy enne, kui teenus on paigaldatud ja tal on lubatud neile klientidele vastata, ja just selle sammu jätavad inimesed VM-i kloonimisel vahele.
Milline sobib teie töökorraldusele
Võrdlus ei käi selle kohta, milline lahendus on kiirem. See käib selle kohta, kas te üldse tahate DNS-tarkvara käitada ja kas päringute maht õigustab hallatavat ressurssi, mille eest arveldatakse lõpp-punkti ja päringu kaupa.
| 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 |
Ükskõik milline rida otsustab, kohalik forwarderi reegel näeb välja sama. Just see osa peab mõlemas lahenduses olemas olema ja just see jääb kõige sagedamini puudu, kui keegi teatab, et lahendamine töötab Azure'i seest, aga mitte kontorist.
Kontrollige teed järjekorras
Veenduge, et tsoon on lingitud VNetiga, mis hoiab resolverit, ja et kohalik forwarder nimetab nimeruumi, mitte ülemdomeeni. corp.example'i forwarder ei sobi cloud.corp.example'iga, kui resolver ise ei delegeeri, ja see mittevastavus annab puhta eitava vastuse, mis näeb välja nagu puuduv kirje.
Seejärel kontrollige, et päring jõuab lõpp-punkti: kohalikul allikal on vaja marsruuti resolveri aadressile ja tagasiteed ning port 53 peaks olema lubatud nii UDP kui ka TCP jaoks seal, kus poliitika seda lubab. NSG ei saa pakkuda puuduvat tsoonikirjet ja õige tsoon ei saa vastata päringule, mis kunagi ei saabu.
Hoidke nõutud FQDN valitud resolveri kõrval, kui diagnoosite, ja eraldatage aegumine eitavast vastusest. Aegumine on tee või poliitika probleem. Eitav vastus tähendab, et päring saabus ja nimeruum ei sobinud. Töö järjekord: linkige tsoon, lisage tingimuslik forwarder, avage port 53 mõlemas suunas, testige ühte nime kohalikust võrgust ja alles siis vaadake rakenduse enda autoriseerimist.