Un VPN affiché « connecté » ne garantit pas que tout le trafic passe par le tunnel. Sur macOS, l'étanchéité repose entièrement sur le client — il faut donc la tester.
« Le VPN est connecté » et « tout mon trafic est protégé » sont deux affirmations différentes. Entre les deux se glissent les fuites DNS, les fuites IPv6, la fenêtre de reconnexion et l'absence de coupe-circuit au niveau du système. Cette page décrit ces failles sur macOS et donne une méthode de test avec les outils intégrés. Elle prolonge la vue d'ensemble sur le VPN pour Mac sur un point concret et vérifiable.
Sur certaines plateformes mobiles, le système d'exploitation propose un « VPN permanent » qui bloque tout trafic hors tunnel, indépendamment de l'application. macOS n'a pas d'équivalent intégré. Le coupe-circuit — le fait de couper l'accès réseau si le tunnel tombe — est une fonction du client VPN, pas du système. Cela a deux conséquences : un client sans coupe-circuit laisse passer le trafic en clair dès que le tunnel se rompt, et un coupe-circuit applicatif dépend du bon fonctionnement de l'application, qui peut planter ou être fermée.
Certains clients installent des règles dans le pare-feu de filtrage de macOS pour obtenir un blocage plus robuste, qui tient même si l'interface du client ne répond plus. La présence et la qualité de ce mécanisme sont un point à vérifier avant de choisir un service. Un bon indicateur : le client propose un mode « bloquer tout le trafic hors VPN » distinct d'un simple « reconnexion automatique », et il documente ce que ce mode fait pendant le démarrage et pendant les mises en veille prolongées.
Entre l'ouverture de session et le moment où le client VPN est chargé et le tunnel établi, le Mac a un accès réseau normal. Les applications qui se lancent automatiquement, les processus de synchronisation, les mises à jour peuvent émettre des requêtes pendant cette fenêtre, avec l'adresse IP réelle. Les clients sérieux proposent une option « se connecter au démarrage » et un blocage actif dès l'ouverture de session, avant même que le tunnel soit prêt. Sans cela, chaque redémarrage crée une brève exposition.
Toutes les transitions réseau — sortie de veille, passage du Wi-Fi au partage de connexion, changement de serveur — imposent au tunnel de se rétablir. La durée de cette reprise dépend du protocole. WireGuard, sans état au niveau du transport, reprend dès le premier paquet chiffré échangé, souvent en moins d'une seconde. IKEv2 avec l'extension MOBIKE maintient la session lors d'un changement d'adresse. OpenVPN impose une renégociation complète, plus lente. Plus la reprise est longue, plus la fenêtre pendant laquelle un coupe-circuit défaillant laisserait fuir du trafic est large. Sur un Mac qui change souvent de réseau, WireGuard ou IKEv2 réduisent nettement ce risque.
Certains clients permettent d'exclure des applications du tunnel — pour une application bancaire qui refuse les connexions VPN, ou pour garder un débit maximal sur un service local. C'est utile, mais une configuration par exclusion se retourne facilement contre soi : une application ajoutée à la liste, ou une liste réinitialisée par une mise à jour, laisse sortir en clair un trafic que l'on croyait protégé. Après toute mise à jour du client, il faut revérifier quelles applications sont réellement dans le tunnel.
Si le client ne force pas les requêtes DNS dans le tunnel, elles partent vers le résolveur configuré sur le réseau — celui du fournisseur d'accès ou du point Wi-Fi. L'adresse IP est alors masquée, mais la liste des domaines consultés reste visible pour l'opérateur du réseau, ce qui annule une grande partie de l'intérêt du VPN.
Sur macOS, deux subtilités compliquent la situation. Le système garde un cache DNS géré par le processus mDNSResponder, qui peut conserver des réponses obtenues avant l'activation du tunnel. Et le réglage « DNS privé » chiffré, s'il est activé au niveau du système, peut coexister mal avec certains clients VPN — soit il court-circuite le résolveur du tunnel, soit l'inverse. En cas de doute, vider le cache DNS après connexion et vérifier au test que les requêtes sortent bien par le serveur VPN.
Beaucoup de services ne routent que l'IPv4 dans le tunnel. Si la connexion — fixe ou en partage depuis un téléphone — fournit de l'IPv6, le trafic vers les services accessibles en IPv6 sort hors tunnel avec l'adresse IPv6 réelle, qui identifie l'abonnement aussi sûrement qu'une IPv4. Un client correct route aussi l'IPv6 ou le désactive pendant la connexion. macOS permet de désactiver l'IPv6 par interface en ligne de commande si le client ne le gère pas.
VPN activé, ouvrir un site de test de fuites depuis le navigateur : vérifier que l'adresse IPv4 affichée est celle du serveur VPN, qu'aucune adresse IPv6 réelle n'apparaît, que les serveurs DNS listés appartiennent au VPN, et que la section WebRTC n'expose pas d'adresse réelle. Dans le Terminal, scutil --dns montre les résolveurs actifs et curl ifconfig.co affiche l'adresse de sortie. Refaire le test en Wi-Fi puis en partage de connexion mobile.
Pour vérifier le coupe-circuit : VPN activé, lancer un téléchargement continu, puis couper le Wi-Fi quelques secondes et le rétablir. Pendant la coupure et la reconnexion, aucune donnée ne doit passer si le coupe-circuit est efficace. Si le téléchargement se poursuit brièvement sur la connexion normale, le client laisse une fuite lors des transitions.
Dans les navigateurs, la technologie WebRTC peut, via une requête à un serveur STUN, révéler des adresses IP indépendamment du tunnel. Sur Mac, le risque concerne surtout Chrome et Firefox ; Safari est plus restrictif. Les navigateurs proposent un réglage ou une extension pour limiter cette fuite ; le test de fuites en montre le résultat. À noter que si le VPN route correctement tout le trafic, y compris celui destiné aux serveurs STUN, l'adresse révélée sera celle du serveur VPN et non l'adresse réelle — la fuite WebRTC n'est réellement problématique que combinée à une autre faille de routage.
Les mises à jour majeures de macOS modifient parfois la pile réseau, la gestion des extensions ou les réglages de confidentialité. Un client VPN qui fonctionnait peut se retrouver avec son extension désactivée, son coupe-circuit inopérant ou son réglage DNS ignoré. Après chaque montée de version, il est prudent de refaire le test de fuites complet et de vérifier que l'extension du client est toujours autorisée dans les réglages système. C'est aussi l'occasion de contrôler que le client lui-même est à jour : un éditeur sérieux publie une version compatible avant ou peu après la sortie d'une nouvelle version de macOS.
Une fuite DNS ou IPv6 ne se corrige pas côté utilisateur si elle vient d'une mauvaise configuration des serveurs de l'opérateur : c'est un motif d'écarter le service. Une fuite au démarrage ou lors des coupures se corrige en activant le coupe-circuit et la connexion au démarrage du client, quand ils existent. Un client qui n'offre ni coupe-circuit robuste ni gestion correcte du DNS et de l'IPv6 ne devrait pas être retenu, quels que soient ses tarifs — ce que reprend la grille d'évaluation. Sur un réseau public, ces vérifications sont d'autant plus importantes, comme le rappelle la page sur le Wi-Fi public.