Pourquoi le relais privé iCloud peut-il perturber les DNS d’un VPN d’entreprise ? J’ai arrêté de réparer le tunnel et regardé qui répondait au nom interne

Le VPN de l’entreprise était connecté. C’était justement ce qui rendait la panne incompréhensible. J’étais sur mon Mac personnel autorisé pour le travail à distance, connecté au Wi-Fi de mon hébergement. Outlook fonctionnait. Teams aussi. Le client VPN affichait sa connexion habituelle.

Mais quand j’ai ouvert notre outil interne, le navigateur a répondu qu’il ne trouvait pas le serveur. J’ai essayé le nom complet. Même chose. Puis j’ai utilisé directement son adresse IP privée. La page s’est ouverte. À ce moment-là, j’ai cessé de soupçonner le tunnel lui-même.

Le VPN savait atteindre le serveur. Mon Mac ne savait simplement plus quel DNS devait lui dire où ce serveur se trouvait.

Et il me restait moins de vingt minutes avant une réunion où j’avais besoin de cette page.

Le résultat le plus déroutant venait du Terminal

Mon premier réflexe a été de vérifier le DNS fourni par le VPN. dig renvoyait l’adresse privée attendue. nslookup aussi. Très bien. J’ai rouvert Safari. Le nom interne ne fonctionnait toujours pas. J’ai lancé une autre application qui utilisait le même domaine.

Échec également. J’avais donc un ordinateur capable de connaître la bonne réponse dans le Terminal et, quelques secondes plus tard, de se comporter comme s’il ne la connaissait pas.

Ce type de panne a déjà été observé sur macOS. En mars 2025, un utilisateur des forums développeurs d’Apple décrivait presque exactement le même comportement avec OpenVPN et le relais privé iCloud : le DNS du VPN retournait correctement l’adresse interne dans dig et nslookup, alors que les applications ordinaires obtenaient une autre résolution. Le problème avait été signalé à Apple via Feedback Assistant.

Cette description m’a fait regarder un réglage que je n’avais même pas considéré comme faisant partie de mon problème professionnel : Limiter le suivi de l’adresse IP. Autrement dit, le relais privé iCloud.

J’avais deux protections qui voulaient décider du chemin du même nom

Le relais privé n’est pas simplement « un VPN Apple ». Apple le conçoit principalement pour protéger la navigation Safari et les requêtes DNS associées. Les résolutions protégées sont chiffrées et passent par son architecture de relais afin de limiter ce qu’un seul intermédiaire peut connaître à la fois sur l’utilisateur et sur les sites consultés.

Mon VPN d’entreprise avait une autre mission. Il utilisait du split DNS. Le principe est beaucoup plus simple qu’il n’en a l’air. Pour www.apple.com, mon Mac peut utiliser son chemin normal vers Internet. Pour un nom interne comme intranet.entreprise.example, le VPN doit envoyer la question au DNS privé de l’entreprise, parce que c’est lui qui connaît l’adresse interne correspondante.

Apple prévoit justement des mécanismes comme matchDomains pour indiquer au système : pour ces domaines précis, utilise le résolveur du tunnel. Tant qu’une seule politique décide, on n’y pense même pas.

Le problème apparaît lorsque deux couches essaient de protéger ou de rediriger la résolution du même nom. Le VPN dit : ce domaine appartient à mon DNS interne. Le relais privé dit en substance : je protège aussi la résolution DNS de ce trafic.

Et dans certaines configurations, le résultat peut devenir exactement celui que j’avais devant moi : le tunnel est bien établi, l’adresse privée reste joignable, mais l’application n’obtient pas la réponse DNS interne attendue. Le VPN n’était pas cassé.

La question DNS avait simplement pris la mauvaise file.

Une actualité d’août 2026 m’avait déjà donné un indice

Quelques semaines auparavant, le relais privé iCloud était revenu dans l’actualité technique.

Les chercheurs Talal Haj Bakry et Tommy Mysk avaient montré que certaines fonctions de WebKit pouvaient contourner des configurations de proxy et laisser partir certaines requêtes DNS ou réseau directement depuis l’appareil. Ils faisaient aussi une distinction utile : Private Relay et un VPN système complet ne travaillent pas de la même façon ni au même niveau.

Ce problème WebKit n’expliquait pas à lui seul mon accès interne. Mais il m’a aidé à corriger l’idée qui m’avait fait perdre du temps :

deux outils qui améliorent la confidentialité ne se complètent pas automatiquement lorsqu’ils interviennent tous les deux dans la façon dont le trafic est résolu ou acheminé.

Pour mon domaine interne, ce qui comptait n’était pas d’ajouter encore une protection. C’était de laisser le DNS de l’entreprise répondre sans concurrence.

J’ai arrêté de modifier les DNS du VPN

J’avais déjà essayé les gestes classiques. Déconnexion du VPN. Reconnexion. Vidage du cache DNS. Changement de Wi-Fi. Retour au Wi-Fi. Je m’apprêtais même à saisir manuellement le DNS de l’entreprise dans macOS. Puis j’ai arrêté. Si le VPN avait déjà fourni le bon résolveur et que dig savait l’utiliser, ajouter encore une adresse DNS allait surtout compliquer le diagnostic.

J’ai ouvert : Réglages Système → Réseau → Wi-Fi → Détails. Puis j’ai désactivé Limiter le suivi de l’adresse IP pour ce réseau. Apple prévoit précisément cette possibilité lorsque Private Relay entre en conflit avec un réseau, un VPN ou un logiciel de filtrage : on peut le désactiver pour un réseau Wi-Fi ou Ethernet donné au lieu de devoir abandonner le service partout.

J’ai ensuite déconnecté puis reconnecté le VPN professionnel. Retour sur le nom interne. Cette fois, la page s’est ouverte. Pas son adresse IP saisie à la main. Pas une version publique. Le vrai nom interne. J’ai lancé l’outil dont j’avais besoin.

Connexion. Dossier client. Document. Puis la réunion. Le problème qui m’avait fait soupçonner le VPN pendant quinze minutes avait disparu sans que je change de serveur VPN ni que je réécrive sa configuration DNS.

Mon critère a changé : je voulais savoir qui avait le dernier mot

Avant cet incident, j’aurais presque toujours pensé qu’empiler les protections était préférable. Relais privé. VPN professionnel. DNS chiffré. Peut-être encore un filtre supplémentaire. Après cet après-midi, je raisonne autrement. Pour un domaine interne, une réponse prévisible vaut davantage qu’une couche de confidentialité supplémentaire qui ne connaît rien au réseau privé de mon entreprise.

Cela ne rend pas le relais privé inutile. Pour la navigation personnelle, son objectif reste parfaitement compréhensible. Et cela ne transforme pas non plus le VPN d’entreprise en outil idéal pour tout le reste. Son travail est de me donner accès aux ressources internes, à leurs routes et à leurs résolveurs.

Mais au moment où je dois ouvrir git.intra, wiki.interne ou un portail qui n’existe correctement qu’à l’intérieur du réseau de l’entreprise, je veux que le DNS du tunnel soit celui qui décide.

Apple reconnaît d’ailleurs que certaines entreprises et écoles doivent pouvoir désactiver Private Relay sur leurs réseaux afin d’auditer ou de filtrer leur trafic. Sa documentation prévoit une méthode spécifique autour de mask.icloud.com et mask-h2.icloud.com, plutôt que de laisser les connexions échouer silencieusement.

Ce détail a fini de clarifier mon problème. Je n’avais pas besoin de trouver « le meilleur DNS ». J’avais besoin d’éviter deux autorités concurrentes pour la même requête.

Après le travail, je ne voulais pas pour autant revenir à une connexion nue

Une fois la réunion terminée, j’ai déconnecté le tunnel d’entreprise. Et là, un deuxième problème est apparu, beaucoup plus banal. J’avais désactivé Private Relay sur ce Wi-Fi pour rendre mon environnement professionnel prévisible. Je pouvais évidemment le réactiver.

Mais je savais aussi ce qui risquait de se passer la prochaine fois que je reconnecterais le VPN de l’entreprise : je devrais me souvenir du réglage, vérifier à nouveau le DNS, puis me demander quelle couche était en train de décider. Je voulais une séparation beaucoup plus nette :

travail interne → VPN de l’entreprise ;

navigation personnelle → une seule protection personnelle explicite.

C’est là que la petite application que j’avais déjà installée comme solution de voyage a commencé à avoir davantage de sens. Une fois le VPN professionnel fermé, je l’ai lancée sur le Wi-Fi de l’hébergement et utilisé son mode destiné aux réseaux publics.

Connexion. Safari s’est ouvert normalement. Ma messagerie aussi. Les autres applications continuaient à passer dans le tunnel au niveau de l’appareil. Et surtout, je savais exactement ce que j’avais activé. Je n’avais plus une protection Safari d’un côté, un tunnel d’entreprise de l’autre et une question permanente sur le chemin emprunté par le DNS.

Le service est conçu autour d’une connexion VPN simple au niveau de l’appareil, sans obliger l’utilisateur à commencer par reconstruire manuellement une pile réseau complexe.

Après l’après-midi que je venais de passer, c’était précisément l’avantage qui m’intéressait. Pas davantage de réglages. Moins de choses capables de se disputer la même décision.

Je ne l’activerais justement pas par-dessus le VPN de mon entreprise

Cette limite compte. Un VPN personnel ne connaît pas les DNS privés de mon employeur. Il ne possède pas les routes vers ses sous-réseaux internes. Il ne remplace ni l’authentification de l’entreprise, ni ses certificats, ni ses règles d’accès. Si je dois atteindre un serveur uniquement disponible derrière le VPN professionnel, c’est ce dernier qui doit rester maître de la connexion.

Et sur un ordinateur entièrement géré par mon employeur, je suivrais la configuration de l’équipe informatique plutôt que d’ajouter un VPN personnel. La petite application a également moins de recul public, moins de régions et moins d’évaluations indépendantes qu’un fournisseur installé depuis longtemps.

Mais je ne lui demandais pas de devenir mon infrastructure d’entreprise. Je lui demandais quelque chose de beaucoup plus précis : me permettre de protéger simplement ma navigation personnelle sur un réseau partagé lorsque le tunnel professionnel était fermé, sans avoir à réintroduire une deuxième couche DNS dans mon prochain dépannage.

C’est pour cela qu’elle est restée sur le Mac. Je pensais au départ que mon VPN d’entreprise avait un mauvais DNS. Il avait en réalité le bon. Le problème était que mon Mac avait plusieurs façons de décider qui devait répondre.

Depuis, quand le tunnel se connecte mais qu’un nom interne échoue alors que son adresse IP fonctionne, je ne commence plus par changer de serveur VPN. Je vérifie le split DNS, le domaine concerné et les autres couches réseau actives — en particulier Private Relay et « Limiter le suivi de l’adresse IP ».

Pour un domaine d’entreprise, la question décisive n’est donc plus pour moi « combien de protections sont actives ? ». Elle est beaucoup plus concrète :

quand mon Mac demande où se trouve le serveur interne, est-ce bien le DNS de l’entreprise qui a le dernier mot ?