Varför Windows skickar dina VPN-namn till en DNS-server du aldrig har ställt in

Du ställer in DNS-servern på VPN-adaptern, ansluter igen, och det privata namnet kommer fortfarande från kontorets resolver som ingen har konfigurerat på den här datorn. Resultatet ser ut som att inställningen ignorerades, och på sätt och vis gjorde den det, eftersom adapterlistan är en uppsättning kandidater och inte ett beslut. Windows löser namn genom en namnrymdspolicy som kan peka ut en annan server för ett visst suffix, och den policyn tillämpas innan adapterinställningen beaktas. Att hitta regeln som vann är ett jobb på fem minuter när du vet vilken tabell du ska läsa.

Vad du ändrade, och vad som faktiskt avgör

DNS-adressen på en adapter talar om för klienten vart det gränssnittet kan skicka frågor. Tabellen för namnupplösningspolicy talar om för klienten vart den måste skicka frågor för en viss namnrymd, och den utvärderas per namn, inte per adapter. När en regel matchar suffixet du skrev används regelns servrar och adapterlistan slutar spela roll för den uppslagningen.

Det är därför två namn på samma dator kan följa olika vägar i samma ögonblick. En värd under företagssuffixet följer sin regel; ett offentligt namn följer standardvägen, vilket oftast betyder den adapter som svarar först.

Hur tabellen matchar ett namn

Regler nycklas efter namnrymd, och den mest specifika träffen vinner. En regel för corp.example gäller för vpn.corp.example och gäller inte för example.net. En regel med namnrymden . täcker allt de andra reglerna inte täcker, vilket gör den till den farligaste posten på listan och den som är värd att kontrollera när en orelaterad webbplats löses genom tunneln.

En regel kan också bära en kommentar, en policy som inaktiverar posten, och säkerhetsinställningar som inte har något med DNS-adresser att göra. En inaktiverad regel förblir synlig i konfigurationen utan att ha effekt, så en post som ser rätt ut på papperet kan fortfarande vara verkningslös efter en profiländring.

Läs den effektiva tabellen, inte önskelistan

Konfigurerade regler och effektiva regler är två olika frågor. Get-DnsClientNrptRule listar vad som finns på datorn. Get-DnsClientNrptPolicy -Effective visar vad klienten faktiskt kommer att använda, med värdena sammanfogade från policy och lokala inställningar.

Jämför suffixet i den utdata med namnet du testar, tecken för tecken. En regel för corp.example fångar inte ett namn som slutar på corp.example.com, och en punkt i slutet på ett ställe och inte på det andra räcker för att ändra träffen.

Utan regel frågar Windows fler än en adapter

När inget i tabellen gör anspråk på namnet kan klienten skicka frågan genom flera gränssnitt och ta det första svaret som kommer. Resultatet beror på timingen: samma namn kan lösas från den trådbundna adaptern på måndagen och från tunneln på tisdagen, och inget i någon adapters konfiguration förklarar skillnaden.

Det finns två vägar ut. Lägg till en regel för namnrymden så att beslutet inte längre är en kapplöpning, eller stäng av det parallella beteendet via DNS-klientpolicyn och acceptera den långsammare, deterministiska upplösningen. Den första passar oftast bättre för ett VPN med delad tunnel, eftersom den dokumenterar avsikten i stället för att lita på ordningen.

Vägar som hoppar över resolvern helt

En webbläsare med säkert DNS aktiverat löser själv och ger Windows bara adressen, så regeltabellen ser aldrig namnet. Klienter byggda på körmiljöer med egen resolver kan bete sig på samma sätt. När ett namn löses i en applikation och misslyckas i en annan på samma maskin, jämför de två upplösningsvägarna innan du rör policyn.

Kontrollera också om appen ansluter till en cachad adress från en tidigare session. Clear-DnsClientCache och sedan samma uppslag ger ett renare svar än att sluta sig till det från ett gammalt resultat.

Testa med namnet som misslyckades

Lös det exakta värdnamnet från rapporten, inte en offentlig hastighetstestdomän, och notera vilken server som svarade. Ändra sedan en sak: regeln, adapterlistan eller policytilldelningen, och upprepa samma uppslag efter en ny anslutning så att det tillämpade tillståndet byggs upp igen.

Om namnet löses och tjänsten fortfarande vägrar, sluta redigera DNS. Nästa användbara steg är adressen och vägen dit, eftersom namnupplösningen redan har gjort sitt jobb.