Wie past de OpenConnect-DNS-instellingen op Windows eigenlijk toe?

De tunnel opzetten is niet hetzelfde als de DNS-waarden ervan installeren. OpenConnect onderhandelt, en een helper aan de Windows-kant past toe. De kloof tussen die twee stappen verklaart de meeste fouten met privénamen op deze client, en de helper is bijna nooit de VPN-instellingenpagina van Windows.

Scheid wat de gateway aanbood van wat Windows installeerde

De client geeft verbindingsgegevens door aan een scriptinterface, en de Unix- en Windows-varianten zijn afzonderlijke programma’s. Op Windows is de implementatie meestal een JavaScript-helper die variabelen zoals de interne DNS-server en het interne domein leest voordat hij een adapter aanraakt. Niets in de tunnel zelf schrijft resolvertilstand.

Die splitsing is belangrijk omdat een waarde in de onderhandeling kan bestaan en de adapter nooit bereikt. Een helper die ontbreekt, halverwege faalt of een oudere kopie is die in een GUI-wrapper zit, laat Windows precies zoals het was. De sessie lijkt verbonden, de privénaam wordt nog steeds via de lokale provider opgelost, en niets in het clientvenster wijst op het verschil. De eigen uitvoer van de helper lezen is de enige betrouwbare manier om te weten te komen welke fase brak.

Een GUI-wrapper kan zijn eigen kopie van de client en helper meeleveren, dus een tweede openconnect.exe elders op de schijf bewijst niets. Zoek het uitvoerbare bestand dat de sessie startte voordat u de configuratie beoordeelt.

Lees de resolvertilstand zonder die te wijzigen

Drie alleen-lezen-query’s dekken de gebruikelijke verwarring, en elk beantwoordt een andere vraag:

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

Een server op adapterniveau is wat de meeste mensen met VPN-DNS bedoelen. Een verbindingsspecifiek achtervoegsel bepaalt of een korte naam überhaupt wordt uitgebreid. De naamruimtebeleidslijst geldt voor overeenkomende namen ongeacht de adaptervolgorde, en een leeg resultaat daar is geen fout wanneer de helper nooit van plan was er een te maken. Alle drie lezen voordat u bewerkt, voorkomt een reparatie die het symptoom alleen ergens anders neerzet.

Begin met de volledig gekwalificeerde naam. Als de FQDN wordt opgelost en de korte naam niet, is het achtervoegsel of de zoeklijst de kloof en niet het serveradres.

Vraag de bedoelde server rechtstreeks als tweede stap, met welk al geïnstalleerd resolverhulpmiddel dan ook. Een direct antwoord bewijst dat de server bereikbaar en gezaghebbend voor de zone is. Het bewijst niets over welke server een toepassing standaard vraagt.

Benoem het onderdeel dat de verbinding bezit

Twee opstellingen komen vaak voor. Een client die vanaf een terminal start, geeft zijn scriptpad expliciet door, dus de eigenaar is zichtbaar in het uitgevoerde commando. Een verpakte toepassing start de client voor u en houdt de helper in zijn eigen map, wat betekent dat de leverancier beslist wanneer die verandert.

Vergelijk helperversies tussen installaties voordat u iets vervangt. Een helper van een spiegel met verhoogde rechten uitvoeren omdat de bestandsnaam bekend voorkomt, maakt van een DNS-kloof een beveiligingsincident.

Zodra de eigenaar bekend is, wordt het reparatiedoel duidelijk: een ondersteund scriptpad in de launcher, een pakketupdate of een gecorrigeerd profiel op de gateway. Geen daarvan vereist dat u adaptereigenschappen handmatig bewerkt.

Repareer de eigenaar, niet de adapter

Handmatig ingestelde adapter-DNS overleeft vaak het verbreken, waardoor het lijkt te werken en vervolgens problemen geeft op het volgende netwerk. Een publieke resolver die op elke interface is vastgeschroefd, verbergt het probleem van de privé-naamruimte in plaats van het op te lossen. Wanneer de helper nooit een DNS-waarde heeft ontvangen, is het gatewayprofiel de plek om te kijken. Wanneer hij er een heeft ontvangen en de adapter nog steeds de oude server toont, is de helper tijdens het verbinden mislukt en het clientlog registreert dat meestal bij de tunnelopstellingsregels.

Bouw de toestand opnieuw op via het ondersteunde pad en verifieer dan een hele cyclus: verbind, los de privé-FQDN op, open de dienst, verbreek de verbinding en bevestig dat de adapter terugkwam met zijn vorige servers.

Controleer de toepassing die werkelijk faalt

Een browser met zijn eigen versleutelde DNS-instelling negeert alles hierboven en blijft antwoorden van een publieke resolver. Een toepassing die een gecacht negatief antwoord van vóór het opkomen van de tunnel vasthoudt, gedraagt zich hetzelfde. Vergelijk die met een gewone systeemquery op dezelfde machine voordat u weer resolveradressen wijzigt.

Als de systeemquery juist is en de toepassing onjuist, zit de resterende fout in de DNS-configuratie van die toepassing, niet in het VPN-pad.