Qui applique réellement les paramètres DNS d’OpenConnect sous Windows ?

Monter le tunnel n’est pas la même chose qu’installer ses valeurs DNS. OpenConnect négocie, et un assistant côté Windows applique. L’écart entre ces deux étapes explique la plupart des échecs de noms privés sur ce client, et l’assistant n’est presque jamais la page de paramètres VPN de Windows.

Séparez ce que la passerelle a proposé de ce que Windows a installé

Le client transmet les données de connexion à une interface de script, et les variantes Unix et Windows sont des programmes distincts. Sous Windows, l’implémentation est généralement un assistant JavaScript qui lit des variables comme le serveur DNS interne et le domaine interne avant de toucher un adaptateur. Rien dans le tunnel lui-même n’écrit l’état du résolveur.

Cette séparation compte parce qu’une valeur peut exister dans la négociation et ne jamais atteindre l’adaptateur. Un assistant absent, qui échoue à mi-chemin ou qui est une copie plus ancienne embarquée dans une enveloppe GUI laisse Windows exactement comme il était. La session semble connectée, le nom privé se résout toujours via le fournisseur local, et rien dans la fenêtre du client n’indique la différence. Lire la sortie propre de l’assistant est le seul moyen fiable de savoir quelle étape a cassé.

Une enveloppe GUI peut livrer sa propre copie du client et de l’assistant, donc un second openconnect.exe ailleurs sur le disque ne prouve rien. Trouvez l’exécutable qui a lancé la session avant de juger sa configuration.

Lisez l’état du résolveur sans le modifier

Trois requêtes en lecture seule couvrent la confusion habituelle, et chacune répond à une question différente :

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

Un serveur au niveau de l’adaptateur est ce que la plupart des gens entendent par DNS VPN. Un suffixe propre à la connexion décide si un nom court est développé ou non. La liste de stratégies d’espace de noms s’applique aux noms correspondants quel que soit l’ordre des adaptateurs, et un résultat vide n’y est pas un défaut quand l’assistant n’a jamais eu l’intention d’en créer un. Lire les trois avant de modifier évite une réparation qui ne fait que déplacer le symptôme ailleurs.

Commencez par le nom pleinement qualifié. Si le FQDN se résout et que le nom court ne le fait pas, le suffixe ou la liste de recherche est la lacune, pas l’adresse du serveur.

Interrogez directement le serveur prévu comme deuxième étape, avec n’importe quel outil de résolveur déjà installé. Une réponse directe prouve que le serveur est joignable et fait autorité pour la zone. Elle ne prouve rien sur le serveur qu’une application interroge par défaut.

Nommez le composant qui possède la connexion

Deux dispositions sont courantes. Un client lancé depuis un terminal transmet explicitement le chemin de son script, si bien que le propriétaire est visible dans la commande exécutée. Une application empaquetée lance le client pour vous et garde l’assistant dans son propre répertoire, ce qui signifie que le fournisseur décide quand il change.

Comparez les versions de l’assistant entre installations avant de remplacer quoi que ce soit. Exécuter avec des droits élevés un assistant récupéré sur un miroir parce que le nom du fichier semble familier transforme une lacune DNS en incident de sécurité.

Une fois le propriétaire connu, la cible de la réparation devient évidente : un chemin de script pris en charge dans le lanceur, une mise à jour du paquet ou un profil corrigé sur la passerelle. Aucune de ces options n’exige de modifier les propriétés de l’adaptateur à la main.

Réparez le propriétaire, pas l’adaptateur

Le DNS posé à la main sur l’adaptateur survit souvent à la déconnexion, ce qui explique qu’il semble fonctionner puis cause des ennuis sur le réseau suivant. Un résolveur public boulonné sur chaque interface masque le problème de l’espace de noms privé au lieu de le résoudre. Quand l’assistant n’a jamais reçu de valeur DNS, le profil de la passerelle est l’endroit à regarder. Quand il en a reçu une et que l’adaptateur montre encore l’ancien serveur, l’assistant a échoué pendant la connexion et le journal du client l’enregistre généralement près des lignes de configuration du tunnel.

Reconstruisez l’état par la voie prise en charge, puis vérifiez un cycle complet : connectez, résolvez le FQDN privé, ouvrez le service, déconnectez, et confirmez que l’adaptateur est revenu avec ses serveurs précédents.

Vérifiez l’application qui échoue réellement

Un navigateur doté de son propre réglage de DNS chiffré ignore tout ce qui précède et continue de répondre depuis un résolveur public. Une application qui garde une réponse négative en cache d’avant le montage du tunnel se comporte de la même manière. Comparez-la avec une requête système simple sur la même machine avant de changer à nouveau les adresses de résolveur.

Si la requête système est correcte et l’application ne l’est pas, la panne restante se situe dans la configuration DNS de cette application, pas dans le chemin VPN.