Feil DNS-server i Windows VPN: metrikk, bindingsrekkefølge eller suffiks

En Windows-klient kan ha en fungerende tunnel, bære den bedriftsstyrte resolveren og likevel sende interne navn til hjemmeruteren. Tre ulike mekanismer avgjør hvilken server som svarer, og de svikter på ulike måter. Du trenger ikke rette alle tre: symptomet forteller deg hvilken som er i spill. Beslutningstreet nedenfor tar noen minutter og forhindrer det vanlige utfallet, der en metrikkendring, en omordning av registeret og en NRPT-regel lander samtidig og ingen vet hvilken som gjorde noe.

Tre mekanismer avgjør, og vanligvis er én feil

Grensesnittmetrikken ordner adaptere for en gitt adressefamilie. Bindingsrekkefølgen under Tcpip\Linkage er en maskinvid liste over grensesnittidentifikatorer som eldre kodestier fortsatt konsulterer. Navneoppløsningsretningslinjetabellen (NRPT) binder et navnerom til bestemte servere, og suffikslisten avgjør om et kort navn i det hele tatt utvides. De er uavhengige, og derfor taper en korrekt resolver på VPN-adapteren mot en utdatert preferanse et annet sted.

Ingen av disse mekanismene er den andre siden av tunnelen. Hvis serveren som VPN-en skyver ut ikke kan løse navnet, er hver innstilling på klientsiden bare pynt, så den første beslutningen er om resolveren selv kan svare når man spør den direkte.

Beslutning én: kan den utskutte resolveren svare i det hele tatt?

Spør serveren eksplisitt og sammenlign med et vanlig oppslag. Gapet mellom svarene skiller et utvalgsproblem fra et tilgjengelighetsproblem, og det er den raskeste forgreningen her:

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

Hvis det første lykkes og det andre feiler, er resolveren tilgjengelig og Windows velger dårlig; gå til beslutningene om navnerom og rekkefølge nedenfor. Hvis det første også feiler, hjelper ingenting på klienten: kontroller at UDP og TCP 53 når serveren gjennom tunnelen, at ingen vertsbrannmur på serveren slipper puljen, og at serverens egne videresendere er sunne.

Stopp ved denne forgreningen. Å bruke en NRPT-regel på en resolver du ikke kan nå gir samme feil med mer konfigurasjon å rulle tilbake, og den skjuler den egentlige feilen bak en regel som ser autoritativ ut.

Beslutning to: ett navnerom eller hver spørring?

Omfanget avgjør verktøyet. Når bare bedriftsnavn feiler, bind navnerommet i stedet for å omordne maskinen: en NRPT-regel sender det suffikset til tunnelens resolver og lar alt annet være. Når hvert oppslag er rammet, er problemet global adapterpreferanse, og metrikken er stedet å begynne fordi den ikke endrer noen serverinnstilling.

Sett metrikken per adressefamilie, på begge grensesnittene, og bekreft rekkefølgen etterpå:

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

Erstatt 11 med tunneladapterens ifIndex fra linjen ovenfor; hvis 11 er LAN-adapteren, senker samme kommando feil vei. Å heve LAN-adapteren i stedet når samme rekkefølge fra den andre siden: netsh int ip set interface interface="Ethernet" metric=15, og netsh int ipv6 set interface interface="Ethernet" metric=15 for den andre familien, fordi int ip bare berører IPv4.

Bindingsrekkefølgen er siste utvei og ikke første trekk. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage holder en Bind-liste over enhetsidentifikatorer, og å flytte tunnelens identifikator fremover endrer faktisk hvilken adapter som spørres først, men det er en maskinvid registerverdi uten omfang per navnerom. Eksporter den før du redigerer, og koble tunnelen til på nytt etterpå, slik at rekkefølgen gjelder i den tilstanden klienten forventer.

For ett navnerom, foretrekk det smalere verktøyet:

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

Beslutning tre: overlever rettelsen en gjentilkobling?

En metrikk som virker til neste oppringte tilkobling ble aldri lagret. L2TP/IPsec og andre tilkoblingsprofiler gjenopprettes når tilkoblingen starter, så den lagrede verdien lever i telefonbokoppføringen som IpInterfaceMetric, ikke bare på det levende grensesnittet. Noen miljøer skriptlegger det feltet nettopp derfor; andre skyver preferansen fra en administrasjonspolicy og lar endepunktet være.

Cache og registrering er et eget lag. Å kjøre disse etter at tunnelen er oppe retter utdaterte oppføringer og registrerer klienten på nytt, men ingen av dem omordner en adapter:

ipconfig /registerdns
ipconfig /flushdns

Det finnes en avbryter i samme lag. Å deaktivere dynamisk registrering på den fysiske adapteren hindrer klienten i å annonsere sin VPN-sideadresse under feil navn, og det er en annen reparasjon enn oppdateringen ovenfor.

IPv6 fortjener sin egen linje i beslutningen. Hvis den fysiske adapteren har en global IPv6-adresse mens tunnelen bare bærer IPv4, kan Windows foretrekke den tunnelfrie veien for navneoppløsning. Sjekk den familien separat, fordi en metrikk satt for IPv4 ikke sier noe om den:

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

Å deaktivere IPv6 på LAN-adapteren fjerner den veien og protokollen med den; en metrikkendring på IPv6-grensesnittet, eller en NRPT-regel for bedriftsnavnerommet, beholder familien og retter preferansen. Velg den smalere, med mindre du har bestemt at den lenken ikke skal ha IPv6.

Verifiser med kilden navngitt, og hold én eier

Verifiser med verktøy som rapporterer hvilken kilde som er i kraft, ikke bare om en side lastes:

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

Skill så filtrering fra utvalg, fordi de ser identiske ut innenfra en applikasjon. block-outside-dns i OpenVPN blokkerer port 53 på de andre adapterne; den velger ikke resolver. Hvis hver spørring nå feiler, kan et filter blokkere den eneste tilgjengelige serveren; hvis den konfigurerte resolveren ignoreres, er rekkefølgen eller navneromsregelen feil. Å endre begge samtidig gjør en blokkert spørring og en ignorert spørring umulige å skille.

Hold én eier av DNS-policyen: VPN-profilen, en administrasjonspolicy eller en NRPT-regel, ikke to av dem. Før du lukker saken:

• Den utskutte resolveren svarer når den navngis eksplisitt, og et vanlig oppslag bruker den.
• Regelen eller metrikken du endret dekker adressefamilien som faktisk bærer spørringene.
• Innstillingen overlever en frakobling og gjentilkobling, eller du har flyttet den inn i den lagrede profilen.
• Nøyaktig én mekanisme er autoritativ, og de andre er latt som de var.

Behandle rekkefølgen som miljøtilstand og ikke som noe du fullfører. Sjekk den på nytt etter en gjentilkobling og etter en Windows-oppdatering som berører nettverksstakken, fordi begge kan sette den fysiske adapteren foran igjen.