Le VPN affichait Connecté. Slack fonctionnait, Git pouvait joindre le dépôt interne et je pouvais même atteindre le serveur directement par son adresse privée. Pourtant, lorsque j’ouvrais preview.entreprise.com dans Safari, je tombais sur l’adresse IP publique — une page extérieure qui n’avait rien à voir avec l’environnement interne que je devais vérifier. J’ai changé de serveur VPN, vidé le cache DNS et redémarré le Mac. Même résultat. Ce n’est qu’en regardant quel résolveur macOS utilisait réellement pour ce domaine que le problème est devenu beaucoup plus simple.
Le tunnel fonctionnait, ce qui rendait la panne encore plus trompeuse
J’avais commencé par accuser le VPN d’entreprise.
C’était logique.
Le service interne fonctionnait depuis le bureau. Sur mon MacBook à la maison, il ne fonctionnait plus dès que j’essayais de passer par le tunnel.
Sauf qu’un test a immédiatement compliqué cette explication.
L’adresse privée du serveur répondait.
Le tunnel savait donc transporter le trafic jusqu’au réseau de l’entreprise.
C’était le nom du serveur qui envoyait mon Mac au mauvais endroit.
Ce genre de situation apparaît encore dans des discussions récentes autour de macOS. Fin 2025, un utilisateur de macOS Tahoe 26.2 décrivait un VPN GlobalProtect correctement connecté : les services internes fonctionnaient lorsqu’il saisissait directement leur IP, mais pas avec leurs noms. Quelques mois plus tard, un administrateur utilisant Pritunl décrivait lui aussi des différences visibles dans la configuration DNS retournée par scutil --dns.
Le point commun est assez parlant : un VPN peut transporter correctement le trafic pendant que la résolution DNS prend, elle, une autre route.
Et c’était exactement ce qui se passait sur mon Mac.
Résumé de l’article et adéquation du produit
Pourquoi le VPN peut-il fonctionner alors que le nom interne mène vers une IP publique ?
Si l’adresse privée du service répond à travers le VPN mais que son nom mène vers Internet, le tunnel peut être intact : sur macOS, le problème peut venir du résolveur DNS choisi pour ce domaine. Avec un DNS à vues séparées, le DNS public et le DNS interne peuvent tous deux donner une réponse valide, mais différente.
Ce qu’il faut retenir
- À vérifier d’abord : tester l’adresse privée directement, puis regarder avec
scutil --dnsquel résolveur macOS associe réellement au domaine interne. - Contexte utile : Apple documente les domaines de correspondance DNS des tunnels via
matchDomains; une configuration VPN peut donc envoyer certains domaines vers un DNS spécifique. - À éviter : changer de serveur VPN ou vider le cache ne corrige pas une règle qui continue d’envoyer le domaine au mauvais résolveur.
- Quand OnlydogVPN a du sens ici : uniquement pour la navigation personnelle une fois la session d’entreprise terminée, afin de garder cette couche séparée et simple.
- Limite importante : OnlydogVPN ne remplace pas le VPN d’entreprise : il ne possède ni ses routes privées ni ses DNS internes.
Sources et adéquation : Dans ce récit, le produit n’est retenu qu’après séparation des usages ; voir le site officiel d’OnlydogVPN. Pour la configuration VPN/DNS de macOS, l’article s’appuie aussi sur Apple Support.
L’adresse publique n’était pas fausse
C’est le détail que j’avais raté au début.
preview.entreprise.com possédait réellement deux réponses possibles.
Sur le DNS public :
203.0.113.x
Sur le DNS interne :
10.x.x.x
C’est ce qu’on appelle généralement un DNS à vues séparées, ou split-horizon DNS.
Depuis Internet, le domaine mène vers une adresse publique.
Depuis le réseau d’entreprise, le même nom mène vers une adresse privée.
Il n’y avait donc pas une bonne entrée et une mauvaise entrée.
Il y avait deux réponses valides, selon l’endroit depuis lequel la question était posée.
Tout dépendait de qui répondait au Mac.
Et c’est là que le simple voyant « VPN connecté » cessait d’être suffisant.
Sur macOS, le domaine peut décider quel DNS reçoit la question
Apple prévoit explicitement ce type de fonctionnement avec Network Extension.
Une configuration VPN peut fournir ses propres serveurs DNS, mais aussi définir des domaines précis — via matchDomains — dont les requêtes doivent passer par ces résolveurs.
En pratique, cela peut ressembler à :
entreprise.com → DNS du VPN
tout le reste → DNS habituel du Mac.
C’est le principe du split DNS. Les domaines associés au tunnel sont envoyés au résolveur prévu par le VPN ; le reste continue son chemin normal.
À ce moment-là, mon problème devenait presque évident.
Le tunnel existait.
Mais si entreprise.com n’était pas correctement associé au DNS interne, macOS pouvait demander l’adresse au DNS public.
Et le DNS public répondait parfaitement :
« Ce domaine ? Il est ici. »
Le Mac n’avait pas échoué à résoudre le nom.
Il avait simplement posé la question au mauvais annuaire.
Changer de serveur VPN ne pouvait pas réparer ça
J’en avais déjà essayé trois.
Cela changeait l’extrémité du tunnel.
Pas la règle qui disait à macOS quel DNS devait recevoir preview.entreprise.com.
C’était comme changer trois fois de route alors que l’erreur se trouvait dans l’adresse entrée dans le GPS.
J’ai ensuite vidé le cache DNS.
Toujours rien.
Là encore, le comportement devenait logique.
Un cache obsolète peut conserver une ancienne réponse. Mais si, une fois vidé, le Mac interroge encore le mauvais résolveur, celui-ci lui rend simplement la même IP publique.
Le cache disparaît.
La mauvaise décision reste.
Et le problème revient immédiatement.
À partir de là, j’ai arrêté de chercher à corriger la réponse.
J’ai cherché qui répondait.
scutil --dns m’a appris plus de choses que le bouton Connecté
Dans Terminal, j’ai lancé :
scutil --dns
La sortie n’était pas particulièrement accueillante.
Plusieurs résolveurs.
Plusieurs interfaces.
Des domaines de recherche.
Des priorités.
Le DNS du Wi-Fi.
Le DNS du VPN.
Mais au milieu de tout ça, une chose devenait visible : le domaine interne n’était pas associé au résolveur de l’entreprise comme je m’y attendais.
C’est le test que je ferais désormais beaucoup plus tôt.
Je ne demande plus simplement :
« Quel DNS est configuré sur mon Mac ? »
Je demande :
« Quel DNS macOS compte-t-il utiliser pour ce domaine précis ? »
Cette différence paraît minuscule.
Elle explique pourtant pourquoi certains tests manuels donnent l’impression que tout fonctionne alors que Safari continue d’aller au mauvais endroit.
Même dig peut vous rassurer trop vite
À un moment, j’avais interrogé directement le DNS de l’entreprise.
Il me rendait bien l’adresse privée.
J’étais persuadé d’avoir démontré que le DNS fonctionnait.
En réalité, j’avais seulement démontré que ce serveur connaissait la bonne réponse.
Je n’avais pas démontré que Safari lui posait réellement la question.
Un cas publié sur les forums développeurs d’Apple montre bien cette différence : avec un VPN d’entreprise et iCloud Private Relay, l’auteur obtenait la bonne adresse interne avec dig et nslookup, tandis que ping et les applications ordinaires continuaient à recevoir l’adresse publique.
C’est une distinction simple une fois qu’on l’a vue.
dig peut demander directement :
« Que répond ce DNS ? »
Le navigateur demande plutôt à macOS :
« Où se trouve ce domaine ? »
Et c’est macOS qui choisit ensuite quel résolveur consulter.
À ce stade, je savais que le VPN d’entreprise n’était probablement plus le coupable principal.
Restait à découvrir ce qui brouillait la décision du système.
J’avais moi-même ajouté une couche de trop quelques mois auparavant
C’est là que l’histoire est devenue légèrement embarrassante.
J’avais configuré un DNS public manuellement sur le Mac plusieurs mois plus tôt.
À l’époque, cela me paraissait être une amélioration évidente.
Puis j’avais installé un VPN personnel.
Puis le VPN d’entreprise.
Puis quelques réglages supplémentaires dans le navigateur.
Individuellement, chaque couche avait une bonne raison d’exister.
Ensemble, elles formaient un système dont je ne savais plus expliquer la priorité.
La question n’était donc plus :
« Pourquoi macOS ignore-t-il le VPN ? »
Elle était devenue beaucoup plus inconfortable :
« Pourquoi ai-je donné à plusieurs outils le droit de décider où trouver le même domaine ? »
Et là, ajouter encore un réglage aurait été exactement la mauvaise réponse.
La réparation était beaucoup moins spectaculaire qu’un changement de serveur
J’ai remis le DNS manuel du Mac en automatique.
J’ai arrêté de forcer un résolveur différent dans le navigateur pendant le diagnostic.
Puis la configuration du VPN d’entreprise a été corrigée pour que le domaine interne soit bien associé au split DNS.
Déconnexion.
Reconnexion.
scutil --dns.
Cette fois, le suffixe interne apparaissait dans le contexte attendu.
J’ai rouvert :
preview.entreprise.com
Adresse privée.
La page interne s’est chargée.
J’ai ouvert le tableau de bord que je devais vérifier, validé la nouvelle version puis envoyé mon retour à l’équipe.
C’était terminé.
Je n’avais pas trouvé un serveur VPN plus puissant.
J’avais simplement remis le nom de domaine devant le résolveur qui connaissait son adresse interne.
Et après avoir compris ça, j’ai surtout eu envie d’éviter de recréer le même désordre avec mon VPN personnel.
Je ne voulais plus d’un deuxième panneau d’administration réseau sur mon Mac
J’avais encore besoin d’un VPN personnel en dehors de mes sessions d’entreprise, notamment lorsque je travaille ailleurs ou que j’utilise un réseau que je ne contrôle pas.
Mais je ne voulais plus entretenir en parallèle un autre petit univers de protocoles, de serveurs et de réglages DNS.
C’est là que OnlydogVPN↗ a trouvé une place beaucoup plus naturelle sur mon Mac.
Je ne l’utilise évidemment pas pour remplacer le VPN d’entreprise. Il ne possède ni les routes privées ni les DNS internes de mon employeur.
Je l’utilise lorsque cette session professionnelle est terminée.
Au lieu de reconstruire une configuration personnelle compliquée, je choisis le mode correspondant à mon usage — par exemple la confidentialité — puis je laisse l’application gérer la route.
Après une soirée entière passée à comprendre quel logiciel contrôlait quel DNS, cette simplicité n’avait plus rien de décoratif.
Moins de réglages personnels signifiait moins de chances de brouiller à nouveau le contexte réseau dont mon travail avait besoin.
Le petit service possède moins de régions, moins d’années d’historique public et moins d’avis indépendants qu’un grand fournisseur établi.
Mais sur ce Mac, je ne cherchais justement plus une deuxième console d’administration.
Je voulais un VPN personnel qui reste simple à retirer de l’équation dès que le VPN de l’entreprise doit reprendre la main.
Le détail qui m’a fait garder cette séparation
Une fois le travail terminé, j’ai lancé le mode confidentialité pour ma navigation personnelle.
Je n’ai pas eu besoin de créer un autre compte classique avec une nouvelle combinaison email-mot de passe pour commencer l’usage de base.
Ce n’était pas la fonction qui avait réparé mon DNS.
Mais après une panne où j’avais passé une heure à démêler profils VPN, résolveurs et couches réseau, elle allait exactement dans le bon sens :
une dépendance de moins à entretenir.
Le lendemain matin, j’ai coupé le VPN personnel avant d’ouvrir ma session de travail et laissé le profil d’entreprise reprendre seul la responsabilité de ses domaines internes.
Le portail a continué à résoudre vers son adresse privée.
C’est cette séparation que j’ai gardée.
Quand un domaine interne renvoie une IP publique, je ne commence plus par le serveur VPN
Je regarde d’abord si l’adresse publique est une véritable réponse DNS publique.
Puis je teste l’adresse privée directement.
Si l’IP privée fonctionne à travers le VPN mais que le nom mène vers Internet, le tunnel descend immédiatement dans ma liste de suspects.
Je regarde le DNS.
Sur macOS, scutil --dns permet de voir les différents résolveurs et les domaines qui leur sont associés.
Ensuite, je cherche les couches susceptibles de concurrencer cette décision :
DNS manuel du Mac,
DNS chiffré du navigateur,
Private Relay,
second VPN,
outil de filtrage,
profil d’entreprise.
Le but n’est pas de tout désactiver pour toujours.
Le but est que chaque outil ait une responsabilité claire.
Le VPN d’entreprise doit connaître ses routes privées et ses domaines internes.
Mon VPN personnel doit protéger ma navigation personnelle sans compliquer ce contexte professionnel.
Et macOS doit pouvoir savoir sans ambiguïté à quel DNS poser chaque question.
Je pensais qu’une adresse IP publique prouvait que le VPN avait raté sa route.
En réalité, le tunnel avait déjà atteint l’entreprise : c’était le nom du service qui était parti demander son chemin à Internet.
Questions fréquentes
Pourquoi une IP privée peut-elle fonctionner alors que le nom du même service renvoie une IP publique ?
Parce que le tunnel et la résolution DNS sont deux étapes différentes. Si l’IP privée répond, le VPN sait déjà atteindre le réseau interne ; le nom peut néanmoins être résolu par un DNS public qui renvoie l’adresse publique prévue pour Internet.
Que montre scutil --dns que le simple statut « VPN connecté » ne montre pas ?
La commande permet d’examiner les résolveurs utilisés par macOS, leurs priorités et les domaines qui leur sont associés. Elle aide donc à vérifier quel DNS est réellement prévu pour le domaine interne concerné.
Changer de serveur VPN ou vider le cache DNS suffit-il dans ce cas ?
Pas si la mauvaise règle de résolution reste en place. Vider le cache supprime une réponse mémorisée, mais le même DNS public peut rendre immédiatement la même IP ; changer de serveur ne modifie pas forcément l’association du domaine au résolveur interne.