De ce un punct final privat răspunde în continuare cu o adresă publică

Laptopul se conectează, tunelul se declară activ, iar contul de stocare refuză în continuare fiecare cerere. Punctul final privat există, ruta către subrețeaua sa există, iar numele fie răspunde cu o adresă publică, fie nu se rezolvă deloc. Tunelul nu are nimic în neregulă: clientului nu i s-a spus niciodată care server ar trebui să răspundă pentru acel nume. Urmați interogarea spre exterior și diferența devine evidentă.

Începeți cu resolverul clientului

Întrebați clientul ce server interoghează cât timp tunelul este activ. Un profil punct-la-site furnizează acea adresă, iar un profil care nu furnizează nimic lasă sistemul de operare să revină la valorile implicite ale adaptorului.

Resolverele publice nu au nicio vedere asupra unei zone private, așa că răspund din internet, ceea ce este exact treaba lor. Prima verificare este așadar adresa resolverului folosit, nu tunelul și nu punctul final.

Citiți ce este de fapt răspunsul

Rezolvați numele serviciului și citiți adresa care revine. Un răspuns public înseamnă că interogarea a ajuns la un server care nu poate vedea zona. Niciun răspuns înseamnă că numele există doar privat și că nimic la ce clientul poate ajunge nu îl deține.

Aceste două rezultate produc erori de aplicație similare și aparțin unor proprietari diferiți. Unul este o problemă de alegere a resolverului, celălalt este o legătură de zonă lipsă.

O intrare hosts dovedește calea, apoi minte

Punerea adresei punctului final în fișierul hosts local este cea mai rapidă cale de a dovedi că tunelul și firewallul serviciului funcționează deja. Dacă cererea reușește cu acea intrare, doar rezolvarea numelor este stricată. Este și o modificare pentru fiecare mașină care acoperă exact un nume.

Nu ajută al doilea cont, al doilea punct final sau un coleg, și se strică fără avertisment când punctul final este recreat la o adresă nouă.

Mai rău, face ca mașina dumneavoastră să se comporte diferit de a tuturor, și așa supraviețuiește o defecțiune a resolverului o săptămână de investigație. Folosiți-o pentru a confirma calea, apoi scoateți-o și corectați cauza.

Legați zona și distribuiți un resolver

Două condiții trebuie să fie valabile simultan. Zona privată trebuie să fie legată de rețeaua virtuală în care se află punctul final, iar clientul trebuie să își trimită interogările către un server care poate citi acea zonă. Un punct final de intrare din DNS Private Resolver oferă o astfel de adresă în interiorul rețelei și răspunde interogărilor care sosesc prin tunel. Puneți acea adresă în profilul VPN și adăugați sufixul privat pe care clientul trebuie să îl aplice.

Un resolver local deja existent poate obține același rezultat printr-un forwarder condiționat îndreptat către zonă.

Regulile de rețea de pe resolver contează la fel de mult ca rutarea. Dacă regula de intrare exclude intervalul clienților VPN, interogările expiră în loc să returneze un răspuns greșit. Tocmai această expirare trimite lumea înapoi la un tabel de rute în care nimic nu este greșit.

Verificați numele, portul și identitatea în ordine

Lucrați în ordine: rezolvați numele, confirmați că răspunsul este privat, deschideți portul, apoi faceți o cerere autentificată. Fiecare etapă are propriul proprietar și propria semnătură de eșec.

Un răspuns privat urmat de expirare indică o rută sau un firewall. Un răspuns public indică resolverul. O conexiune finalizată care returnează o eroare de identitate aparține serviciului.

Încă o defecțiune aparține acestei liste. Un firewall de serviciu care permite o adresă de client nu mai corespunde când poolul atribuie acea adresă altei sesiuni după reconectare. Citiți adresa apelantului pe care serviciul a înregistrat-o, nu pe cea pe care clientul crede că o are. Cele două nu sunt de acord mai des decât se așteaptă lumea. Îndrumările Azure DNS Private Resolver acoperă legătura zonei și aranjamentul de forwardare.