Vem tillämpar egentligen OpenConnects DNS-inställningar på Windows?

Att resa tunneln är inte samma sak som att installera dess DNS-värden. OpenConnect förhandlar, och en hjälpare på Windows-sidan tillämpar. Gapet mellan de två stegen förklarar de flesta fel med privata namn på den här klienten, och hjälparen är nästan aldrig Windows VPN-inställningssida.

Skilj det gatewayen erbjöd från det Windows installerade

Klienten lämnar anslutningsdata till ett skriptgränssnitt, och Unix- och Windows-varianterna är separata program. På Windows är implementeringen oftast en JavaScript-hjälpare som läser variabler som den interna DNS-servern och den interna domänen innan den rör någon adapter. Ingenting i själva tunneln skriver resolvertillstånd.

Den uppdelningen spelar roll eftersom ett värde kan finnas i förhandlingen och aldrig nå adaptern. En hjälpare som saknas, misslyckas halvvägs eller är en äldre kopia inbäddad i ett GUI-omslag lämnar Windows precis som det var. Sessionen ser ansluten ut, det privata namnet löses fortfarande via den lokala leverantören, och ingenting i klientfönstret antyder skillnaden. Att läsa hjälparens egen utdata är det enda tillförlitliga sättet att ta reda på vilket steg som gick sönder.

Ett GUI-omslag kan leverera sin egen kopia av klienten och hjälparen, så en andra openconnect.exe någon annanstans på disken bevisar ingenting. Hitta den körbara filen som startade sessionen innan du bedömer dess konfiguration.

Läs resolverns tillstånd utan att ändra det

Tre skrivskyddade frågor täcker den vanliga förvirringen, och var och en svarar på en annan fråga:

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effective

En server på adapternivå är vad de flesta menar med VPN-DNS. Ett anslutningsspecifikt suffix avgör om ett kort namn alls utökas. Namnrymdspolicylistan gäller för matchande namn oavsett adapterordning, och ett tomt resultat där är inte ett fel när hjälparen aldrig avsåg att skapa ett. Att läsa alla tre före redigering är det som förhindrar en reparation som bara flyttar symptomet någon annanstans.

Börja med det fullt kvalificerade namnet. Om FQDN löses och kortnamnet inte, är suffixet eller söklistan gapet och inte serveradressen.

Fråga den avsedda servern direkt som ett andra steg, med vilket redan installerat resolververktyg som helst. Ett direkt svar bevisar att servern är nåbar och auktoritativ för zonen. Det bevisar ingenting om vilken server ett program frågar som standard.

Namnge komponenten som äger anslutningen

Två upplägg är vanliga. En klient som startas från en terminal skickar sin skriptsökväg explicit, så ägaren syns i kommandot som kördes. Ett paketerat program startar klienten åt dig och håller hjälparen i sin egen katalog, vilket betyder att leverantören bestämmer när den ändras.

Jämför hjälparversioner mellan installationer innan du byter något. Att köra en hjälpare hämtad från en spegel med förhöjda rättigheter för att filnamnet ser bekant ut gör ett DNS-gap till en säkerhetsincident.

När ägaren är känd blir reparationsmålet uppenbart: en stödd skriptsökväg i startaren, en paketuppdatering eller en rättad profil på gatewayen. Ingen av dem kräver att du redigerar adapteregenskaper för hand.

Reparera ägaren, inte adaptern

Manuellt inställd adapter-DNS överlever ofta frånkoppling, vilket är varför det verkar fungera och sedan ställer till problem i nästa nätverk. En offentlig resolver fastskruvad på varje gränssnitt döljer problemet med den privata namnrymden i stället för att lösa det. När hjälparen aldrig fick ett DNS-värde är gatewayprofilen stället att titta på. När den fick ett och adaptern fortfarande visar den gamla servern misslyckades hjälparen under anslutningen, och klientloggen brukar registrera det nära tunnelinställningsraderna.

Bygg upp tillståndet igen via den stödda vägen och verifiera sedan en hel cykel: anslut, lös det privata FQDN, öppna tjänsten, koppla från och bekräfta att adaptern kom tillbaka med sina tidigare servrar.

Kontrollera programmet som faktiskt misslyckas

En webbläsare med sin egen krypterade DNS-inställning ignorerar allt ovan och fortsätter svara från en offentlig resolver. Ett program som håller ett cachat negativt svar från innan tunneln restes beter sig på samma sätt. Jämför det med en vanlig systemfråga på samma maskin innan du ändrar resolveradresser igen.

Om systemfrågan är rätt och programmet fel sitter det kvarvarande felet i det programmets DNS-konfiguration, inte i VPN-vägen.