Privātais Azure DNS pār VPN: resolvera galapunkts vai forwarder
Abi risinājumi atbild uz privātajām zonām caur tuneli. Salīdziniet pārvaldīto ienākošo galapunktu ar forwarder VM un pēc tam pārbaudiet ceļu, kuram jābūt abos gadījumos.
Serveris lokālajā tīklā sasniedz Azure VM pēc privātas adreses un tomēr nevar atrisināt tā privāto resursdatora nosaukumu, kas liek cilvēkiem meklēt salauztu tuneli. Tunelis ir kārtībā. Trūkst DNS robežas: nekas lokālajā pusē nezina, ka uz noteiktu privāto Azure zonu jāatbild resolverim VNet iekšienē. Divi risinājumi aizpilda šo plaisu, un tie atšķiras ar to, ko galu galā pārvaldāt, nevis ar to, vai vaicājumi strādā.
Tunelis pārvadā vaicājumus, nevis zināšanas par zonām
Vietnes uz vietni savienojums dod paketēm maršrutu starp diviem tīkliem. Tas nepasaka lokālajam DNS serverim, kura nosaukumtelpa pieder Azure vai kura adrese atbildēs, tāpēc vaicājums vai nu aiziet uz internetu un atgriežas tukšs, vai nekad neiziet no lokālā resolvera.
Labojumam ir divas viegli atdalāmas puses. Viena puse ir resolveris VNet iekšienē, kas pieņem vaicājumus, kuri nāk pa tuneli. Otra ir nosacīts forwarder lokālajā pusē, kas sūta tieši vienu nosaukumtelpu tam resolverim. Neviena puse nestrādā viena pati.
Pieņemsim, ka zona ir cloud.corp.example pārējā šī apraksta daļā, un uzskatiet katru adresi par ilustratīvu.
A variants: pārvaldītais ienākošais galapunkts
Azure DNS Private Resolver nodrošina ienākošo galapunktu, kas pieņem DNS vaicājumus no ārpuses VNet. Jūs izvietojat to īpašā deleģētā apakštīklā, saistāt privāto zonu ar šo VNet un pierakstāt ienākošo adresi, ko piešķir pakalpojums.
Pēc tam lokālajā DNS serverī izveidojat nosacītu forwarder precīzai nosaukumtelpai uz šo adresi:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft hibrīdā DNS procedūra dokumentē gan zonas saistīšanu, gan forwarder soli. Pārvaldītais ceļš neatstāj nekādu DNS programmatūru, kas jālāpa, un galapunkta adrese paliek stabila visā resursa darbmūžā.
Cena ir tā, ka jums tagad pieder resolvera resurs, tā apakštīkla deleģējums un izmaksas, kas ir reālas arī tad, ja vaicājumu apjoms ir niecīgs.
B variants: forwarder VM VNet iekšienē
Vecākais risinājums darbina DNS programmatūru parastā VM VNet iekšienē: Windows DNS, BIND vai dnsmasq, un privātā zona ir vai nu mitināta lokāli, vai pārsūtīta uz Azure resolveri adresē 168.63.129.16. Lokālais nosacītais forwarder norāda uz šīs VM privāto adresi.
Šis variants ir pazīstams komandām, kas jau pārvalda DNS serverus, un tas var nest papildu loģiku, piemēram, žurnālu rakstīšanu vai split-horizon atbildes. Tas arī manto visus DNS servera ekspluatācijas pienākumus: lāpīšanu, otru instanci pieejamībai, uzraudzību un atjaunošanas ceļu, kad VM tiek nomainīts un tā adrese mainās.
Parasts VNet resursdators nav DNS starpniekserveris, kamēr pakalpojums nav instalēts un tam nav atļauts atbildēt šiem klientiem, un tieši šo soli cilvēki izlaiž, klonējot VM.
Kurš atbilst jūsu darbībai
Salīdzinājums nav par to, kurš risinājums ir ātrāks. Tas ir par to, vai jūs vispār gribat pārvaldīt DNS programmatūru, un vai vaicājumu apjoms attaisno pārvaldītu resursu, par kuru maksā pēc galapunkta un pēc vaicājuma.
| 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 |
Lai kura rinda izšķirtu, lokālā forwarder noteikums izskatās tāpat. Tieši šai daļai ir jābūt abos risinājumos, un tieši tās visbiežāk trūkst, kad kāds ziņo, ka atrisināšana strādā no Azure iekšienes, bet ne no biroja.
Pārbaudiet ceļu secībā
Pārliecinieties, ka zona ir saistīta ar VNet, kurā ir resolveris, un ka lokālais forwarder nosauc nosaukumtelpu, nevis vecākdomēnu. Forwarder korporatīvajai corp.example nesaskanēs ar cloud.corp.example, ja vien resolveris pats neveic deleģēšanu, un šī neatbilstība rada tīru noraidošu atbildi, kas izskatās kā trūkstošs ieraksts.
Pēc tam pārbaudiet, vai vaicājums sasniedz galapunktu: lokālajam avotam vajag maršrutu uz resolvera adresi un atgriešanās ceļu, un 53. ports jāatļauj gan UDP, gan TCP tur, kur politika to pieļauj. NSG nevar nodrošināt trūkstošu zonas ierakstu, un pareiza zona nevar atbildēt uz vaicājumu, kas nekad neierodas.
Diagnosticējot turiet pieprasīto FQDN blakus izvēlētajam resolverim, un atdaliet taimautu no noraidošas atbildes. Taimauts ir ceļa vai politikas problēma. Noraidoša atbilde nozīmē, ka vaicājums ieradās un nosaukumtelpa nesakrita. Darbu secība: saistiet zonu, pievienojiet nosacīto forwarder, atveriet 53. portu abos virzienos, pārbaudiet vienu nosaukumu no lokālās puses un tikai tad skatiet pašas lietojumprogrammas autorizāciju.