Kdo v Windows dejansko uporablja nastavitve DNS OpenConnect?

Dvigniti tunel ni isto kot namestiti njegove vrednosti DNS. OpenConnect se pogaja, pomočnik na strani Windows pa jih uporabi. Vrzel med tema dvema korakoma pojasnjuje večino napak z zasebnimi imeni pri tem odjemalcu, pomočnik pa skoraj nikoli ni stran z nastavitvami VPN v Windows.

Ločite, kaj je ponudil prehod, od tega, kar je namestil Windows

Odjemalec preda podatke o povezavi skriptnemu vmesniku, različici za Unix in Windows pa sta ločena programa. V Windows je izvedba običajno pomočnik JavaScript, ki prebere spremenljivke, kot sta notranji strežnik DNS in notranja domena, preden se dotakne katerega koli adapterja. Nič v samem tunelu ne zapisuje stanja razreševalnika.

Ta ločitev je pomembna, ker lahko vrednost obstaja v pogajanju in nikoli ne doseže adapterja. Pomočnik, ki manjka, se na pol poti ne uspe ali je starejša kopija, vgrajena v ovoj GUI, pusti Windows natanko takšne, kot so bili. Seja je videti povezana, zasebno ime se še vedno razrešuje prek lokalnega ponudnika in nič v oknu odjemalca ne kaže na razliko. Branje lastnega izhoda pomočnika je edini zanesljiv način, da ugotovite, katera stopnja se je zlomila.

Ovoj GUI lahko prinese svojo kopijo odjemalca in pomočnika, zato drugi openconnect.exe drugje na disku ne dokazuje ničesar. Poiščite izvršljivo datoteko, ki je zagnala sejo, preden ocenite njeno konfiguracijo.

Preberite stanje razreševalnika, ne da bi ga spremenili

Tri poizvedbe samo za branje pokrijejo običajno zmedo in vsaka odgovori na drugo vprašanje:

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

Strežnik na ravni adapterja je tisto, kar večina ljudi razume kot DNS VPN. Pripona, specifična za povezavo, odloči, ali se bo kratko ime sploh razširilo. Seznam pravil imenskega prostora velja za ujemajoča se imena ne glede na vrstni red adapterjev, in prazen rezultat tam ni napaka, ko pomočnik nikoli ni nameraval ustvariti enega. Branje vseh treh pred urejanjem je tisto, kar prepreči popravilo, ki le premakne simptom drugam.

Začnite s popolnoma kvalificiranim imenom. Če se FQDN razreši in kratko ime ne, je vrzel pripona ali iskalni seznam, ne naslov strežnika.

Kot drugi korak neposredno vprašajte predvideni strežnik s katerim koli že nameščenim orodjem razreševalnika. Neposreden odgovor dokaže, da je strežnik dosegljiv in pristojen za območje. Ne dokaže ničesar o tem, kateri strežnik aplikacija vpraša privzeto.

Imenujte komponento, ki ima v lasti povezavo

Pogosti sta dve ureditvi. Odjemalec, zagnan iz terminala, izrecno posreduje pot do svoje skripte, zato je lastnik viden v izvedenem ukazu. Pakirana aplikacija zažene odjemalca namesto vas in hrani pomočnika v svoji mapi, kar pomeni, da dobavitelj odloča, kdaj se spremeni.

Primerjajte različice pomočnika med namestitvami, preden karkoli zamenjate. Zaganjanje pomočnika, pridobljenega iz zrcala, z povišanimi pravicami samo zato, ker je ime datoteke videti znano, spremeni vrzel v DNS v varnostni incident.

Ko je lastnik znan, je cilj popravila očiten: podprta pot do skripte v zaganjalniku, posodobitev paketa ali popravljen profil na prehodu. Nobeno od tega ne zahteva ročnega urejanja lastnosti adapterja.

Popravite lastnika, ne adapterja

Ročno nastavljen DNS adapterja pogosto preživi prekinitev, zato se zdi, da deluje, nato pa povzroči težave v naslednjem omrežju. Javni razreševalnik, privit na vsak vmesnik, skrije težavo zasebnega imenskega prostora, namesto da bi jo rešil. Ko pomočnik nikoli ni prejel vrednosti DNS, je profil prehoda mesto, kamor je treba pogledati. Ko jo je prejel, adapter pa še vedno kaže stari strežnik, je pomočnik med povezovanjem spodletel in dnevnik odjemalca to običajno zabeleži blizu vrstic za nastavitev tunela.

Obnovite stanje po podprti poti in nato preverite celoten cikel: povežite se, razrešite zasebni FQDN, odprite storitev, prekinite povezavo in potrdite, da se je adapter vrnil s prejšnjimi strežniki.

Preverite aplikacijo, ki dejansko spodleti

Brskalnik z lastno nastavitvijo šifriranega DNS prezre vse zgoraj in še naprej odgovarja z javnega razreševalnika. Aplikacija, ki hrani predpomnjeni negativni odgovor iz časa pred dvigom tunela, se obnaša enako. Primerjajte jo z običajno sistemsko poizvedbo na istem računalniku, preden znova spremenite naslove razreševalnika.

Če je sistemska poizvedba pravilna in aplikacija ne, je preostala napaka v konfiguraciji DNS te aplikacije, ne na poti VPN.