Kiu efektive aplikas la DNS-agordojn de OpenConnect en Windows?

Levante la tunelon ne samas kiel instali ĝiajn DNS-valorojn. OpenConnect intertraktas, kaj helpanto ĉe la Windows-flanko aplikas. La manko inter tiuj du paŝoj klarigas la plej multajn malsukcesojn de privataj nomoj ĉe tiu ĉi kliento, kaj la helpanto preskaŭ neniam estas la agorda paĝo de VPN en Windows.

Apartigu tion, kion la enirejo proponis, de tio, kion Windows instalis

La kliento transdonas konektajn datumojn al skripta interfaco, kaj la variantoj por Unix kaj Windows estas apartaj programoj. En Windows la efektivigo kutime estas JavaScript-helpanto, kiu legas variablojn kiel la interna DNS-servilo kaj la interna domajno antaŭ ol ĝi tuŝas iun ajn adaptilon. Nenio en la tunelo mem skribas la staton de la solvilo.

Tiu apartigo gravas, ĉar valoro povas ekzisti en la intertrakto kaj neniam atingi la adaptilon. Helpanto, kiu mankas, malsukcesas duonvoje aŭ estas pli malnova kopio enkonstruita en GUI-ujo, lasas Windows ĝuste tia, kia ĝi estis. La seanco ŝajnas konektita, la privata nomo ankoraŭ solviĝas per la loka provizanto, kaj nenio en la klienta fenestro sugestas la diferencon. Legi la propran eligon de la helpanto estas la sola fidinda maniero ekscii, kiu stadio rompiĝis.

GUI-ujo povas liveri sian propran kopion de la kliento kaj helpanto, do dua openconnect.exe aliloke sur la disko pruvas nenion. Trovu la plenumeblon, kiu lanĉis la seancon, antaŭ ol juĝi ĝian agordon.

Legu la staton de la solvilo sen ŝanĝi ĝin

Tri nurlegaj demandoj kovras la kutiman konfuzon, kaj ĉiu respondas al malsama demando:

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

Servilo je adaptila nivelo estas tio, kion la plej multaj homoj komprenas per VPN-DNS. Konektospecifa sufikso decidas, ĉu mallonga nomo entute etendiĝos. La listo de nomspacaj politikoj validas por kongruaj nomoj sendepende de la adaptila ordo, kaj malplena rezulto tie ne estas difekto, kiam la helpanto neniam intencis krei unu. Legi ĉiujn tri antaŭ redakti estas tio, kio malhelpas riparon, kiu nur translokas la simptomon aliloken.

Komencu per la plene kvalifikita nomo. Se la FQDN solviĝas kaj la mallonga nomo ne, la manko estas la sufikso aŭ la serĉolisto, ne la servila adreso.

Demandu la celatan servilon rekte kiel duan paŝon, per iu ajn jam instalita solvila ilo. Rekta respondo pruvas, ke la servilo atingeblas kaj aŭtoritata por la zono. Ĝi pruvas nenion pri tio, kiun servilon aplikaĵo demandas defaŭlte.

Nomu la komponanton, kiu posedas la konekton

Du aranĝoj oftas. Kliento lanĉita el terminalo transdonas sian skriptan vojon eksplice, do la posedanto videblas en la ruligita komando. Pakaĵa aplikaĵo lanĉas la klienton por vi kaj tenas la helpanton en sia propra dosierujo, kio signifas, ke la vendisto decidas, kiam ĝi ŝanĝiĝos.

Komparu helpantajn versiojn inter instalaĵoj antaŭ ol anstataŭigi ion ajn. Ruli helpanton prenitan el spegulo kun altigitaj rajtoj ĉar la dosiernomo aspektas konata igas DNS-mankon sekureca okazaĵo.

Kiam la posedanto konatas, la riparcelo evidentiĝas: subtenata skripta vojo en la lanĉilo, pakaĵa ĝisdatigo aŭ korektita profilo ĉe la enirejo. Neniu el tiuj postulas mane redakti adaptilajn ecojn.

Riparu la posedanton, ne la adaptilon

Mane agordita adaptila DNS ofte postvivas malkonekton, pro kio ĝi ŝajnas funkcii kaj poste kaŭzas problemojn en la sekva reto. Publika solvilo ŝraŭbita al ĉiu interfaco kaŝas la problemon de la privata nomspaco anstataŭ solvi ĝin. Kiam la helpanto neniam ricevis DNS-valoron, la enireja profilo estas la loko por rigardi. Kiam ĝi ricevis unu kaj la adaptilo ankoraŭ montras la malnovan servilon, la helpanto malsukcesis dum konekto kaj la klienta protokolo kutime registras tion apud la linioj de tunela agordo.

Rebonu la staton per la subtenata vojo, poste kontrolu tutan ciklon: konektu, solvu la privatan FQDN, malfermu la servon, malkonektu kaj konfirmu, ke la adaptilo revenis kun siaj antaŭaj serviloj.

Kontrolu la aplikaĵon, kiu efektive malsukcesas

Retumilo kun propra agordo de ĉifrita DNS ignoras ĉion ĉi-supre kaj daŭre respondas el publika solvilo. Aplikaĵo, kiu tenas kaŝmemoran negativan respondon de antaŭ ol la tunelo leviĝis, kondutas same. Komparu ĝin kun ordinara sistema demando sur la sama maŝino antaŭ ol denove ŝanĝi solvilajn adresojn.

Se la sistema demando pravas kaj la aplikaĵo malpravas, la restanta difekto kuŝas ene de la DNS-agordo de tiu aplikaĵo, ne en la VPN-vojo.