Hvorfor Windows sender VPN-navnene dine til en DNS-server du aldri har satt opp

Du setter DNS-serveren på VPN-adapteren, kobler til på nytt, og det private navnet kommer fortsatt fra kontorresolveren som ingen har konfigurert på denne maskinen. Resultatet ser ut som om innstillingen ble ignorert, og på sett og vis ble den det, fordi adapterlisten er et sett med kandidater og ikke en beslutning. Windows løser navn gjennom en navneromspolicy som kan peke ut en annen server for et bestemt suffiks, og den policyen brukes før adapterinnstillingen blir vurdert. Å finne regelen som vant er en jobb på fem minutter når du vet hvilken tabell du skal lese.

Hva du endret, og hva som faktisk bestemmer

DNS-adressen på en adapter forteller klienten hvor det grensesnittet kunne sende spørringer. Tabellen for navnepolicy forteller klienten hvor den må sende spørringer for et gitt navnerom, og den vurderes per navn, ikke per adapter. Når en regel passer til suffikset du skrev, brukes reglens servere, og adapterlisten slutter å bety noe for det oppslaget.

Det er derfor to navn på samme maskin kan følge ulike veier i samme øyeblikk. En vert under bedriftssuffikset følger regelen sin; et offentlig navn følger standardveien, som vanligvis betyr adapteren som svarer først.

Hvordan tabellen matcher et navn

Regler er nøklet etter navnerom, og den mest spesifikke treffen vinner. En regel for corp.example gjelder for vpn.corp.example og gjelder ikke for example.net. En regel med navnerommet . dekker alt de andre reglene ikke dekker, noe som gjør den til den farligste oppføringen på listen og den som er verdt å sjekke når et urelatert nettsted løses gjennom tunnelen.

En regel kan også bære en kommentar, en policy som deaktiverer oppføringen, og sikkerhetsinnstillinger som ikke har noe med DNS-adresser å gjøre. En deaktivert regel forblir synlig i konfigurasjonen uten å ha effekt, så en oppføring som ser riktig ut på papiret kan fortsatt være inaktiv etter en profilendring.

Les den effektive tabellen, ikke ønskelisten

Konfigurerte regler og effektive regler er to forskjellige spørsmål. Get-DnsClientNrptRule lister opp hva som finnes på maskinen. Get-DnsClientNrptPolicy -Effective viser hva klienten faktisk vil bruke, med verdiene slått sammen fra policy og lokale innstillinger.

Sammenlign suffikset i den utdataen med navnet du tester, tegn for tegn. En regel for corp.example fanger ikke et navn som slutter på corp.example.com, og et punktum til slutt ett sted og ikke et annet er nok til å endre treffet.

Uten regel spør Windows mer enn én adapter

Når ingenting i tabellen gjør krav på navnet, kan klienten sende spørringen ut gjennom flere grensesnitt og ta det første svaret som kommer. Resultatet avhenger av tidspunktet: samme navn kan løses fra den kablede adapteren på mandag og fra tunnelen på tirsdag, og ingenting i konfigurasjonen til noen av adapterne forklarer forskjellen.

Det finnes to veier ut. Legg til en regel for navnerommet slik at beslutningen slutter å være et kappløp, eller slå av den parallelle oppførselen gjennom DNS-klientpolicyen og godta den langsommere, deterministiske oppløsningen. Den første passer vanligvis bedre for en VPN med delt tunnel, fordi den dokumenterer hensikten i stedet for å stole på rekkefølgen.

Veier som hopper over resolveren helt

En nettleser med sikker DNS aktivert løser selv og gir Windows bare adressen, så regeltabellen ser aldri navnet. Klienter bygget på kjøretidsmiljøer med egen resolver kan oppføre seg på samme måte. Når et navn løses i én applikasjon og feiler i en annen på samme maskin, sammenlign de to oppløsningsveiene før du rører policyen.

Sjekk også om appen kobler til en hurtiglagret adresse fra en tidligere økt. Clear-DnsClientCache og deretter samme oppslag gir et renere svar enn å slutte det fra et gammelt resultat.

Test med navnet som feilet

Løs det nøyaktige vertsnavnet fra rapporten, ikke et offentlig hastighetstestdomene, og noter hvilken server som svarte. Endre så én ting: regelen, adapterlisten eller policytildelingen, og gjenta det samme oppslaget etter en ny tilkobling slik at den brukte tilstanden bygges opp på nytt.

Hvis navnet løses og tjenesten fortsatt avviser, slutt å redigere DNS. Neste nyttige steg er adressen og ruten dit, fordi navneoppløsningen allerede har gjort jobben sin.