Privatus Azure DNS per VPN: resolverio galinis taškas ar forwarder
Abu sprendimai atsako į privačias zonas per tunelį. Palyginkite valdomą įeinantį galinį tašką su forwarder VM ir tada patikrinkite kelią, kuris turi egzistuoti abiem atvejais.
Vietinio tinklo serveris pasiekia Azure VM privačiu adresu ir vis tiek negali išspręsti jo privataus pagrindinio kompiuterio vardo, todėl žmonės pradeda ieškoti sugedusio tunelio. Tunelis tvarkingas. Trūksta DNS ribos: niekas vietinėje pusėje nežino, kad į tam tikrą privačią Azure zoną turi atsakyti resolveris VNet viduje. Du sprendimai užpildo šią spragą, ir jie skiriasi tuo, ką galiausiai administruojate, o ne tuo, ar užklausos veikia.
Tunelis perduoda užklausas, o ne žinias apie zonas
Site-to-site ryšys suteikia paketams maršrutą tarp dviejų tinklų. Jis nepasako vietiniam DNS serveriui, kuri vardų erdvė priklauso Azure ar kuris adresas turi atsakyti, todėl užklausa arba išeina į internetą ir grįžta tuščia, arba niekada nepalieka vietinio resolverio.
Pataisymas turi dvi lengvai atskiriamas dalis. Viena dalis yra resolveris VNet viduje, priimantis užklausas, ateinančias per tunelį. Kita yra sąlyginis forwarder vietinėje pusėje, siunčiantis tiksliai vieną vardų erdvę tam resolveriui. Nė viena dalis neveikia viena.
Tarkime, kad zona yra cloud.corp.example likusioje šio aprašymo dalyje, o kiekvieną adresą laikykite iliustraciniu.
Variantas A: valdomas įeinantis galinis taškas
Azure DNS Private Resolver teikia įeinantį galinį tašką, priimantį DNS užklausas iš už VNet ribų. Jį diegiate atskirame deleguotame potinklyje, susiejate privačią zoną su tuo VNet ir užsirašote įeinantį adresą, kurį priskiria paslauga.
Tada vietiniame DNS serveryje sukuriate sąlyginį forwarder tiksliam vardų erdvei link to adreso:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft hibridinio DNS procedūra dokumentuoja ir zonos susiejimą, ir forwarder žingsnį. Valdomas kelias nepalieka jokios DNS programinės įrangos, kurią reikėtų lopyti, o galinio taško adresas išlieka stabilus per visą ištekliaus gyvavimo laiką.
Kaina ta, kad dabar turite resolverio išteklių, jo potinklio delegavimą ir jo sąnaudas, kurios yra realios net kai užklausų apimtis labai maža.
Variantas B: forwarder VM VNet viduje
Senesnis sprendimas paleidžia DNS programinę įrangą įprastoje VM VNet viduje: Windows DNS, BIND arba dnsmasq, o privačioji zona arba talpinama vietiškai, arba persiunčiama Azure resolveriui adresu 168.63.129.16. Vietinis sąlyginis forwarder nukreiptas į tos VM privatų adresą.
Šis variantas pažįstamas komandoms, kurios jau valdo DNS serverius, ir gali nešti papildomą logiką, pavyzdžiui, žurnalų rašymą ar split-horizon atsakymus. Jis taip pat paveldi visas DNS serverio operacines pareigas: lopymą, antrą egzempliorių prieinamumui, stebėjimą ir atkūrimo kelią, kai VM pakeičiama ir jos adresas pasikeičia.
Įprastas VNet hostas nėra DNS tarpinis serveris, kol paslauga neįdiegta ir neturi leidimo atsakyti tiems klientams, ir būtent šį žingsnį žmonės praleidžia klonuodami VM.
Kuris tinka jūsų veiklai
Palyginimas ne apie tai, kuris sprendimas greitesnis. Jis apie tai, ar apskritai norite valdyti DNS programinę įrangą, ir ar užklausų apimtis pateisina valdomą išteklių, už kurį atsiskaitoma pagal galinį tašką ir pagal užklausą.
| 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 |
Kuri eilutė bebūtų lemiama, vietinio forwarder taisyklė atrodo taip pat. Būtent ši dalis turi egzistuoti abiejuose sprendimuose, ir būtent jos dažniausiai trūksta, kai kas nors praneša, kad sprendimas veikia iš Azure vidaus, bet ne iš biuro.
Patikrinkite kelią iš eilės
Patvirtinkite, kad zona susieta su VNet, kurioje yra resolveris, ir kad vietinis forwarder nurodo vardų erdvę, o ne pirminį domeną. Corp.example forwarderis nesutaps su cloud.corp.example, nebent pats resolveris deleguotų, o šis neatitikimas duoda švarų neigiamą atsakymą, kuris atrodo kaip trūkstamas įrašas.
Tada patikrinkite, ar užklausa pasiekia galinį tašką: vietiniam šaltiniui reikia maršruto į resolverio adresą ir grįžimo kelio, o 53 prievadas turėtų būti leidžiamas tiek UDP, tiek TCP ten, kur politika tai leidžia. NSG negali pateikti trūkstamo zonos įrašo, o teisinga zona negali atsakyti į užklausą, kuri niekada neatvyksta.
Diagnozuodami laikykite prašomą FQDN šalia pasirinkto resolverio ir atskirkite skirtąjį laiką nuo neigiamo atsakymo. Skirtasis laikas yra maršruto ar politikos problema. Neigiamas atsakymas reiškia, kad užklausa atvyko, o vardų erdvė nesutapo. Darbo tvarka: susiekite zoną, pridėkite sąlyginį forwarder, atidarykite 53 prievadą abiem kryptimis, išbandykite vieną vardą iš vietinės pusės ir tik tada žiūrėkite į pačios programos autorizaciją.