Forkert DNS-server i Windows VPN: metrik, bindingsrækkefølge eller suffiks

En Windows-klient kan have en fungerende tunnel, bære den virksomhedsudstedte resolver og alligevel sende interne navne til hjemmeruteren. Tre forskellige mekanismer afgør, hvilken server der svarer, og de fejler på hver sin måde. Du behøver ikke rette alle tre: symptomet fortæller, hvilken der er i spil. Beslutningstræet nedenfor tager et par minutter og forhindrer det sædvanlige udfald, hvor en metrikændring, en omordning i registreringsdatabasen og en NRPT-regel lander samtidig, og ingen ved, hvilken der gjorde noget.

Tre mekanismer afgør, og som regel er én forkert

Interfacemetrikken ordner adaptere for en given adressefamilie. Bindingsrækkefølgen under Tcpip\Linkage er en maskinvid liste over interface-id'er, som ældre kodestier stadig konsulterer. Navneopløsningspolitiktabellen (NRPT) binder et navneområde til bestemte servere, og suffikslisten afgør, om et kort navn overhovedet udvides. De er uafhængige, og derfor taber en korrekt resolver på VPN-adapteren til en forældet præference et andet sted.

Ingen af disse mekanismer er den anden side af tunnelen. Hvis serveren, som VPN'en skubber ud, ikke kan opløse navnet, er enhver indstilling på klientsiden pynt, så den første beslutning er, om resolveren selv kan svare, når man spørger den direkte.

Beslutning et: kan den udskubbede resolver overhovedet svare?

Spørg serveren eksplicit, og sammenlign med et almindeligt opslag. Forskellen mellem svarene skiller et udvælgelsesproblem fra et tilgængelighedsproblem, og det er den hurtigste forgrening 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 andet fejler, er resolveren tilgængelig, og Windows vælger dårligt; gå til beslutningerne om navneområde og rækkefølge nedenfor. Hvis det første også fejler, hjælper intet på klienten: kontrollér, at UDP og TCP 53 når serveren gennem tunnelen, at ingen host-firewall på serveren dropper poolen, og at serverens egne videresendere er sunde.

Stop ved denne forgrening. At anvende en NRPT-regel på en resolver, du ikke kan nå, giver samme fejl med mere konfiguration at rulle tilbage, og den skjuler den egentlige fejl bag en regel, der ser autoritativ ud.

Beslutning to: ét navneområde eller hver forespørgsel?

Omfanget afgør værktøjet. Når kun virksomhedsnavne fejler, bind navneområdet i stedet for at omordne maskinen: en NRPT-regel sender det suffiks til tunnelens resolver og lader alt andet være. Når hvert opslag er ramt, er problemet global adapterpræference, og metrikken er stedet at begynde, fordi den ikke ændrer nogen serverindstilling.

Sæt metrikken per adressefamilie på begge interfaces, og bekræft rækkefølgen bagefter:

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

Erstat 11 med tunneladapterens ifIndex fra linjen ovenfor; hvis 11 er LAN-adapteren, sænker samme kommando den forkerte vej. At hæve LAN-adapteren i stedet når samme rækkefølge fra den anden side: netsh int ip set interface interface="Ethernet" metric=15, og netsh int ipv6 set interface interface="Ethernet" metric=15 for den anden familie, fordi int ip kun rører IPv4.

Bindingsrækkefølgen er den sidste udvej snarere end det første træk. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage indeholder en Bind-liste over enheds-id'er, og at flytte tunnelens id frem ændrer faktisk, hvilken adapter der spørges først, men det er en maskinvid registreringsværdi uden omfang per navneområde. Eksportér den før redigering, og genopret tunnelen bagefter, så rækkefølgen gælder i den tilstand, klienten forventer.

Til ét navneområde, foretræk det smallere værktøj:

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

Beslutning tre: overlever rettelsen en genopkobling?

En metrik, der virker indtil den næste opkobling via telefonlinje, blev aldrig gemt. L2TP/IPsec og andre forbindelsesprofiler genskabes, når forbindelsen starter, så den gemte værdi lever i telefonbogsindgangen som IpInterfaceMetric, ikke kun på det levende interface. Nogle miljøer skripter det felt netop derfor; andre skubber præferencen fra en administrationspolitik og lader endepunktet være.

Cache og registrering er et separat lag. At køre disse, når tunnelen er oppe, retter forældede poster og registrerer klienten igen, men ingen af dem omordner en adapter:

ipconfig /registerdns
ipconfig /flushdns

Der er en afbryder i samme lag. Deaktivering af dynamisk registrering på den fysiske adapter forhindrer klienten i at annoncere sin VPN-side-adresse under det forkerte navn, hvilket er en anden reparation end opdateringen ovenfor.

IPv6 fortjener sin egen linje i beslutningen. Hvis den fysiske adapter har en global IPv6-adresse, mens tunnelen kun bærer IPv4, kan Windows foretrække den tunnelfrie vej til navneopløsning. Tjek den familie separat, fordi en metrik sat for IPv4 intet siger om den:

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

Deaktivering af IPv6 på LAN-adapteren fjerner den vej og protokollen med den; en metrikændring på IPv6-interfacet eller en NRPT-regel for virksomhedens navneområde beholder familien og retter præferencen. Vælg den smalle løsning, medmindre du har besluttet, at det link ikke skal have IPv6.

Verificér med kilden nævnt, og hold én ejer

Verificér med værktøjer, der rapporterer, hvilken kilde der er i kraft, ikke blot om en side indlæses:

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

Adskil derefter filtrering fra udvælgelse, fordi de ser identiske ud inde fra en applikation. block-outside-dns i OpenVPN blokerer port 53 på andre adaptere; den vælger ikke en resolver. Hvis hver forespørgsel nu fejler, kan et filter blokere den eneste tilgængelige server; hvis den konfigurerede resolver ignoreres, er rækkefølgen eller navneområderegelen forkert. At ændre begge på én gang gør en blokeret forespørgsel og en ignoreret forespørgsel umulige at skelne.

Hold én ejer af DNS-politikken: VPN-profilen, en administrationspolitik eller en NRPT-regel, ikke to af dem. Før du lukker sagen:

• Den udskubbede resolver svarer, når den nævnes eksplicit, og et almindeligt opslag bruger den.
• Reglen eller metrikken, du ændrede, dækker den adressefamilie, der faktisk bærer forespørgslerne.
• Indstillingen overlever en afbrydelse og genopkobling, eller du har flyttet den ind i den gemte profil.
• Præcis én mekanisme er autoritativ, og de andre er ladt som de var.

Behandl rækkefølgen som miljøtilstand snarere end noget, du afslutter. Tjek den igen efter en genopkobling og efter en Windows-opdatering, der rører netværksstakken, fordi begge kan sætte den fysiske adapter forrest igen.