Sino ba talaga ang naglalapat ng mga OpenConnect DNS setting sa Windows?
Tatlong lugar ang pinag-iingatan ng Windows sa estado ng resolver. Hanapin ang helper na may-ari ng koneksyon bago mo manu-manong i-edit ang DNS ng adapter o magdagdag ng namespace rule.
Ang pag-angat ng tunnel ay hindi katulad ng pag-install ng mga halaga ng DNS nito. Nag-uusap ang OpenConnect, at isang helper sa panig ng Windows ang naglalapat. Ang agwat sa pagitan ng dalawang hakbang na iyon ang nagpapaliwanag sa karamihan ng pagkabigo ng pribadong pangalan sa client na ito, at ang helper ay halos hindi kailanman ang pahina ng mga setting ng VPN ng Windows.
Ihiwalay ang inialok ng gateway sa inilagay ng Windows
Ipinapasa ng client ang data ng koneksyon sa isang script interface, at ang mga bersyon para sa Unix at Windows ay magkahiwalay na programa. Sa Windows ang implementasyon ay karaniwang isang JavaScript helper na nagbabasa ng mga variable tulad ng internal DNS server at internal domain bago ito humawak ng anumang adapter. Wala sa loob ng tunnel mismo ang nagsusulat ng estado ng resolver.
Mahalaga ang paghahating iyon dahil ang isang halaga ay maaaring umiral sa negosasyon at hindi kailanman umabot sa adapter. Ang helper na kulang, nabigo sa kalagitnaan, o lumang kopya na nakabalot sa isang GUI wrapper ay nag-iiwan sa Windows na eksaktong tulad ng dati. Mukhang konektado ang session, nareresolba pa rin ang pribadong pangalan sa pamamagitan ng lokal na provider, at wala sa window ng client ang nagpapahiwatig ng pagkakaiba. Ang pagbasa ng sariling output ng helper ang tanging maaasahang paraan upang malaman kung aling yugto ang nasira.
| 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 |
Ang isang GUI wrapper ay maaaring magdala ng sarili nitong kopya ng client at helper, kaya ang pangalawang openconnect.exe sa ibang lugar sa disk ay walang pinapatunayan. Hanapin ang executable na nagsimula ng session bago hatulan ang configuration nito.
Basahin ang estado ng resolver nang hindi ito binabago
Tatlong query na basahin lamang ang sumasaklaw sa karaniwang kalituhan, at bawat isa ay sumasagot sa ibang tanong:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -EffectiveAng server sa antas ng adapter ang tinutukoy ng karamihan sa VPN DNS. Ang suffix na partikular sa koneksyon ang nagpapasya kung ang maikling pangalan ay palalawakin man. Ang listahan ng patakaran ng namespace ay nalalapat sa mga tugmang pangalan anuman ang pagkakasunod-sunod ng adapter, at ang walang laman na resulta doon ay hindi depekto kapag hindi kailanman sinadya ng helper na gumawa ng isa. Ang pagbasa ng tatlo bago mag-edit ang pumipigil sa isang pag-aayos na naglilipat lamang ng sintomas sa ibang lugar.
Magsimula sa ganap na kwalipikadong pangalan. Kung nareresolba ang FQDN at hindi ang maikling pangalan, ang suffix o listahan ng paghahanap ang agwat, hindi ang address ng server.
Tanungin nang direkta ang nilalayong server bilang ikalawang hakbang, gamit ang anumang naka-install nang tool na resolver. Ang direktang sagot ay nagpapatunay na ang server ay maabot at may awtoridad para sa zone. Wala itong pinapatunayan tungkol sa kung aling server ang tinatanong ng isang application bilang default.
Pangalanan ang bahaging may-ari ng koneksyon
Karaniwan ang dalawang kaayusan. Ang client na sinimulan mula sa terminal ay tahasang nagpapasa ng path ng script nito, kaya makikita ang may-ari sa command na pinatakbo. Ang naka-package na application ay nagsisimula ng client para sa iyo at inilalagay ang helper sa sarili nitong direktoryo, ibig sabihin, ang vendor ang nagpapasya kung kailan ito magbabago.
Ihambing ang mga bersyon ng helper sa iba’t ibang pag-install bago palitan ang anuman. Ang pagpapatakbo ng helper na nakuha mula sa mirror na may nakataas na karapatan dahil pamilyar ang pangalan ng file ay ginagawang insidente sa seguridad ang isang agwat sa DNS.
Kapag kilala na ang may-ari, nagiging malinaw ang target ng pag-aayos: isang suportadong path ng script sa launcher, isang update ng package, o isang itinamang profile sa gateway. Wala sa mga ito ang nangangailangan ng manu-manong pag-edit ng mga property ng adapter.
Ayusin ang may-ari, hindi ang adapter
Ang manu-manong itinakdang DNS sa adapter ay madalas na tumatagal pagkatapos ng pagkadiskonekta, kaya mukhang gumagana ito at pagkatapos ay nagdudulot ng problema sa susunod na network. Ang pampublikong resolver na naka-bolt sa bawat interface ay nagtatago ng problema sa pribadong namespace sa halip na lutasin ito. Kapag hindi kailanman nakatanggap ng halaga ng DNS ang helper, ang profile ng gateway ang lugar na dapat tingnan. Kapag nakatanggap ito ng isa at ipinapakita pa rin ng adapter ang lumang server, nabigo ang helper habang kumokonekta at karaniwang itinatala iyon ng log ng client malapit sa mga linya ng pag-setup ng tunnel.
Itayong muli ang estado sa suportadong landas, pagkatapos ay i-verify ang isang buong siklo: kumonekta, resolbahin ang pribadong FQDN, buksan ang serbisyo, idiskonekta, at kumpirmahin na bumalik ang adapter kasama ang mga dating server nito.
Suriin ang application na talagang nabigo
Ang browser na may sariling setting ng naka-encrypt na DNS ay hindi pinapansin ang lahat ng nasa itaas at patuloy na sumasagot mula sa pampublikong resolver. Ang application na may naka-cache na negatibong sagot mula bago umangat ang tunnel ay ganoon din ang ginagawa. Ihambing ito sa isang simpleng query ng system sa parehong makina bago mo muling baguhin ang mga address ng resolver.
Kung tama ang query ng system at mali ang application, ang natitirang depekto ay nasa loob ng configuration ng DNS ng application na iyon, hindi sa landas ng VPN.