VPN Mac, filtre de contenu ou Private Relay : lequel est actif
Trois couches réseau du Mac se ressemblent dans Réglages. Distinguez un VPN, un filtre de contenu et Private Relay par le chemin de sortie, la politique de flux et la portée de navigation.
Votre Mac peut avoir installés en même temps un tunnel VPN, un filtre de contenu et iCloud Private Relay, et aucun d'eux n'annonce lequel façonne une connexion donnée. Les panneaux de réglages se ressemblent, les icônes se ressemblent, et presque tous les fournisseurs appellent leur produit sécurité réseau. Trois faits les séparent : si le trafic sort par un point distant que vous pouvez nommer, si un moteur de politique décide autoriser-ou-rejeter sur des flux individuels, et si la protection s'arrête à Safari. Mettez ces trois points au clair et la plupart des questions du type mon-VPN-est-il-actif se répondent d'elles-mêmes.
Trois conditions qui identifient le composant
La première condition est la sortie. Un fournisseur de tunnel remet les paquets à une passerelle distante, donc votre adresse publique change et, si le profil le prévoit, les hôtes derrière cette passerelle deviennent joignables. Si l'adresse ne change jamais et qu'aucun sous-réseau privé ne s'ouvre, vous ne regardez pas un tunnel fonctionnel, quoi qu'en dise la barre des menus.
La deuxième condition est la décision. Un filtre de contenu évalue des flux et renvoie autoriser ou rejeter. Il peut appliquer un blocage de catégorie, une règle par application ou une politique poussée par un employeur, et il peut journaliser le verdict. Ce qu'il ne peut pas faire seul, c'est donner au trafic un endroit où aller.
La troisième condition est la portée. Private Relay protège une tranche définie de la navigation plutôt qu'un appareil entier, et son rôle est de séparer qui vous êtes de ce que vous visitez, non de vous placer sur un autre réseau.
Alignez les trois et les frontières sont difficiles à manquer :
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
Un filtre de contenu est un moteur de politique, pas une sortie
Sur macOS, un filtre arrive sous forme de Network Extension bâtie sur la classe de fournisseur de données de filtrage d'Apple, NEFilterDataProvider. Dans un déploiement géré, il est poussé par MDM, installé comme extension système et approuvé une fois dans Réglages Système > Général > Ouverture et extensions. À partir de là, il voit des flux TCP, et dans certaines configurations UDP aussi, et renvoie un verdict pour chacun.
Le mode de défaillance est ce qui déroute les gens. Un filtre qui rejette un flux produit un délai d'attente expiré, une poignée de main TLS bloquée ou une réinitialisation, ce qui ressemble exactement à un tunnel monté qui ne laisse pas passer le trafic. L'adresse publique n'a jamais changé, parce qu'il n'y avait aucune sortie pour la changer.
Les clients commerciaux regroupent souvent les deux rôles. Un seul installateur fournit un fournisseur de tunnel et un filtre, le filtre bloque et le tunnel route. Le nom de l'application ne vous dit donc rien sur le composant qui a refusé la connexion. Vérifiez la liste des extensions, puis le service connecté, puis le journal du client, dans cet ordre.
Private Relay couvre Safari, pas la machine
Private Relay envoie la navigation qu'il couvre via deux relais exploités par des parties distinctes, si bien qu'aucun opérateur unique ne détient à la fois votre identité et vos destinations. C'est une conception de confidentialité, pas un tunnel : il n'y a pas de passerelle où entrer, pas de sous-réseau privé et aucun moyen d'épingler une adresse de sortie dans un pays que vous choisissez.
Sa portée est délibérément étroite : elle couvre la navigation Safari ainsi que les requêtes DNS et les chargements HTTP non sécurisés qui l'accompagnent. Une session de terminal, un client de messagerie, une application de discussion et un lanceur de jeux en restent exclus. Si une vérification dans Terminal montre encore l'adresse de votre réseau d'accès alors que Safari affiche une adresse de relais, c'est le résultat attendu, pas une installation cassée.
La disponibilité est conditionnelle. Il faut un abonnement iCloud+, il n'est pas proposé dans toutes les régions, et un réseau géré peut bloquer l'accès au relais, auquel cas Safari revient à une connexion directe. La présentation de Private Relay par Apple fait référence pour la portée actuelle. Lorsqu'un profil VPN est connecté et porte ce trafic, le relais ne s'empile pas par-dessus ; le profil décide du chemin.
Lisez les preuves dans le bon ordre
Commencez par l'état du service, car c'est le signal le moins coûteux. scutil --nc list liste les services VPN configurés et indique si chacun est connecté. Un profil peut rester là des années sans jamais être connecté, et les gens le comptent régulièrement comme un tunnel.
Regardez ensuite les interfaces et les routes. ifconfig montre des interfaces utun, mais leur seule présence prouve peu, car macOS utilise utun à plusieurs fins au-delà du VPN. Ce qui compte, c'est de savoir si la route par défaut pointe vers l'une d'elles, ce que rapporte route -n get default.
Pour la résolution de noms, scutil --dns liste les résolveurs que le système utilisera réellement, et un fournisseur de proxy DNS y apparaît. Comparer dig +short example.com avec dig +short example.com @1.1.1.1 sépare le résolveur qui répond de celui qui est intercepté.
L'activité des extensions parvient au journal unifié : log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Vous cherchez quelle extension a démarré et si un filtre a signalé un verdict sur le flux qui vous intéresse, non une ligne à mémoriser.
Précisez le symptôme avant de désactiver quoi que ce soit
Classez d'abord la défaillance. Un nom qui ne se résout pas, une connexion refusée immédiatement et une connexion qui reste suspendue jusqu'au délai d'attente sont trois observations différentes avec trois responsables différents. La résolution pointe vers un résolveur ou un proxy DNS. Un refus immédiat pointe vers une règle de filtre. Le silence pointe généralement vers le routage, ou vers un tunnel monté mais qui ne transfère pas.
Sur un Mac géré, supposez que le filtre appartient à l'organisation. Le désactiver pour tester le VPN retire le composant que vous vouliez observer, et MDM le rétablit souvent à la prochaine vérification. Demandez le nom de la politique à l'administrateur avant de changer quoi que ce soit, et testez avec l'application précise qui a échoué plutôt qu'avec tout le système.
Un piège de plus : désactiver Private Relay pour tester un VPN ne dit rien du trafic étranger, car le relais n'a jamais couvert ce trafic. Chaque couche doit être testée dans l'application qu'elle gouverne réellement.
Parcourez cette liste et arrêtez-vous au premier point qui échoue :
scutil --nc listaffiche-t-il le service attendu comme connecté ?- L'adresse publique vue depuis Terminal diffère-t-elle de celle attribuée par votre réseau d'accès ?
- Une extension de filtre est-elle installée, et a-t-elle journalisé un verdict pour le flux qui échoue ?
- La défaillance est-elle limitée à Safari ? Si oui, vérifiez la portée du relais avant d'accuser le tunnel.
Si les quatre passent et que l'application échoue toujours, le problème se situe au-dessus de la couche réseau : réglages de proxy, confiance dans les certificats ou liste d'autorisation au niveau de l'application.