Hvorfor Windows sender dine VPN-navne til en DNS-server, du aldrig har sat op

Du sætter DNS-serveren på VPN-adapteren, genopretter forbindelsen, og det private navn kommer stadig tilbage fra kontorets resolver, som ingen har konfigureret på denne bærbare. Resultatet ser ud, som om indstillingen blev ignoreret, og det blev den til en vis grad, fordi adapterlisten er et sæt kandidater og ikke en beslutning. Windows opløser navne gennem en navnerumspolitik, der kan udpege en anden server til et bestemt suffiks, og den politik anvendes, før adapterindstillingen bliver spurgt. At finde den regel, der vandt, er et arbejde på fem minutter, når du ved, hvilken tabel du skal læse.

Hvad du ændrede, og hvad der faktisk afgør

DNS-adressen på en adapter fortæller klienten, hvor den grænseflade kunne sende forespørgsler hen. Name Resolution Policy Table fortæller klienten, hvor den skal sende forespørgsler for et givet navnerum, og den vurderes per navn, ikke per adapter. Når en regel matcher det suffiks, du skrev, bruges reglens servere, og adapterlisten holder op med at betyde noget for det opslag.

Det er derfor, to navne på samme bærbare kan følge forskellige veje i samme øjeblik. En vært under virksomhedssuffikset følger sin regel; et offentligt navn følger standardvejen, hvilket normalt betyder den adapter, der svarer først.

Hvordan tabellen matcher et navn

Regler er nøglet efter navnerum, og det mest specifikke match vinder. En regel for corp.example gælder for vpn.corp.example og gælder ikke for example.net. En regel med navnerummet . dækker alt, hvad de andre regler ikke dækker, hvilket gør den til den farligste post på listen og den, der er værd at kontrollere, når et uvedkommende websted opløses gennem tunnelen.

En regel kan også bære en kommentar, en politik der deaktiverer posten, og sikkerhedsindstillinger, der intet har med DNS-adresser at gøre. En deaktiveret regel forbliver synlig i konfigurationen uden at have effekt, så en post, der ser rigtig ud på papiret, kan stadig være inaktiv efter en profilændring.

Læs den effektive tabel, ikke ønskelisten

Konfigurerede regler og effektive regler er to forskellige spørgsmål. Get-DnsClientNrptRule viser, hvad der findes på maskinen. Get-DnsClientNrptPolicy -Effective viser, hvad klienten faktisk vil anvende, med værdierne sammenflettet fra politik og lokale indstillinger.

Sammenlign suffikset i det output med det navn, du tester, tegn for tegn. En regel for corp.example fanger ikke et navn, der ender på corp.example.com, og et punktum til sidst ét sted og ikke det andet er nok til at ændre matchningen.

Uden en regel spørger Windows mere end én adapter

Når intet i tabellen gør krav på navnet, kan klienten sende forespørgslen ud gennem flere grænseflader og tage det første svar, der ankommer. Resultatet afhænger af timingen: det samme navn kan opløses fra den kablede adapter om mandagen og fra tunnelen om tirsdagen, og intet i nogen af adapterens konfigurationer forklarer forskellen.

Der er to udveje. Tilføj en regel for navnerummet, så beslutningen holder op med at være et kapløb, eller slå den parallelle adfærd fra gennem DNS-klientpolitikken og accepter den langsommere, deterministiske opløsning. Den første passer normalt bedre til en VPN med opdelt tunnel, fordi den dokumenterer hensigten i stedet for at stole på rækkefølgen.

Veje der springer resolveren helt over

En browser med sikker DNS aktiveret opløser selv og giver kun Windows adressen, så regeltabellen ser aldrig navnet. Klienter bygget på runtime-miljøer med deres egen resolver kan opføre sig på samme måde. Når et navn opløses i én applikation og fejler i en anden på samme maskine, skal du sammenligne de to opløsningsveje, før du rører politikken.

Kontrollér også, om appen forbinder til en cachelagret adresse fra en tidligere session. Clear-DnsClientCache og derefter det samme opslag giver et renere svar end at slutte sig til det ud fra et gammelt resultat.

Test med det navn, der fejlede

Opløs det præcise værtsnavn fra rapporten, ikke et offentligt hastighedstestdomæne, og notér, hvilken server der svarede. Skift derefter én ting: reglen, adapterlisten eller politikktildelingen, og gentag det identiske opslag efter en genoprettet forbindelse, så den anvendte tilstand genopbygges.

Hvis navnet opløses, og tjenesten stadig afviser, skal du holde op med at redigere DNS. Det næste nyttige skridt er adressen og ruten dertil, fordi navneopløsningen allerede har gjort sit arbejde.