DNS privat Azure prin VPN: punct final de resolver sau forwarder

Un server din rețeaua locală ajunge la o VM Azure printr-o adresă privată și tot nu poate rezolva numele de gazdă privat, ceea ce îi face pe oameni să caute un tunel stricat. Tunelul este în regulă. Lipsește o graniță DNS: nimic de partea locală nu știe că o anumită zonă privată Azure trebuie să primească răspuns de la un resolver din interiorul VNet. Două proiecte acoperă acest gol și diferă prin ceea ce administrezi în final, nu prin dacă interogările funcționează.

Tunelul transportă interogări, nu cunoașterea zonelor

O conexiune site-to-site oferă pachetelor o rută între cele două rețele. Nu îi spune serverului DNS local ce spațiu de nume aparține Azure sau ce adresă ar trebui să răspundă, așa că interogarea fie merge în internet și se întoarce goală, fie nu părăsește niciodată resolverul local.

Remedierea are două jumătăți ușor de separat. O jumătate este un resolver în interiorul VNet care acceptă interogări venite prin tunel. Cealaltă este un forwarder condiționat de partea locală care trimite exact un spațiu de nume către acel resolver. Niciuna dintre jumătăți nu funcționează singură.

Presupunem că zona este cloud.corp.example pentru restul acestei explicații și tratăm fiecare adresă ca ilustrativă.

Opțiunea A: punctul final de intrare administrat

Azure DNS Private Resolver oferă un punct final de intrare care acceptă interogări DNS din afara VNet. Îl implementezi într-o subrețea delegată dedicată, legi zona privată de acea VNet și notezi adresa de intrare pe care o atribuie serviciul.

Pe serverul DNS local creezi apoi un forwarder condiționat pentru spațiul de nume exact către acea adresă:

Namespace: cloud.corp.example
Forward to: 10.20.2.4

Procedura DNS hibrid de la Microsoft documentează atât legarea zonei, cât și pasul de forwarder. Calea administrată nu lasă niciun software DNS de corectat, iar adresa punctului final rămâne stabilă pe toată durata de viață a resursei.

Prețul este că acum deții o resursă de resolver, delegarea subrețelei ei și costul ei, care este real chiar și când volumul interogărilor este minuscul.

Opțiunea B: o VM forwarder în interiorul VNet

Proiectul mai vechi rulează software DNS pe o VM obișnuită din VNet: Windows DNS, BIND sau dnsmasq, cu zona privată găzduită local sau redirecționată către resolverul Azure de la 168.63.129.16. Forwarderul condiționat local indică adresa privată a acelei VM.

Această opțiune este cunoscută echipelor care deja administrează servere DNS și poate transporta logică suplimentară precum jurnalizare sau răspunsuri split-horizon. Moștenește și fiecare obligație operațională a unui server DNS: corecturi, o a doua instanță pentru disponibilitate, monitorizare și o cale de reconstrucție când VM-ul este înlocuit și adresa i se schimbă.

O gazdă VNet obișnuită nu este proxy DNS până când serviciul nu este instalat și i se permite să răspundă acelor clienți, iar acesta este pasul pe care oamenii îl sar atunci când clonează o VM.

Care se potrivește operațiunii tale

Comparația nu este despre care proiect este mai rapid. Este despre dacă vrei să administrezi deloc software DNS și dacă volumul interogărilor justifică o resursă administrată facturată pe punct final și pe interogare.

Indiferent care rând decide, regula forwarderului local arată la fel. Aceasta este partea care trebuie să existe în ambele proiecte și este partea care lipsește cel mai des când cineva raportează că rezolvarea funcționează din interiorul Azure, dar nu din birou.

Verifică traseul în ordine

Confirmă că zona este legată de VNet-ul care conține resolverul și că forwarderul local numește spațiul de nume, nu un domeniu părinte. Un forwarder pentru corp.example nu se va potrivi cu cloud.corp.example decât dacă resolverul însuși deleagă, iar nepotrivirea produce un răspuns negativ curat care arată ca o înregistrare lipsă.

Apoi verifică dacă interogarea ajunge la punctul final: sursa locală are nevoie de o rută către adresa resolverului și de o cale de întoarcere, iar portul 53 ar trebui permis atât pentru UDP, cât și pentru TCP unde politica permite. Un NSG nu poate furniza o înregistrare de zonă lipsă, iar o zonă corectă nu poate răspunde la o interogare care nu ajunge niciodată.

Păstrează FQDN-ul solicitat lângă resolverul ales când diagnostichezi și separă un timeout de un răspuns negativ. Un timeout este o problemă de rută sau de politică. Un răspuns negativ înseamnă că interogarea a ajuns și spațiul de nume nu s-a potrivit. Ordinea lucrului: leagă zona, adaugă forwarderul condiționat, deschide portul 53 în ambele sensuri, testează un nume din rețeaua locală și abia apoi uită-te la autorizarea proprie a aplicației.