Client VPN Azure sur Mac : placez les serveurs DNS dans le profil

Sous macOS, trois questions différentes reçoivent le même haussement d’épaules. Quel client est-ce ? D’où viennent ses serveurs DNS ? Et une fois le réglage en place, pourquoi un nom court échoue-t-il encore ? Elles ont des réponses distinctes, et seule la première concerne le fichier de profil. Le bon ordre transforme un problème DNS vague en une étape vérifiable à la fois.

Confirmez quel client vous configurez

Il s’agit du client VPN Azure de Microsoft, qui utilise OpenVPN pour l’accès point à site. Son XML n’est pas un profil IKEv2 natif de macOS, et ce n’est pas non plus un fichier de configuration pour n’importe quel client OpenVPN tiers.

Si le Mac se connecte via la boîte de dialogue système intégrée, vous êtes dans le mauvais document.

Le DNS vit à l’intérieur du XML du profil

Téléchargez le profil actuel pour la passerelle et la méthode d’authentification prévues, puis conservez une copie non modifiée avant de toucher à quoi que ce soit. Ne modifiez que la copie de travail, et ne collez pas son matériel d’authentification dans un ticket d’assistance.

Le guide des paramètres facultatifs place les entrées DNS dans un élément clientconfig. Un fragment minimal ressemble à ceci, avec une adresse que votre organisation exploite réellement.

<clientconfig>
    <dnsservers>
        <dnsserver>10.20.2.4</dnsserver>
    </dnsservers>
</clientconfig>

Cette adresse est illustrative, pas un résolveur fourni par Azure. Intégrez les entrées dans la configuration existante au lieu de coller un second élément clientconfig, car Microsoft indique que les éléments en double ne sont pas pris en charge sous macOS. Les profils générés peuvent aussi contenir un espace réservé nil là où va la vraie configuration, et ajouter des paramètres à côté d’un élément nil n’est pas une réparation.

L’importation est le changement

Enregistrer le fichier ne change rien en soi. Ouvrez le client VPN Azure, choisissez Import, sélectionnez le XML révisé, remplissez les champs requis et enregistrez la connexion.

Reconnectez-vous ensuite via cette connexion importée. Un profil qui reste sur le disque alors qu’une connexion plus ancienne est toujours active est la raison la plus fréquente pour laquelle une modification correcte semble ne rien faire.

La limite de suffixe décide de votre premier test

Comme documenté le 30 octobre 2026, les valeurs de suffixe DNS supplémentaires de cette configuration ne persistent pas correctement sous macOS. Copier un exemple de suffixe Windows et promettre un comportement identique, c’est ainsi qu’un résolveur qui fonctionne est signalé comme cassé. Saisissez les suffixes, enregistrez, reconnectez-vous et vérifiez s’ils ont survécu à la reconnexion. Sinon, prévoyez des noms pleinement qualifiés plutôt que de lutter contre le client.

Testez d’abord avec un nom d’hôte privé pleinement qualifié. Si le FQDN se résout et que le nom court ne se résout pas, vous avez appris quelque chose de précis : le résolveur est joignable et l’expansion des noms courts manque. C’est un défaut différent d’un serveur DNS injoignable, et il nécessite un autre responsable.

Le résolveur a toujours besoin d’un chemin

Lister une adresse dans le XML ne crée pas un service DNS. L’adresse doit exécuter un résolveur autorisé capable de répondre ou de transférer l’espace de noms privé, et le Mac doit être autorisé à l’atteindre via le tunnel. Si ce résolveur se trouve derrière une règle de pare-feu qui ne connaît pas la plage du tunnel, les requêtes expirent sans erreur utile. Le délai ressemble alors exactement à une adresse erronée, et les gens remodifient le XML pendant une heure.

Inspectez l’état actif du résolveur du Mac connecté, puis interrogez directement ce serveur pour isoler sa réponse du choix de résolveur de l’application. Une requête directe prouve que le serveur fonctionne. Elle ne prouve pas que les recherches ordinaires le sélectionnent.

Transmettez trois résultats distincts

Gardez-les séparés dans la transmission : le profil révisé a été importé, le résolveur prévu a répondu au nom demandé et l’application a atteint l’adresse renvoyée. Chacun a un responsable et un correctif différents.

Une ligne par résultat suffit, et cela évite que la personne suivante remodifie un profil qui était déjà correct.