Hvem bruker egentlig OpenConnect-DNS-innstillingene på Windows?

Å reise tunnelen er ikke det samme som å installere DNS-verdiene dens. OpenConnect forhandler, og en hjelper på Windows-siden bruker dem. Gapet mellom disse to trinnene forklarer de fleste feil med private navn på denne klienten, og hjelperen er nesten aldri Windows’ VPN-innstillingsside.

Skill det gatewayen tilbød fra det Windows installerte

Klienten gir tilkoblingsdata til et skriptgrensesnitt, og Unix- og Windows-variantene er separate programmer. På Windows er implementasjonen vanligvis en JavaScript-hjelper som leser variabler som den interne DNS-serveren og det interne domenet før den berører noen adapter. Ingenting i selve tunnelen skriver resolvertilstand.

Denne delingen betyr noe fordi en verdi kan finnes i forhandlingen og aldri nå adapteren. En hjelper som mangler, feiler halvveis eller er en eldre kopi pakket inn i en GUI-innpakning, lar Windows være nøyaktig som det var. Økten ser tilkoblet ut, det private navnet løses fortsatt gjennom den lokale leverandøren, og ingenting i klientvinduet antyder forskjellen. Å lese hjelperens egen utdata er den eneste pålitelige måten å finne ut hvilket trinn som brøt.

En GUI-innpakning kan levere sin egen kopi av klienten og hjelperen, så en andre openconnect.exe et annet sted på disken beviser ingenting. Finn den kjørbare filen som startet økten før du vurderer konfigurasjonen.

Les resolvertilstanden uten å endre den

Tre skrivebeskyttede spørringer dekker den vanlige forvirringen, og hver svarer på et forskjellig spørsmål:

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

En server på adapternivå er det de fleste mener med VPN-DNS. Et tilkoblingsspesifikt suffiks avgjør om et kort navn i det hele tatt utvides. Navneromspolitikklisten gjelder for matchende navn uavhengig av adapterrekkefølge, og et tomt resultat der er ikke en feil når hjelperen aldri hadde til hensikt å opprette en. Å lese alle tre før redigering er det som forhindrer en reparasjon som bare flytter symptomet et annet sted.

Start med det fullt kvalifiserte navnet. Hvis FQDN løses og kortnavnet ikke, er suffikset eller søkelisten gapet og ikke serveradressen.

Spør den tiltenkte serveren direkte som et andre trinn, med hvilket som helst allerede installert resolververktøy. Et direkte svar beviser at serveren er tilgjengelig og autoritativ for sonen. Det beviser ingenting om hvilken server et program spør etter som standard.

Navngi komponenten som eier tilkoblingen

To ordninger er vanlige. En klient startet fra en terminal sender skriptbanen sin eksplisitt, så eieren er synlig i kommandoen som ble kjørt. Et pakket program starter klienten for deg og holder hjelperen i sin egen mappe, noe som betyr at leverandøren bestemmer når den endres.

Sammenlign hjelperversjoner på tvers av installasjoner før du bytter noe. Å kjøre en hjelper hentet fra et speil med forhøyede rettigheter fordi filnavnet ser kjent ut, gjør et DNS-gap til en sikkerhetshendelse.

Når eieren er kjent, blir reparasjonsmålet åpenbart: en støttet skriptbane i oppstarteren, en pakkeoppdatering eller en rettet profil på gatewayen. Ingen av dem krever at du redigerer adapteregenskaper manuelt.

Reparer eieren, ikke adapteren

Manuelt angitt adapter-DNS overlever ofte frakobling, og derfor ser det ut til å virke og skaper så problemer på det neste nettverket. En offentlig resolver boltet på hver grensesnitt skjuler problemet med det private navnerommet i stedet for å løse det. Når hjelperen aldri mottok en DNS-verdi, er gatewayprofilen stedet å se. Når den mottok en og adapteren fortsatt viser den gamle serveren, feilet hjelperen under tilkoblingen, og klientloggen registrerer det vanligvis nær tunneloppsettlinjene.

Bygg tilstanden på nytt via den støttede veien, og verifiser deretter en hel syklus: koble til, løs det private FQDN, åpne tjenesten, koble fra, og bekreft at adapteren kom tilbake med sine tidligere servere.

Kontroller programmet som faktisk feiler

En nettleser med sin egen krypterte DNS-innstilling ignorerer alt ovenfor og fortsetter å svare fra en offentlig resolver. Et program som holder et bufret negativt svar fra før tunnelen kom opp, oppfører seg på samme måte. Sammenlign det med en vanlig systemspørring på samme maskin før du endrer resolveradresser igjen.

Hvis systemspørringen er riktig og programmet er galt, sitter den gjenværende feilen i det programmets DNS-konfigurasjon, ikke i VPN-veien.