Hvem anvender egentlig OpenConnect-DNS-indstillingerne på Windows?

At rejse tunnelen er ikke det samme som at installere dens DNS-værdier. OpenConnect forhandler, og en hjælper på Windows-siden anvender. Kløften mellem de to trin forklarer de fleste fejl med private navne på denne klient, og hjælperen er næsten aldrig Windows’ VPN-indstillingsside.

Adskil hvad gatewayen tilbød fra hvad Windows installerede

Klienten giver forbindelsesdata videre til en scriptgrænseflade, og Unix- og Windows-varianterne er separate programmer. På Windows er implementeringen normalt en JavaScript-hjælper, der læser variabler som den interne DNS-server og det interne domæne, før den rører nogen adapter. Intet i selve tunnelen skriver resolvertilstand.

Den opdeling betyder noget, fordi en værdi kan findes i forhandlingen og aldrig nå adapteren. En hjælper, der mangler, fejler halvvejs eller er en ældre kopi indbygget i en GUI-indpakning, efterlader Windows præcis som det var. Sessionen ser forbundet ud, det private navn slås stadig op via den lokale udbyder, og intet i klientvinduet antyder forskellen. At læse hjælperens eget output er den eneste pålidelige måde at finde ud af, hvilket trin der brød.

En GUI-indpakning kan levere sin egen kopi af klienten og hjælperen, så en anden openconnect.exe et andet sted på disken beviser intet. Find den eksekverbare fil, der startede sessionen, før du bedømmer dens konfiguration.

Læs resolvertilstanden uden at ændre den

Tre skrivebeskyttede forespørgsler dækker den sædvanlige forvirring, og hver besvarer et forskelligt spørgsmål:

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

En server på adapterniveau er det, de fleste mener med VPN-DNS. Et forbindelsesspecifikt suffiks afgør, om et kort navn overhovedet udvides. Navnerumspolitiklisten gælder for matchende navne uanset adapterrækkefølge, og et tomt resultat der er ikke en fejl, når hjælperen aldrig havde til hensigt at oprette en. At læse alle tre før redigering er det, der forhindrer en rettelse, som blot flytter symptomet et andet sted hen.

Start med det fuldt kvalificerede navn. Hvis FQDN slås op, og det korte navn ikke gør, er suffikset eller søgelisten hullet og ikke serveradressen.

Spørg den tilsigtede server direkte som andet trin, med hvilket som helst allerede installeret resolverværktøj. Et direkte svar beviser, at serveren er tilgængelig og autoritativ for zonen. Det beviser intet om, hvilken server et program spørger som standard.

Navngiv den komponent, der ejer forbindelsen

To ordninger er almindelige. En klient startet fra en terminal sender sin scriptsti eksplicit, så ejeren er synlig i den kommando, der blev kørt. Et pakket program starter klienten for dig og holder hjælperen i sin egen mappe, hvilket betyder, at leverandøren bestemmer, hvornår den ændres.

Sammenlign hjælperversioner på tværs af installationer, før du bytter noget ud. At køre en hjælper hentet fra et spejl med forhøjede rettigheder, fordi filnavnet ser bekendt ud, gør et DNS-hul til en sikkerhedshændelse.

Når ejeren er kendt, bliver reparationsmålet indlysende: en understøttet scriptsti i starteren, en pakkeopdatering eller en rettet profil på gatewayen. Ingen af dem kræver, at du redigerer adapteregenskaber manuelt.

Ret ejeren, ikke adapteren

Manuelt indstillet adapter-DNS overlever ofte afbrydelse, og derfor ser det ud til at virke og skaber så problemer på det næste netværk. En offentlig resolver boltet på hver grænseflade skjuler problemet med det private navnerum i stedet for at løse det. Når hjælperen aldrig modtog en DNS-værdi, er gatewayprofilen stedet at kigge. Når den modtog en, og adapteren stadig viser den gamle server, fejlede hjælperen under forbindelsen, og klientloggen registrerer det normalt nær tunnelopsætningslinjerne.

Genopbyg tilstanden ad den understøttede vej, og verificér derefter en hel cyklus: forbind, slå den private FQDN op, åbn tjenesten, afbryd, og bekræft at adapteren kom tilbage med sine tidligere servere.

Kontrollér det program, der faktisk fejler

En browser med sin egen krypterede DNS-indstilling ignorerer alt ovenstående og svarer fortsat fra en offentlig resolver. Et program, der holder et cachet negativt svar fra før tunnelen kom op, opfører sig på samme måde. Sammenlign det med en almindelig systemforespørgsel på samme maskine, før du ændrer resolveradresser igen.

Hvis systemforespørgslen er rigtig, og programmet er forkert, sidder den resterende fejl i det programs DNS-konfiguration, ikke i VPN-stien.