Ändrade VPN:en min DNS? Jämför före och efter
En profil kan flytta dina uppslag med avsikt. Jämför resolverpolicyn och det faktiska svaret före och efter att en VPN ansluter, och håll en variabel fast.
Du ansluter tunneln, öppnar en privat instrumentpanel och namnet löses till en adress du aldrig sett. Eller så händer motsatsen: webbläsaren fortsätter att fungera medan ett kommandoradsverktyg plötsligt inte löser något. Båda resultaten kommer från samma ändring, och folk förklarar det vanligtvis med en mening om VPN:en som ”använder sin egen DNS”, vilket inte är tillräckligt exakt för att felsöka eller verifiera. I den meningen gömmer sig två frågor: vilka uppslag ska den här profilen ta över, och skickade din maskin dem verkligen till resolvern den fick? Att hålla dem åtskilda är hela metoden, för ett test som blandar dem ger ett självsäkert fel svar i båda riktningarna.
Varför en profil överhuvudtaget levererar en resolver
Inuti en tunnel löses namn bakom den bortre änden vanligtvis till adresser som bara finns i det nätverket. En privat zon som corp.internal har ingen offentlig delegering, så resolvern som svarar på den måste vara nåbar inifrån tunneln. Samma mekanism tjänar ett andra syfte: när uppslag annars skulle gå ut via din leverantör håller en resolver på den bortre sidan frågan kvar inne i den krypterade vägen. Därför kommer DNS-serverns adress som en del av anslutningens policy och inte som en global inställning du valde en gång för maskinen.
Adressen ensam avgör ingenting. En resolver kan bara svara om det finns en väg till den, och det vanligaste felet är en resolver som bara är nåbar medan tunneln är uppe. När tunneln faller och policyn ligger kvar går uppslagen till en adress utan väg, och symptomet är en timeout snarare än ett rent fel. Den skillnaden spelar roll när du läser nästa testresultat, för en timeout skickar folk in i transportinställningar som aldrig var inblandade.
Jämför de två designerna innan du jämför svar
Full tunnel och delad DNS ger motsatta förväntningar, och ingen av dem är ett fel. Under en full tunnel kan varje uppslag flytta till leverantören eller till företagets resolver, så att offentliga namn svarar annorlunda efter anslutning är väntat. Under delad DNS går bara de listade domänerna till den privata resolvern medan allt annat stannar lokalt; i Windows bor domänlistan i Name Resolution Policy Table, i macOS i DNS-inställningarnas matchande domäner, och på en systemd-resolved-värd i routingdomäner per länk.
Det är jämförelsen som måste göras först, eftersom den avgör vad som räknas som ett fel. Med delad DNS är ett offentligt namn som svarar från en ny resolver det som är värt att undersöka, medan ett internt namn som svarar korrekt är systemet som gör sitt jobb. Med full tunnel är anomalin ett offentligt namn som fortfarande svarar från din leverantörs resolver. Microsofts dokumentation om VPN-namnlösning beskriver Windows-ordningen för dessa regler, inklusive hur en matchande policyrad konsulteras före adapterns egna servrar.
Det finns en tredje resolver i rummet som är lätt att glömma. Webbläsarens säkra DNS löser namn på egen hand och kan fortsätta svara efter att tunneln ändrat operativsystemets policy, så en sida som laddas bevisar att webbläsarens resolver fungerade, inte att profilen tillämpades. Om du bara jämför det webbläsaren visar testar du fel lager halva tiden.
Registrera en baslinje med bara en variabel
Ändra tunneln. Ändra inte också namnet, verktyget eller sökändelsen i samma steg. Välj ett namn du får fråga om, notera vilken applikation du använde och skriv ned antingen adressen som kom tillbaka eller det exakta felet. I Windows skriver Get-DnsClientServerAddress -AddressFamily IPv4 ut servrarna per adapter och Get-DnsClientNrptPolicy skriver ut policyraderna; i Linux med systemd-resolved visar resolvectl status DNS-servrar och routingdomäner per länk; i macOS skriver scutil --dns ut resolverordningen som systemet faktiskt följer.
Anslut sedan via klientens vanliga kontroller och upprepa exakt samma kommandon. Behåll den första utskriften i stället för ett minne av den, för jämförelsen är hela poängen och en andra läsning efter tömning av cachen är redan en annan mätning. Om baslinjen togs med webbläsaren framme och körningen efter anslutning sker i en terminal, jämför du två resolvers, inte två tillstånd av en resolver.
En uttrycklig fråga och ett applikationsuppslag är olika tester
Att fråga en specifik server, med nslookup name 10.20.0.1 eller dig @10.20.0.1 name, bevisar en enda sak: att servern du namngav svarar när du kan nå den. Det kringgår valet helt, så det kan inte säga om systemet skulle ha valt den servern för detta namn. Använd det för att testa om den tilldelade resolvern är nåbar, och använd det inte för att testa policy.
Ett uppslag via den lokala resolvern utövar faktiskt val. resolvectl query name går igenom samma routingdomänregler och rapporterar vilket protokoll som svarade, Resolve-DnsName i Windows går genom policytabellen och klientens cache, och scutil --dns visar den ordning ett uppslag skulle följa. Kör båda slagen och håll dem i separata kolumner i dina anteckningar. En lyckad uttrycklig fråga intill ett misslyckat applikationsuppslag är ett routing- eller valproblem, inte en resolver som vägrar arbeta.
Cachen står mellan dig och svaret. Operativsystemet, den lokala stub-resolvern, webbläsaren och negativ cachning håller alla resultat, så ett uppslag kan lyckas utan att ett enda paket lämnar maskinen. Registrera resultatet innan du tömmer något: ipconfig /flushdns, resolvectl flush-caches eller sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder i macOS. Hoppa över den breda nätverksåterställningen i detta skede, eftersom den förstör bevisen du fortfarande samlar in.
Vad skillnaden betyder
Jämför de två registrerade raderna och klassificera ändringen innan du rör en enda inställning.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
En rad förtjänar betoning. Ett namn som löses är inte en tjänst som fungerar, och DNS-framgång säger bara att en adress hittades. Det säger ingenting om vidarebefordran, brandväggsregler eller om ditt konto ens får använda tjänsten, så avsluta med att testa den faktiska applikationen i stället för att anta att felet drog sig tillbaka av sig själv.
Återställ baslinjen och verifiera den
Koppla från via klientens egna kontroller i stället för att döda processen, och läs sedan om samma tre kommandon. Servrarna per länk, policyraderna och svaret för ditt testnamn bör återgå till baslinjen du skrev ned tidigare. En kvarvarande policyrad efter en ren frånkoppling är en verklig defekt värd att registrera, och det är också därför handredigering av en genererad resolverfil är en dålig vana: filen skrivs om och redigeringen försvinner, eller redigeringen överlever och fäster en resolver som inte längre har en väg.
Gå igenom den här listan en gång, i ordning. Bestäm vilken design profilen implementerar innan du bedömer något resultat. Håll namn, verktyg och ändelse fasta genom båda körningarna. Skilj den uttryckliga frågan från applikationsuppslaget. Läs den effektiva policyn, inte bara svaret. Töm cacharna sist, efter att jämförelsen skrivits ned. Verifiera med den riktiga applikationen, starta sedan om en gång och bekräfta att det frånkopplade tillståndet fortfarande är rent.