Wa past de DNS-ynstellingen fan OpenConnect eins ta op Windows?
Windows hâldt de status fan de resolver op trije plakken. Fyn de helper dy’t de ferbining besit foardat jo adapter-DNS mei de hân bewurkje of in nammesromteregel tafoegje.
De tunnel omheech bringe is net itselde as syn DNS-wearden ynstallearje. OpenConnect ûnderhannelet, en in helper oan de Windows-kant past ta. De kleau tusken dy twa stappen ferklearret de measte mislearrings fan priveenammen op dizze klient, en de helper is hast nea de Windows VPN-ynsettingsside.
Skied wat de gateway oanbea fan wat Windows ynstallearre
De klient jout ferbiningsgegevens oan in scriptynterface, en de Unix- en Windows-farianten binne aparte programma’s. Op Windows is de ymplemintaasje meastentiids in JavaScript-helper dy’t fariabelen lykas de ynterne DNS-tsjinner en it ynterne domein lêst foardat er in adapter oanrekket. Neat yn de tunnel sels skriuwt resolverstatus.
Dy splitsing is wichtich, want in wearde kin yn de ûnderhanneling bestean en nea de adapter berikke. In helper dy’t mist, healwei mislearret of in âldere kopy is dy’t yn in GUI-omhulsel sit, lit Windows krekt sa’t it wie. De sesje liket ferbûn, de priveenamme wurdt noch altyd fia de lokale leveransier oplost, en neat yn it klientfinster wiist op it ferskil. It lêzen fan de eigen útfier fan de helper is de iennichste betroubere manier om te witten hokker stap bruts.
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
In GUI-omhulsel kin syn eigen kopy fan de klient en helper leverje, dus in twadde openconnect.exe earne oars op de skiif bewiist neat. Fyn it útfierbere bestân dat de sesje starte foardat jo syn konfiguraasje beoardielje.
Lês de resolverstatus sûnder dy te feroarjen
Trije allinnich-lêzen-fragen dekke de gewoane betizing, en elk beantwurdet in oare fraach:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -EffectiveIn tsjinner op adapternivo is wat de measte minsken ûnder VPN-DNS ferstean. In ferbiningseigen efterheaksel beslút oft in koarte namme hielendal útwreide wurdt. De list mei nammesromtebelied jildt foar oerienkommende nammen los fan de adapterfolchoarder, en in leech resultaat dêr is gjin defekt as de helper nea fan doel wie om ien te meitsjen. Alle trije lêze foardat jo bewurkje is wat in reparaasje foarkomt dy’t it symptoom gewoan earne oars hinne ferpleatst.
Begjin mei de folslein kwalifisearre namme. As de FQDN oplost en de koarte namme net, dan is it efterheaksel of de syklist de kleau, net it tsjinneradres.
Freegje de bedoelde tsjinner direkt as twadde stap, mei hokker resolver-ark dan ek al ynstallearre is. In direkt antwurd bewiist dat de tsjinner berikber en foechhawwend foar de sône is. It bewiist neat oer hokker tsjinner in applikaasje standert freget.
Neam it komponint dat de ferbining besit
Twa regelingen binne gewoan. In klient dy’t fan in terminal start is, jout syn scriptpaad eksplisyt troch, dus de eigner is sichtber yn it kommando dat rûn. In ferpakke applikaasje start de klient foar jo en hâldt de helper yn syn eigen map, wat betsjut dat de leveransier beslút wannear’t er feroaret.
Fergelykje helperferzjes tusken ynstallaasjes foardat jo eat ferwikselje. In helper út in spegel helje en mei ferhege rjochten rinne litte om’t de bestânsnamme bekend liket, makket fan in DNS-kleau in feilichheidsyngreep.
As de eigner ienris bekend is, wurdt it reparaasjedoel dúdlik: in stipe scriptpaad yn de starter, in pakketfernijing of in korrizjearre profyl op de gateway. Gjin fan dy freget om adaptereigenskippen mei de hân te bewurkjen.
Meitsje de eigner goed, net de adapter
DNS dy’t mei de hân op de adapter set is, oerlibbet faak it ôfbrekken, wêrtroch’t it liket te wurkjen en dan problemen jout op it folgjende netwurk. In iepenbiere resolver dy’t op elke interface fêstskroeve is, ferberget it probleem fan de priveenammesromte ynstee fan it op te lossen. As de helper nea in DNS-wearde krige, is it gatewayprofyl it plak om te sjen. As er ien krige en de adapter toant noch de âlde tsjinner, dan mislearre de helper by it ferbinen en it klientlog registrearret dat meastentiids tichtby de rigels foar tunnelopsets.
Bou de status wer op fia it stipe paad en ferifiearje dan in folsleine syklus: ferbine, de privee FQDN oplosse, de tsjinst iepenje, ôfbrekke, en befêstigje dat de adapter weromkaam mei syn eardere tsjinners.
Kontrolearje de applikaasje dy’t eins mislearret
In browser mei syn eigen ynstelling foar fersifere DNS negearret alles hjirboppe en bliuwt fan in iepenbiere resolver antwurdzje. In applikaasje dy’t in bewarre negatyf antwurd fan foar it omheech gean fan de tunnel hâldt, docht itselde. Fergelykje it mei in gewoane systeemfraach op deselde masine foardat jo resolveradressen wer feroarje.
As de systeemfraach goed is en de applikaasje ferkeard, sit de oerbleaune flater yn de DNS-konfiguraasje fan dy applikaasje, net yn it VPN-paad.