Kven brukar eigentleg OpenConnect-DNS-innstillingane på Windows?

Å reise tunnelen er ikkje det same som å installere DNS-verdiane hans. OpenConnect forhandlar, og ein hjelpar på Windows-sida brukar dei. Gapet mellom desse to trinna forklarer dei fleste feila med private namn på denne klienten, og hjelparen er nesten aldri Windows’ VPN-innstillingsside.

Skil det gatewayen baud på frå det Windows installerte

Klienten gir tilkoplingsdata til eit skriptgrensesnitt, og Unix- og Windows-variantane er separate program. På Windows er implementasjonen vanlegvis ein JavaScript-hjelpar som les variablar som den interne DNS-tenaren og det interne domenet før han rører nokon adapter. Ingenting i sjølve tunnelen skriv resolvertilstand.

Denne delinga betyr noko fordi ein verdi kan finnast i forhandlinga og aldri nå adapteren. Ein hjelpar som manglar, feilar halvvegs eller er ein eldre kopi pakka inn i ei GUI-innpakning, lèt Windows vere nøyaktig som det var. Økta ser tilkopia ut, det private namnet blir framleis løyst gjennom den lokale leverandøren, og ingenting i klientvindauget tyder på skilnaden. Å lese hjelparens eigen utdata er den einaste pålitelege måten å finne ut kva trinn som braut.

Ei GUI-innpakning kan levere sin eigen kopi av klienten og hjelparen, så ein andre openconnect.exe ein annan stad på disken beviser ingenting. Finn den køyrbare fila som starta økta før du vurderer konfigurasjonen.

Les resolvertilstanden utan å endre han

Tre skriveverna spørjingar dekkjer den vanlege forvirringa, og kvar svarar på eit ulikt spørsmål:

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

Ein tenar på adapternivå er det dei fleste meiner med VPN-DNS. Eit tilkoplingsspesifikt suffiks avgjer om eit kort namn i det heile blir utvida. Namneromspolitikklista gjeld for samsvarande namn uavhengig av adapterrekkjefølgje, og eit tomt resultat der er ikkje ein feil når hjelparen aldri hadde til hensikt å opprette eitt. Å lese alle tre før redigering er det som hindrar ein reparasjon som berre flyttar symptomet ein annan stad.

Start med det fullt kvalifiserte namnet. Viss FQDN blir løyst og kortnamnet ikkje, er suffikset eller søkelista gapet og ikkje tenaradressa.

Spør den tiltenkte tenaren direkte som eit andre trinn, med kva som helst allereie installert resolververktøy. Eit direkte svar beviser at tenaren er tilgjengeleg og autoritativ for sona. Det beviser ingenting om kva tenar eit program spør etter som standard.

Namngi komponenten som eig tilkoplinga

To ordningar er vanlege. Ein klient starta frå ein terminal sender skriptbanen sin eksplisitt, så eigaren er synleg i kommandoen som vart køyrd. Eit pakka program startar klienten for deg og held hjelparen i si eiga mappe, noko som betyr at leverandøren bestemmer når han blir endra.

Samanlikn hjelparversjonar på tvers av installasjonar før du byter noko. Å køyre ein hjelpar henta frå eit spegel med forhøgde rettar fordi filnamnet ser kjent ut, gjer eit DNS-gap til ein tryggingshending.

Når eigaren er kjend, blir reparasjonsmålet openbert: ein støtta skriptbane i oppstartaren, ei pakkeoppdatering eller ein retta profil på gatewayen. Ingen av dei krev at du redigerer adaptereigenskapar manuelt.

Reparer eigaren, ikkje adapteren

Manuelt sett adapter-DNS overlever ofte fråkopling, og difor ser det ut til å verke og skaper så problem på det neste nettet. Ein offentleg resolver bolta på kvart grensesnitt skjuler problemet med det private namnerommet i staden for å løyse det. Når hjelparen aldri fekk ein DNS-verdi, er gatewayprofilen staden å sjå. Når han fekk ein og adapteren framleis viser den gamle tenaren, feila hjelparen under tilkoplinga, og klientloggen registrerer det vanlegvis nær tunneloppsettlinjene.

Bygg tilstanden på nytt via den støtta vegen, og stadfest deretter ein heil syklus: kople til, løys det private FQDN, opne tenesta, kople frå, og stadfest at adapteren kom tilbake med dei tidlegare tenarane sine.

Kontroller programmet som faktisk feilar

Ein nettlesar med si eiga krypterte DNS-innstilling ignorerer alt ovanfor og held fram med å svare frå ein offentleg resolver. Eit program som held eit bufra negativt svar frå før tunnelen kom opp, oppfører seg på same måte. Samanlikn det med ei vanleg systemspørjing på same maskin før du endrar resolveradresser igjen.

Viss systemspørjinga er rett og programmet er gale, sit den attverande feilen i DNS-konfigurasjonen til det programmet, ikkje i VPN-vegen.