Feil DNS-tenar i Windows VPN: metrikk, bindingsrekkjefølgje eller suffiks

Ein Windows-klient kan ha ein fungerande tunnel, bera den bedriftsstyrte resolveren og likevel senda interne namn til heimerutaren. Tre ulike mekanismar avgjer kva tenar som svarar, og dei sviktar på ulike måtar. Du treng ikkje retta alle tre: symptomet fortel deg kven som er i spel. Beslutningstreet nedanfor tek nokre minutt og hindrar det vanlege utfallet, der ei metrikkendring, ei omordning av registeret og ein NRPT-regel landar samstundes og ingen veit kven som gjorde noko.

Tre mekanismar avgjer, og vanlegvis er éin feil

Grensesnittmetrikken ordnar adapterar for ein gitt adressefamilie. Bindingsrekkjefølgja under Tcpip\Linkage er ei maskinvid liste over grensesnittidentifikatorar som eldre kodestiar framleis konsulterer. Namneoppløysingsretningslinjetabellen (NRPT) bind eit namnerom til bestemte tenarar, og suffikslista avgjer om eit kort namn i det heile blir utvida. Dei er uavhengige, og difor tapar ein korrekt resolver på VPN-adapteren mot ei utdatert preferanse ein annan stad.

Ingen av desse mekanismane er den andre sida av tunnelen. Viss tenaren som VPN-en skyv ut ikkje kan løysa namnet, er kvar innstilling på klientsida berre pynt, så den første avgjerda er om resolveren sjølv kan svara når ein spør han direkte.

Avgjerd éin: kan den utskutte resolveren svara i det heile?

Spør tenaren eksplisitt og samanlikn med eit vanleg oppslag. Gapet mellom svara skil eit utvalsproblem frå eit tilgjengeproblem, og det er den snøggaste greina her:

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

Viss det første lukkast og det andre feilar, er resolveren tilgjengeleg og Windows vel dårleg; gå til avgjerdene om namnerom og rekkjefølgje nedanfor. Viss det første også feilar, hjelper ingenting på klienten: kontroller at UDP og TCP 53 når tenaren gjennom tunnelen, at ingen vertsbrannmur på tenaren slepp puljen, og at tenaren sine eigne videresendarar er sunne.

Stopp ved denne greina. Å bruka ein NRPT-regel på ein resolver du ikkje kan nå gir same feilen med meir konfigurasjon å rulle tilbake, og han skjuler den eigentlege feilen bak ein regel som ser autoritativ ut.

Avgjerd to: eitt namnerom eller kvar spørjing?

Omfanget avgjer verktøyet. Når berre bedriftsnamn feilar, bind namnerommet i staden for å omordna maskinen: ein NRPT-regel sender det suffikset til resolveren i tunnelen og lèt alt anna vera. Når kvar oppslag er ramma, er problemet global adapterpreferanse, og metrikken er staden å byrja fordi han ikkje endrar noka tenarinnstilling.

Set metrikken per adressefamilie, på begge grensesnitt, og stadfest rekkjefølgja 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

Byt ut 11 med ifIndex til tunneladapteren frå linja ovanfor; viss 11 er LAN-adapteren, søkkjer same kommando feil veg. Å heva LAN-adapteren i staden når same rekkjefølgje frå den andre sida: 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 berre rører IPv4.

Bindingsrekkjefølgja er siste utveg og ikkje første trekk. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage held ei Bind-liste over einingidentifikatorar, og å flytta tunnelidentifikatoren framover endrar faktisk kva adapter som blir spurd først, men det er ein maskinvid registerverdi utan omfang per namnerom. Eksporter han før du redigerer, og kople tunnelen til på nytt etterpå, slik at rekkjefølgja gjeld i den tilstanden klienten ventar.

For eitt namnerom, føretrekk det smalare verktøyet:

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

Avgjerd tre: overlever rettinga ei attilkopling?

Ein metrikk som verkar til neste oppringde tilkopling vart aldri lagra. L2TP/IPsec og andre tilkoplingsprofilar blir oppretta på nytt når tilkoplinga startar, så den lagra verdien lever i telefonbokoppføringa som IpInterfaceMetric, ikkje berre på det levande grensesnittet. Nokre miljø skriptar det feltet nettopp av denne grunnen; andre skyv preferansen frå ein administrasjonspolicy og lèt endepunktet vera.

Cache og registrering er eit eige lag. Å køyre desse etter at tunnelen er oppe rettar utdaterte oppføringar og registrerer klienten på nytt, men ingen av dei omordnar ein adapter:

ipconfig /registerdns
ipconfig /flushdns

Det finst ein avbrytar i same lag. Å slå av dynamisk registrering på den fysiske adapteren hindrar klienten i å annonsera si VPN-sideadresse under feil namn, og det er ei anna retting enn oppdateringa ovanfor.

IPv6 fortener si eiga linje i avgjerda. Viss den fysiske adapteren har ei global IPv6-adresse medan tunnelen berre ber IPv4, kan Windows føretrekka den tunnelfrie vegen for namneoppløysing. Sjekk den familien separat, fordi ein metrikk sett for IPv4 ikkje seier noko om henne:

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

Å slå av IPv6 på LAN-adapteren fjernar den vegen og protokollen med han; ei metrikkendring på IPv6-grensesnittet, eller ein NRPT-regel for bedriftsnamnerommet, held på familien og rettar preferansen. Vel den smalare, med mindre du har avgjort at den lenkja ikkje skal ha IPv6.

Stadfest med kjelda nemnd, og hald éin eigar

Stadfest med verktøy som rapporterer kva kjelde som er i kraft, ikkje berre om ei side lastar:

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

Skil så filtrering frå utval, fordi dei ser identiske ut innanfrå ein applikasjon. block-outside-dns i OpenVPN blokkerer port 53 på dei andre adapterane; han vel ikkje resolver. Viss kvar spørjing no feilar, kan eit filter blokkera den einaste tilgjengelege tenaren; viss den konfigurerte resolveren blir ignorert, er rekkjefølgja eller namneromsregelen feil. Å endra begge samstundes gjer ei blokkert spørjing og ei ignorert spørjing umoglege å skilja.

Hald éin eigar av DNS-policyen: VPN-profilen, ein administrasjonspolicy eller ein NRPT-regel, ikkje to av dei. Før du lukkar saka:

• Den utskutte resolveren svarar når han blir nemnd eksplisitt, og eit vanleg oppslag brukar han.
• Regelen eller metrikken du endra dekkjer adressefamilien som faktisk ber spørjingane.
• Innstillinga overlever fråkopling og attilkopling, eller du har flytta henne inn i den lagra profilen.
• Nøyaktig éin mekanisme er autoritativ, og dei andre er latne som dei var.

Handsam rekkjefølgja som miljøtilstand og ikkje som noko du fullfører. Sjekk henne på nytt etter ei attilkopling og etter ei Windows-oppdatering som rører nettverksstakken, fordi begge kan setja den fysiske adapteren framanfor att.