Fel DNS-server i Windows VPN: metrik, bindningsordning eller suffix

En Windows-klient kan ha en fungerande tunnel, bära företagets resolver och ändå skicka interna namn till hemroutern. Tre olika mekanismer avgör vilken server som svarar, och de misslyckas på olika sätt. Du behöver inte åtgärda alla tre: symtomet säger vilken som är i spel. Beslutsträdet nedan tar några minuter och förhindrar det vanliga utfallet, där en metrikändring, en omordning i registret och en NRPT-regel landar samtidigt och ingen vet vilken som gjorde något.

Tre mekanismer avgör, och oftast är en fel

Gränssnittsmetriken ordnar adaptrar för en viss adressfamilj. Bindningsordningen under Tcpip\Linkage är en maskinvidd lista över gränssnittsidentifierare som äldre kodvägar fortfarande konsulterar. Namnupplösningsprinciptabellen (NRPT) binder ett namnområde till specifika servrar, och suffixlistan avgör om ett kort namn alls expanderas. De är oberoende, och därför förlorar en korrekt resolver på VPN-adaptern mot en föråldrad preferens någon annanstans.

Ingen av dessa mekanismer är tunnelns andra sida. Om servern som VPN:en skjuter ut inte kan lösa namnet är varje inställning på klientsidan bara dekoration, så det första beslutet är om resolvern själv kan svara när man frågar den direkt.

Beslut ett: kan den utskjutna resolvern svara över huvud taget?

Fråga servern uttryckligen och jämför med ett vanligt uppslag. Gapet mellan svaren skiljer ett urvalsproblem från ett nåbarhetsproblem, och det är den snabbaste förgreningen här:

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

Om det första lyckas och det andra misslyckas är resolvern nåbar och Windows väljer dåligt; gå till besluten om namnområde och ordning nedan. Om det första också misslyckas hjälper inget på klienten: kontrollera att UDP och TCP 53 når servern genom tunneln, att ingen värdbrandvägg på servern släpper poolen, och att serverns egna vidarebefordrare är friska.

Stanna vid den här förgreningen. Att tillämpa en NRPT-regel på en resolver du inte kan nå ger samma fel med mer konfiguration att rulla tillbaka, och den döljer det egentliga felet bakom en regel som ser auktoritativ ut.

Beslut två: ett namnområde eller varje fråga?

Omfattningen avgör verktyget. När bara företagsnamn misslyckas, bind namnområdet i stället för att ordna om maskinen: en NRPT-regel skickar det suffixet till tunnelns resolver och lämnar allt annat i fred. När varje uppslag drabbas, är problemet global adapterpreferens, och metriken är stället att börja på eftersom den inte ändrar någon serverinställning.

Ställ in metriken per adressfamilj, på båda gränssnitten, och bekräfta sedan ordningen:

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

Byt ut 11 mot tunneladapterns ifIndex från raden ovan; om 11 är LAN-adaptern sänker samma kommando fel väg. Att höja LAN-adaptern i stället når samma ordning från andra sidan: netsh int ip set interface interface="Ethernet" metric=15, och netsh int ipv6 set interface interface="Ethernet" metric=15 för den andra familjen, eftersom int ip bara rör IPv4.

Bindningsordningen är den sista utvägen och inte det första draget. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage innehåller en Bind-lista över enhetsidentifierare, och att flytta tunnelns identifierare främst ändrar faktiskt vilken adapter som frågas först, men det är ett maskinvitt registervärde utan omfattning per namnområde. Exportera det före redigering och återanslut tunneln efteråt, så att ordningen gäller i det tillstånd klienten förväntar sig.

För ett enda namnområde, föredra det smalare verktyget:

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

Beslut tre: överlever åtgärden en återanslutning?

En metrik som fungerar till nästa uppringda anslutning sparades aldrig. L2TP/IPsec och andra anslutningsprofiler skapas på nytt när anslutningen startar, så det sparade värdet lever i telefonboksanteckningen som IpInterfaceMetric, inte bara på det levande gränssnittet. Vissa miljöer skriptar det fältet just därför; andra skjuter ut preferensen från en hanteringspolicy och låter slutpunkten vara.

Cache och registrering är ett eget lager. Att köra dessa efter att tunneln är uppe rättar inaktuella poster och registrerar om klienten, men ingen av dem ordnar om en adapter:

ipconfig /registerdns
ipconfig /flushdns

Det finns en avstängningsknapp i samma lager. Att stänga av dynamisk registrering på den fysiska adaptern hindrar klienten från att annonsera sin VPN-sidoadress under fel namn, och det är en annan reparation än uppdateringen ovan.

IPv6 förtjänar en egen rad i beslutet. Om den fysiska adaptern har en global IPv6-adress medan tunneln bara bär IPv4, kan Windows föredra den tunnelfria vägen för namnuplösning. Kontrollera den familjen separat, eftersom en metrik satt för IPv4 inte säger något om den:

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

Att stänga av IPv6 på LAN-adaptern tar bort den vägen och protokollet med den; en metrikändring på IPv6-gränssnittet, eller en NRPT-regel för företagets namnområde, behåller familjen och rättar preferensen. Välj den smalare, om du inte har bestämt att den länken inte ska ha IPv6.

Verifiera med källan namngiven, och håll en ägare

Verifiera med verktyg som rapporterar vilken källa som gäller, inte bara om en sida laddas:

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

Separera sedan filtrering från urval, eftersom de ser identiska ut inifrån en applikation. block-outside-dns i OpenVPN blockerar port 53 på de andra adaptrarna; den väljer ingen resolver. Om varje fråga nu misslyckas kan ett filter blockera den enda nåbara servern; om den konfigurerade resolvern ignoreras är ordningen eller namnområdesregeln fel. Att ändra båda samtidigt gör en blockerad fråga och en ignorerad fråga omöjliga att skilja åt.

Håll en ägare av DNS-policyn: VPN-profilen, en hanteringspolicy eller en NRPT-regel, inte två av dem. Innan du stänger ärendet:

• Den utskjutna resolvern svarar när den namnges uttryckligen, och ett vanligt uppslag använder den.
• Regeln eller metriken du ändrade täcker den adressfamilj som faktiskt bär frågorna.
• Inställningen överlever en frånkoppling och återanslutning, eller du har flyttat den till den sparade profilen.
• Exakt en mekanism är auktoritativ, och de andra lämnades som de var.

Behandla ordningen som miljötillstånd och inte som något du slutför. Kontrollera den igen efter en återanslutning och efter en Windows-uppdatering som rör nätverksstacken, eftersom båda kan sätta den fysiska adaptern först igen.