Du set DNS-tenaren på VPN-adapteren, koplar til på nytt, og det private namnet kjem framleis frå kontortenaren som ingen har konfigurert på denne maskina. Resultatet ser ut som om innstillinga vart ignorert, og på sett og vis vart ho det, fordi adapterlista er eit sett med kandidatar og ikkje eit vedtak. Windows løyser namn gjennom ein namneromspolicy som kan peike ut ein annan tenar for eit bestemt suffiks, og den policyen vert brukt før adapterinnstillinga vert vurdert. Å finne regelen som vann er ein jobb på fem minutt når du veit kva tabell du skal lese.

Kva du endra, og kva som faktisk avgjer

DNS-adressa på ein adapter fortel klienten kvar det grensesnittet kunne sende spørjingar. Tabellen for namneromspolicy fortel klienten kvar han må sende spørjingar for eit gitt namnerom, og han vert vurdert per namn, ikkje per adapter. Når ein regel passar til suffikset du skreiv, vert tenarane til regelen brukte, og adapterlista sluttar å ha noko å seie for den oppslaget.

Det er derfor to namn på same maskin kan følgje ulike vegar i same augneblink. Ein vert under verksemdssuffikset følgjer regelen sin; eit offentleg namn følgjer standardvegen, som vanlegvis tyder adapteren som svarar først.

Korleis tabellen matchar eit namn

Reglar er nøkla etter namnerom, og den mest spesifikke treffet vinn. Ein regel for corp.example gjeld for vpn.corp.example og gjeld ikkje for example.net. Ein regel med namnerommet . dekkjer alt dei andre reglane ikkje dekkjer, noko som gjer han til den farlegaste oppføringa på lista og den som er verdt å sjekke når ein urelatert stad vert løyst gjennom tunnelen.

Ein regel kan også bere ein kommentar, ein policy som deaktiverer oppføringa, og tryggleiksinnstillingar som ikkje har noko med DNS-adresser å gjere. Ein deaktivert regel blir verande synleg i konfigurasjonen utan å ha effekt, så ei oppføring som ser rett ut på papiret kan framleis vere inaktiv etter ei profilendring.

Les den verknadsfulle tabellen, ikkje ønskjelista

Konfigurerte reglar og verknadsfulle reglar er to ulike spørsmål. Get-DnsClientNrptRule listar opp kva som finst på maskina. Get-DnsClientNrptPolicy -Effective viser kva klienten faktisk vil bruke, med verdiane slått saman frå policy og lokale innstillingar.

Samanlikn suffikset i den utdataen med namnet du testar, teikn for teikn. Ein regel for corp.example fangar ikkje eit namn som sluttar på corp.example.com, og eit punktum til slutt på ein stad og ikkje ein annan er nok til å endre treffet.

Utan regel spør Windows meir enn éin adapter

Når ingenting i tabellen gjer krav på namnet, kan klienten sende spørjinga ut gjennom fleire grensesnitt og ta det første svaret som kjem. Resultatet avheng av tidspunktet: same namn kan løysast frå den kablede adapteren på måndag og frå tunnelen på tysdag, og ingenting i konfigurasjonen til nokon av adapterane forklarar skilnaden.

Det finst to vegar ut. Legg til ein regel for namnerommet slik at vedtaket sluttar å vere eit kapplaup, eller slå av den parallelle oppførselen gjennom DNS-klientpolicyen og godta den seinare, deterministiske løysinga. Den første passar vanlegvis betre for ein VPN med delt tunnel, fordi han dokumenterer hensikta i staden for å stole på rekkjefølgja.

Vegar som hoppar over resolvaren heilt

Ein nettlesar med sikker DNS påslått løyser sjølv og gir Windows berre adressa, så regeltabellen ser aldri namnet. Klientar bygde på køyretidsmiljø med eigen resolvar kan oppføre seg på same måte. Når eit namn vert løyst i éin applikasjon og feilar i ein annan på same maskin, samanlikn dei to løysingsvegane før du rører policyen.

Sjekk også om appen koplar til ei hurtiglagra adresse frå ei tidlegare økt. Clear-DnsClientCache og deretter same oppslag gir eit reinare svar enn å slutte det frå eit gammalt resultat.

Test med namnet som feila

Løys det nøyaktige vertsnamnet frå rapporten, ikkje eit offentleg hastigheitstestdomene, og noter kva tenar som svara. Endre så éin ting: regelen, adapterlista eller policytildelinga, og gjer om den same oppslaget etter ei ny tilkopling slik at den brukte tilstanden vert bygd opp på nytt.

Viss namnet vert løyst og tenesta framleis avviser, slutt å redigere DNS. Neste nyttige steg er adressa og ruta dit, fordi namneløysinga allereie har gjort jobben sin.

Relaterte artiklar