VPN-ul a preluat DNS-ul și a stricat numele locale: repară lista

Tunelul urcă, intranetul se încarcă, iar numele imprimantei nu mai este rezolvat. Sau invers: numele locale încă funcționează în timp ce tot ce e în rețeaua corporativă ajunge la expirare. Ambele simptome vin din același loc, o listă de resolveri pe care clientul VPN a rescris-o la conectare.

Repară lista intenționat, apoi ocupă-te separat de mecanismul push. Rutele sunt un al treilea subiect și nu este cel reparat aici.

Ce listă folosesc de fapt aplicațiile

Windows rezolvă prin setări la nivel de interfață și nu prin ce arată un dialog, așa că începe cu listele efective pentru fiecare interfață. Aliasul contează mai mult decât numele afișat, pentru că fiecare comandă de mai jos se adresează unei interfețe. Greșești aliasul și reparația ajunge pe adaptorul greșit. Va părea că funcționează până la următoarea reconectare, când intrarea tunelului însuși revine.

Întrebarea este ce servere au ajuns în față și dacă au venit ca intrări statice sau ca închiriere DHCP. Ambele fapte decid ce reparație îți este disponibilă.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Citește ieșirea pentru adaptorul tunelului și pentru cel fizic și notează fiecare adresă pe fiecare. O intrare statică poate fi eliminată printr-o politică sau un script; una furnizată de DHCP este legată de închiriere și va reveni, ceea ce schimbă reparația pe care ar trebui să o alegi. Numele din rețeaua îndepărtată sunt rezolvate de resolverul anunțat, numele din LAN-ul local de adaptorul fizic, iar interogarea merge către lista consultată prima.

Elimină serverele împinse, sau clasează-le mai jos

Șterge serverele împinse când nimic din tunel nu are nevoie de ele, pentru că resolverii adaptorului fizic preiau din nou. Păstrează-le doar dacă rețeaua îndepărtată are zone la care pot răspunde numai serverele ei, iar în acest caz pune un resolver local în fața lor. Cele două comenzi de mai jos acoperă ambele opțiuni, așa că alege-o pe cea potrivită situației în loc să le rulezi pe amândouă.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Indexul 1 este consultat primul, așa că adresele împinse rămân disponibile dar încetează să mai fie răspunsul implicit pentru fiecare interogare. Indicatorul validate=no sare peste un test de accesibilitate care eșuează des în timp ce tunelul încă se așază, așa că confirmă rezultatul cu comanda show în loc să te bazezi pe codul de ieșire.

Merită să știi două limite înainte să te bazezi pe asta. Windows nu va șterge serverele care au venit prin DHCP prin netsh, iar acele valori persistă ca DhcpNameServer sub cheia de registry a interfeței, așa că editarea registry-ului este ultima soluție și trebuie reverificată după următoarea închiriere. Nici ordinea de legare a adaptoarelor nu este un mecanism fiabil de ierarhizare, pentru că un client VPN poate insera propria intrare în fruntea listei.

Unde poate fi filtrat push-ul

O reparație mai bună scoate opțiunea înainte de a fi aplicată. Clientul Community OpenVPN poate filtra o directivă împinsă după nume, ceea ce lasă configurația serverului neatinsă.

pull-filter ignore "dhcp-option DNS "

Spațiul final aparține potrivirii, iar filtrul numește opțiunea, nu o adresă de server. Dacă profilul conține și o directivă block-outside-dns, eliminarea ei schimbă protecția la scurgeri și nu rezolvarea numelor, așa că decide asta separat în loc să combini cele două modificări.

Pentru un singur nume de gazdă încăpățânat, o linie în fișierul hosts din Windows este mai stabilă decât reordonarea resolverilor pentru toată mașina. Este și invizibilă pentru următoarea persoană, așa că noteaz-o acolo unde este documentată configurația mașinii.

Fă reparația să supraviețuiască unei reconectări

Rezolvarea trebuie testată de două ori, o dată împotriva unui server ales și o dată în forma pe care o folosește o aplicație. Acea pereche separă o problemă de ordine a resolverilor de un server care nu răspunde deloc. Dacă sari peste primul test, cele două cauze rămân încurcate.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Reconectează tunelul și repetă ambele comenzi. Ce ai schimbat manual rezistă doar până la următoarea conexiune, pentru că clientul reconstruiește starea resolverilor în timp ce ridică adaptorul. Pune liniile netsh în scriptul de conectare acceptat al clientului tău, lasă scriptul să se termine cu succes și adaugă o scurtă așteptare înainte de a rula. Un client care aplică DNS după script va suprascrie rezultatul oricum.

Dacă numele publice se rezolvă, iar cele interne încă eșuează după reparație, lista de resolveri nu mai este suspectul. Interogarea probabil nu ajunge deloc la server, ceea ce indică rutare sau o regulă de firewall și nu o altă setare DNS. Notează aliasul interfeței și adresele la care te-ai oprit, pentru că ambele diferă între mașini și niciuna nu supraviețuiește singură unei reconstrucții.