Zasebni DNS v Azure prek VPN: končna točka resolverja ali forwarder
Obe zasnovi odgovarjata na zasebna območja prek tunela. Primerjajte upravljano vhodno končno točko z VM forwarderja, nato preverite pot, ki mora obstajati v obeh primerih.
Strežnik v lokalnem omrežju doseže VM Azure prek zasebnega naslova in še vedno ne more razrešiti njenega zasebnega imena gostitelja, zaradi česar ljudje iščejo pokvarjen tunel. Tunel je v redu. Manjka meja DNS: nič na lokalni strani ne ve, da mora na določeno zasebno območje Azure odgovoriti resolver znotraj VNet. Dve zasnovi zapolnita to vrzel in se razlikujeta po tem, kaj na koncu upravljate, ne po tem, ali poizvedbe delujejo.
Tunel prenaša poizvedbe, ne znanja o območjih
Povezava med lokacijama daje paketom pot med dvema omrežjema. Ne pove lokalnemu strežniku DNS, kateri imenski prostor pripada Azureu ali kateri naslov naj odgovori, zato poizvedba bodisi odide v internet in se vrne prazna, bodisi nikoli ne zapusti lokalnega resolverja.
Popravek ima dve zlahka ločljivi polovici. Ena polovica je resolver znotraj VNet, ki sprejema poizvedbe, ki prihajajo po tunelu. Druga je pogojni forwarder na lokalni strani, ki pošlje točno en imenski prostor temu resolverju. Nobena polovica ne deluje sama.
Za preostanek te razlage predpostavimo, da je območje cloud.corp.example, in vsak naslov obravnavajmo kot ponazoritev.
Možnost A: upravljana vhodna končna točka
Azure DNS Private Resolver ponuja vhodno končno točko, ki sprejema poizvedbe DNS od zunaj VNet. Namestite jo v namensko delegirano podomrežje, povežete zasebno območje s to VNet in zabeležite vhodni naslov, ki ga dodeli storitev.
Na lokalnem strežniku DNS nato ustvarite pogojni forwarder za točen imenski prostor proti temu naslovu:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoftov postopek hibridnega DNS dokumentira tako povezavo območja kot korak forwarderja. Upravljana pot ne pušča nobene programske opreme DNS za popravljanje, naslov končne točke pa ostane stabilen vso življenjsko dobo vira.
Cena je, da zdaj imate vir resolverja, njegovo delegacijo podomrežja in njegove stroške, ki so resnični tudi pri zelo majhnem obsegu poizvedb.
Možnost B: VM s forwarderjem znotraj VNet
Starejša zasnova poganja programsko opremo DNS na običajni VM v VNet: Windows DNS, BIND ali dnsmasq, pri čemer je zasebno območje gostovano lokalno ali posredovano resolverju Azure na 168.63.129.16. Lokalni pogojni forwarder kaže na zasebni naslov te VM.
Ta možnost je znana ekipam, ki že upravljajo strežnike DNS, in lahko nosi dodatno logiko, na primer beleženje ali odgovore split-horizon. Podeduje tudi vse operativne dolžnosti strežnika DNS: popravke, drugo instanco za razpoložljivost, spremljanje in pot ponovne gradnje, ko se VM zamenja in se njen naslov spremeni.
Običajni gostitelj VNet ni proxy DNS, dokler storitev ni nameščena in ji ni dovoljeno odgovarjati tem odjemalcem, in prav ta korak ljudje izpustijo pri kloniranju VM.
Katera ustreza vašemu delovanju
Primerjava ni o tem, katera zasnova je hitrejša. Je o tem, ali sploh želite upravljati programsko opremo DNS in ali obseg poizvedb upravičuje upravljani vir, ki se obračunava po končni točki in po poizvedbi.
| 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 |
Katera koli vrstica odloči, pravilo forwarderja na lokalni strani je enako. To je del, ki mora obstajati v obeh zasnovah, in to je del, ki najpogosteje manjka, ko nekdo poroča, da razreševanje deluje znotraj Azurea, ne pa iz pisarne.
Preverite pot po vrsti
Potrdite, da je območje povezano z VNet, ki vsebuje resolver, in da lokalni forwarder navaja imenski prostor in ne nadrejene domene. Forwarder za corp.example se ne bo ujemal s cloud.corp.example, razen če resolver sam delegira, in neujemanje ustvari čist negativen odgovor, ki je videti kot manjkajoč zapis.
Nato preverite, ali poizvedba doseže končno točko: lokalni vir potrebuje pot do naslova resolverja in povratno pot, vrata 53 pa morajo biti dovoljena za UDP in TCP tam, kjer to dovoljuje politika. NSG ne more zagotoviti manjkajočega zapisa območja, pravilno območje pa ne more odgovoriti na poizvedbo, ki nikoli ne prispe.
Pri diagnosticiranju imejte zahtevani FQDN ob izbranem resolverju in ločite potek časa od negativnega odgovora. Potek časa je težava poti ali politike. Negativen odgovor pomeni, da je poizvedba prispela in se imenski prostor ni ujemal. Vrstni red dela: povežite območje, dodajte pogojni forwarder, odprite vrata 53 v obe smeri, preizkusite eno ime iz lokalnega omrežja in šele nato poglejte lastno avtorizacijo aplikacije.