Wie pas OpenConnect se DNS-instellings werklik op Windows toe?

Om die tonnel te begin is nie dieselfde as om sy DNS-waardes te installeer nie. OpenConnect onderhandel, en ’n hulp aan die Windows-kant pas dit toe. Die gaping tussen dié twee stappe verduidelik die meeste privaatnaam-mislukkings op hierdie kliënt, en die hulp is byna nooit die Windows VPN-instellingsblad nie.

Skei wat die gateway gebied het van wat Windows geïnstalleer het

Die kliënt gee verbindingsdata aan ’n scriptkoppelvlak, en die Unix- en Windows-variante is aparte programme. Op Windows is die implementering gewoonlik ’n JavaScript-hulp wat veranderlikes soos die interne DNS-bediener en interne domein lees voordat dit enige adapter aanraak. Niks in die tonnel self skryf reseolvertoestand nie.

Daardie splitsing maak saak, want ’n waarde kan in die onderhandeling bestaan en nooit die adapter bereik nie. ’n Hulp wat ontbreek, halfpad misluk, of ’n ouer kopie is wat in ’n GUI-omhulsel ingebou is, laat Windows presies soos dit was. Die sessie lyk verbind, die privaat naam word steeds deur die plaaslike verskaffer opgelos, en niks in die kliëntvenster dui op die verskil nie. Om die hulp se eie uitvoer te lees, is die enigste betroubare manier om te leer watter stadium gebreek het.

’n GUI-omhulsel kan sy eie kopie van die kliënt en hulp saambring, so ’n tweede openconnect.exe elders op die skyf bewys niks. Vind die uitvoerbare lêer wat die sessie begin het voordat jy sy opstelling beoordeel.

Lees die reseolvertoestand sonder om dit te verander

Drie lees-alleen-navrae dek die gewone verwarring, en elkeen antwoord ’n ander vraag:

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

’n Bediener op adaptervlak is wat meeste mense met VPN-DNS bedoel. ’n Verbindingspesifieke agtervoegsel bepaal of ’n kort naam hoegenaamd uitgesit word. Die naamruimtebeleidslys geld vir ooreenstemmende name ongeag adapterorde, en ’n leë resultaat daar is nie ’n fout nie wanneer die hulp nooit van plan was om een te skep nie. Om al drie te lees voordat jy wysig, is wat ’n regstelling voorkom wat bloot die simptoom elders heen skuif.

Begin met die volledig gekwalifiseerde naam. As die FQDN oplos en die kort naam nie, is die agtervoegsel of soeklys die gaping eerder as die bedieneradres.

Vra die bedoelde bediener direkt as ’n tweede stap, met watter reseolverinstrument ook al geïnstalleer is. ’n Direkte antwoord bewys die bediener is bereikbaar en gesaghebbend vir die sone. Dit bewys niks oor watter bediener ’n toepassing by verstek vra nie.

Noem die komponent wat die verbinding besit

Twee reëlings is algemeen. ’n Kliënt wat vanuit ’n terminaal begin is, gee sy scriptpad eksplisiet deur, so die eienaar is sigbaar in die opdrag wat geloop het. ’n Verpakte toepassing begin die kliënt vir jou en hou die hulp in sy eie gids, wat beteken die verskaffer besluit wanneer dit verander.

Vergelyk hulpweergawes oor installasies voordat jy enigiets omruil. Om ’n hulp te hardloop wat van ’n spieël afgehaal is met verhoogde regte omdat die lêernaam bekend lyk, maak ’n DNS-gaping ’n sekuriteitsinsident.

Sodra die eienaar bekend is, word die herstelteiken duidelik: ’n ondersteunde scriptpad in die lanseerder, ’n pakketopdatering, of ’n gekorrigeerde profiel op die gateway. Nie een daarvan vereis dat jy adaptereienskappe met die hand wysig nie.

Herstel die eienaar, nie die adapter nie

DNS wat met die hand op die adapter gestel is, oorleef dikwels ontkoppeling, en daarom lyk dit of dit werk en veroorsaak dan moeilikheid op die volgende netwerk. ’n Openbare reseolver wat op elke koppelvlak vasgebout is, verberg die privaat naamruimte-probleem in plaas daarvan om dit op te los. Wanneer die hulp nooit ’n DNS-waarde ontvang het nie, is die gatewayprofiel die plek om te kyk. Wanneer dit een ontvang het en die adapter wys steeds die ou bediener, het die hulp tydens verbinding misluk en die kliëntlog teken dit gewoonlik naby die tonnelopstelling-reëls aan.

Bou die toestand deur die ondersteunde pad weer op en verifieer dan ’n volledige siklus: verbind, los die privaat FQDN op, maak die diens oop, ontkoppel, en bevestig die adapter het met sy vorige bedieners teruggekom.

Kontroleer die toepassing wat werklik misluk

’n Blaaier met sy eie geënskripteerde-DNS-instelling ignoreer alles hierbo en bly van ’n openbare reseolver antwoord. ’n Toepassing wat ’n gekasde negatiewe antwoord van voor die tonnel hou, gedra hom dieselfde. Vergelyk dit met ’n gewone stelselnavraag op dieselfde masjien voordat jy weer reseolveradresse verander.

As die stelselnavraag reg is en die toepassing verkeerd, sit die oorblywende fout in daardie toepassing se DNS-opstelling, nie in die VPN-pad nie.