Wer wendet die OpenConnect-DNS-Einstellungen unter Windows tatsächlich an?

Den Tunnel aufzubauen ist nicht dasselbe wie seine DNS-Werte zu installieren. OpenConnect verhandelt, und ein Helfer auf Windows-Seite wendet an. Die Lücke zwischen diesen beiden Schritten erklärt die meisten Fehler bei privaten Namen auf diesem Client, und der Helfer ist fast nie die Windows-VPN-Einstellungsseite.

Trennen Sie, was das Gateway angeboten hat, von dem, was Windows installiert hat

Der Client übergibt Verbindungsdaten an eine Skriptschnittstelle, und die Unix- und Windows-Varianten sind getrennte Programme. Unter Windows ist die Implementierung meist ein JavaScript-Helfer, der Variablen wie den internen DNS-Server und die interne Domäne liest, bevor er einen Adapter berührt. Nichts im Tunnel selbst schreibt Resolver-Zustand.

Diese Trennung ist wichtig, weil ein Wert in der Verhandlung existieren und den Adapter nie erreichen kann. Ein Helfer, der fehlt, auf halbem Weg scheitert oder eine ältere Kopie ist, die in einem GUI-Wrapper mitgeliefert wird, lässt Windows genau so, wie es war. Die Sitzung sieht verbunden aus, der private Name wird weiterhin über den lokalen Anbieter aufgelöst, und nichts im Client-Fenster deutet auf den Unterschied hin. Die eigene Ausgabe des Helfers zu lesen ist der einzige verlässliche Weg zu erfahren, welche Stufe brach.

Ein GUI-Wrapper kann seine eigene Kopie von Client und Helfer mitbringen, daher beweist eine zweite openconnect.exe anderswo auf dem Datenträger nichts. Finden Sie die ausführbare Datei, die die Sitzung gestartet hat, bevor Sie ihre Konfiguration beurteilen.

Lesen Sie den Resolver-Zustand, ohne ihn zu ändern

Drei schreibgeschützte Abfragen decken die übliche Verwirrung ab, und jede beantwortet eine andere Frage:

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

Ein Server auf Adapterebene ist das, was die meisten unter VPN-DNS verstehen. Ein verbindungsspezifisches Suffix entscheidet, ob ein kurzer Name überhaupt erweitert wird. Die Namespace-Richtlinienliste gilt für passende Namen unabhängig von der Adapterreihenfolge, und ein leeres Ergebnis dort ist kein Fehler, wenn der Helfer nie beabsichtigte, eines anzulegen. Alle drei vor dem Bearbeiten zu lesen verhindert eine Reparatur, die das Symptom nur woandershin verschiebt.

Beginnen Sie mit dem vollqualifizierten Namen. Löst der FQDN auf und der kurze Name nicht, sind das Suffix oder die Suchliste die Lücke und nicht die Serveradresse.

Fragen Sie den vorgesehenen Server direkt als zweiten Schritt, mit welchem bereits installierten Resolver-Werkzeug auch immer. Eine direkte Antwort beweist, dass der Server erreichbar und für die Zone autoritativ ist. Sie beweist nichts darüber, welchen Server eine Anwendung standardmäßig fragt.

Benennen Sie die Komponente, der die Verbindung gehört

Zwei Anordnungen sind üblich. Ein vom Terminal gestarteter Client übergibt seinen Skriptpfad ausdrücklich, sodass der Eigentümer im ausgeführten Befehl sichtbar ist. Eine paketierte Anwendung startet den Client für Sie und hält den Helfer in ihrem eigenen Verzeichnis, was bedeutet, dass der Hersteller entscheidet, wann er sich ändert.

Vergleichen Sie Helferversionen über Installationen hinweg, bevor Sie etwas austauschen. Einen von einem Spiegel geholten Helfer mit erhöhten Rechten auszuführen, weil der Dateiname vertraut aussieht, macht aus einer DNS-Lücke einen Sicherheitsvorfall.

Sobald der Eigentümer bekannt ist, wird das Reparaturziel offensichtlich: ein unterstützter Skriptpfad im Starter, ein Paketupdate oder ein korrigiertes Profil auf dem Gateway. Nichts davon erfordert das Bearbeiten von Adaptereigenschaften von Hand.

Reparieren Sie den Eigentümer, nicht den Adapter

Von Hand gesetzte Adapter-DNS überlebt oft das Trennen, weshalb es zu funktionieren scheint und dann im nächsten Netz Ärger macht. Ein öffentlicher Resolver, der auf jede Schnittstelle geschraubt wird, verbirgt das Problem des privaten Namespace, statt es zu lösen. Wenn der Helfer nie einen DNS-Wert erhalten hat, ist das Gateway-Profil der richtige Ort. Wenn er einen erhalten hat und der Adapter noch den alten Server zeigt, ist der Helfer beim Verbinden gescheitert, und das Client-Log hält das meist nahe den Tunnel-Setup-Zeilen fest.

Bauen Sie den Zustand über den unterstützten Weg neu auf und prüfen Sie dann einen ganzen Zyklus: verbinden, den privaten FQDN auflösen, den Dienst öffnen, trennen und bestätigen, dass der Adapter mit seinen vorherigen Servern zurückkam.

Prüfen Sie die Anwendung, die tatsächlich scheitert

Ein Browser mit eigener verschlüsselter DNS-Einstellung ignoriert alles oben und antwortet weiter von einem öffentlichen Resolver. Eine Anwendung, die eine zwischengespeicherte negative Antwort von vor dem Tunnelaufbau hält, verhält sich genauso. Vergleichen Sie sie mit einer einfachen Systemabfrage auf derselben Maschine, bevor Sie Resolver-Adressen erneut ändern.

Ist die Systemabfrage richtig und die Anwendung falsch, sitzt der verbleibende Fehler in der DNS-Konfiguration dieser Anwendung, nicht im VPN-Pfad.