Server DNS greșit în VPN Windows: metrică, ordine de legare sau sufix

Un client Windows poate avea un tunel funcțional, poartă resolverul companiei și totuși trimite numele interne către routerul de acasă. Trei mecanisme diferite decid ce server răspunde, și eșuează în moduri diferite. Nu trebuie reparate toate trei: simptomul îți spune care este în joc. Arborele de decizie de mai jos durează câteva minute și împiedică rezultatul obișnuit, în care o modificare de metrică, o reordonare a registrului și o regulă NRPT sosesc împreună și nimeni nu știe care a făcut ceva.

Trei mecanisme decid, și de obicei unul este greșit

Metrica interfeței ordonează adaptoarele pentru o anumită familie de adrese. Ordinea de legare de sub Tcpip\Linkage este o listă la nivel de mașină de identificatori de interfață pe care căile de cod mai vechi încă le consultă. Tabelul de politici de rezolvare a numelor (NRPT) leagă un spațiu de nume de servere anume, iar lista de sufixe decide dacă un nume scurt este extins. Sunt independente, și de aceea un resolver corect pe adaptorul VPN pierde în fața unei preferințe învechite în altă parte.

Niciunul dintre aceste mecanisme nu este cealaltă parte a tunelului. Dacă serverul pe care îl împinge VPN-ul nu poate rezolva numele, orice setare din partea clientului este doar decor, așa că prima decizie este dacă resolverul însuși poate răspunde atunci când este întrebat direct.

Decizia unu: poate resolverul împins să răspundă?

Întreabă serverul în mod explicit și compară cu o căutare obișnuită. Diferența dintre răspunsuri separă o problemă de selecție de o problemă de accesibilitate, și aici este cea mai rapidă bifurcație:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Dacă prima reușește și a doua eșuează, resolverul este accesibil și Windows alege prost; mergi la deciziile despre spațiul de nume și ordine de mai jos. Dacă și prima eșuează, nimic din client nu va ajuta: verifică dacă UDP și TCP 53 ajung la server prin tunel, dacă vreun firewall de gazdă de pe server nu aruncă pool-ul și dacă redirectoarele proprii ale serverului sunt sănătoase.

Oprește-te la această bifurcație. Aplicarea unei reguli NRPT pe un resolver la care nu poți ajunge produce aceeași defecțiune cu mai multă configurație de anulat, și ascunde defectul real în spatele unei reguli care pare autoritară.

Decizia doi: un spațiu de nume sau fiecare interogare?

Amploarea decide instrumentul. Când eșuează doar numele companiei, leagă spațiul de nume în loc să reordonezi mașina: o regulă NRPT trimite acel sufix la resolverul tunelului și lasă restul în pace. Când fiecare căutare este afectată, problema este preferința globală a adaptoarelor, iar metrica este punctul de pornire pentru că nu schimbă nicio setare a serverului.

Setează metrica pentru fiecare familie de adrese, pe ambele interfețe, și confirmă apoi ordinea:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Înlocuiește 11 cu ifIndex-ul adaptorului tunelului din linia de mai sus; dacă 11 este adaptorul LAN, aceeași comandă coboară calea greșită. Ridicarea adaptorului LAN ajunge la aceeași ordine din cealaltă parte: netsh int ip set interface interface="Ethernet" metric=15, și netsh int ipv6 set interface interface="Ethernet" metric=15 pentru a doua familie, pentru că int ip atinge doar IPv4.

Ordinea de legare este ultima soluție și nu primul pas. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage conține o listă Bind de identificatori de dispozitiv, iar mutarea identificatorului tunelului în față schimbă într-adevăr ce adaptor este întrebat primul, dar este o valoare de registru la nivel de mașină fără amploare pe spațiu de nume. Export-o înainte de editare și reconectează tunelul după aceea, ca ordinea să se aplice în starea pe care o așteaptă clientul.

Pentru un singur spațiu de nume, preferă instrumentul mai îngust:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Decizia trei: corectura supraviețuiește unei reconectări?

O metrică ce funcționează până la următoarea reconectare prin linie comutată nu a fost niciodată salvată. L2TP/IPsec și alte profiluri de conexiune sunt recreate la pornirea conexiunii, așa că valoarea salvată trăiește în intrarea din agenda telefonică ca IpInterfaceMetric, nu doar pe interfața activă. Unele medii scriptează acel câmp exact din acest motiv; altele împing preferința dintr-o politică de gestionare și lasă punctul final în pace.

Cache-ul și înregistrarea sunt un strat separat. Rularea acestora după ce tunelul urcă corectează intrările învechite și reînregistrează clientul, dar niciuna nu reordonează un adaptor:

ipconfig /registerdns
ipconfig /flushdns

Există un întrerupător în același strat. Dezactivarea înregistrării dinamice pe adaptorul fizic împiedică clientul să anunțe adresa sa din partea VPN sub numele greșit, iar aceasta este o reparație diferită de actualizarea de mai sus.

IPv6 merită o linie proprie în decizie. Dacă adaptorul fizic are o adresă IPv6 globală în timp ce tunelul transportă doar IPv4, Windows poate prefera calea fără tunel pentru rezolvarea numelor. Verifică acea familie separat, pentru că o metrică setată pentru IPv4 nu spune nimic despre ea:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Dezactivarea IPv6 pe adaptorul LAN elimină acea cale și protocolul odată cu ea; o modificare de metrică pe interfața IPv6, sau o regulă NRPT pentru spațiul de nume al companiei, păstrează familia și corectează preferința. Alege-o pe cea mai îngustă, dacă nu ai decis că acea legătură nu trebuie să aibă IPv6.

Verifică cu sursa numită, și păstrează un singur proprietar

Verifică cu instrumente care raportează ce sursă este în vigoare, nu doar dacă se încarcă o pagină:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Apoi separă filtrarea de selecție, pentru că din interiorul unei aplicații par identice. block-outside-dns din OpenVPN blochează portul 53 pe celelalte adaptoare; nu alege un resolver. Dacă acum fiecare interogare eșuează, un filtru poate bloca singurul server accesibil; dacă resolverul configurat este ignorat, ordinea sau regula spațiului de nume este greșită. Schimbarea ambelor deodată face o interogare blocată și una ignorată imposibil de distins.

Păstrează un singur proprietar pentru politica DNS: profilul VPN, o politică de gestionare sau o regulă NRPT, nu două dintre ele. Înainte să închizi:

• Resolverul împins răspunde când este numit explicit, iar o căutare obișnuită îl folosește.
• Regula sau metrica pe care ai schimbat-o acoperă familia de adrese care chiar transportă interogările.
• Setarea supraviețuiește unei deconectări și reconectări, sau ai mutat-o în profilul salvat.
• Exact un mecanism este autoritar, iar celelalte au fost lăsate cum erau.

Tratează ordinea ca stare a mediului și nu ca ceva ce se termină. Reverific-o după o reconectare și după o actualizare Windows care atinge stiva de rețea, pentru că oricare dintre ele poate readuce adaptorul fizic în față.