Quel outil macOS peut forcer une seule app à passer uniquement par le VPN ?
Une limite « VPN uniquement » a besoin à la fois d’un chemin et d’un refus. Comparez les profils par app, les proxys, les filtres et PF, puis testez l’app qui vous importe.
Une ligne dans un document d’exigences, « cette app peut utiliser le VPN, et rien d’autre », demande discrètement deux mécanismes qu’aucun interrupteur unique ne fournit. Le trafic a besoin d’un chemin à travers le tunnel prévu, et le trafic qui sortirait directement doit être refusé. Les outils qui font bien l’un et pas du tout l’autre sont courants, c’est pourquoi une comparaison qui demande seulement si quelque chose peut bloquer répond avec assurance à la moitié de la question. Écrivez d’abord la limite, puis choisissez les composants qui couvrent ses deux moitiés.
Deux exigences cachées dans une seule phrase
L’acheminement est la partie qui place une connexion dans le tunnel ou le proxy. Le refus est la partie qui empêche la même connexion de sortir par une autre route. Des composants différents les mettent en œuvre, ils échouent de manières différentes, et un produit peut être excellent dans l’un sans rien dire de l’autre :
| Approach | Steers traffic | Refuses direct egress | Knows the app identity |
|---|---|---|---|
| Per-app VPN profile | Yes, for the apps it names | Only if a filter or firewall also blocks | Yes, within its own rules |
| Application proxy setting | Partly, for requests that honour it | No | No |
| Content filter | No | Yes | Yes, if the filter is written that way |
| Local PF ruleset | No | Yes, by address and port | Not reliably |
Lisez le tableau comme une liste de contrôle et non comme un classement. Aucune ligne ne remplit les deux colonnes centrales, et les lignes qui les couvrent sont deux composants qui coopèrent : l’un possède le chemin, l’autre possède le refus. La colonne d’identité compte pour une autre raison, car une règle qui ne peut pas nommer l’app ne peut pas appliquer une règle sur cette app. Quoi que vous déployiez, il doit répondre aux trois, sinon la limite du document d’exigences n’est pas la limite sur la machine.
L’acheminement seul laisse une sortie
Le réglage de proxy d’application est l’exemple le plus clair d’un acheminement sans refus. Il peut acheminer les requêtes d’une app qui respecte le proxy système et ne couvre rien d’autre : un processus auxiliaire, un logiciel de mise à jour, un service en arrière-plan ou un autre protocole peuvent suivre leur propre chemin sans jamais lire cette préférence. Choisir un point de terminaison SOCKS dans un panneau ne crée donc pas de politique d’absence de sortie directe pour l’application. Si l’exigence porte sur l’app dans son ensemble, demandez quels composants la règle identifie réellement.
Un profil VPN par app achemine mieux qu’un proxy, parce que la plateforme décide quelles apps entrent dans le tunnel au lieu que chaque app en décide elle-même. Pourtant il ne refuse rien : le profil fournit un chemin, et le trafic qui n’y correspond pas prend la route ordinaire. C’est exactement dans cet écart qu’un second composant gagne sa place, et c’est pourquoi les produits qui ressemblent à un interrupteur unique en sont généralement deux.
Le refus seul casse l’app
La documentation d’Apple sur les filtres de contenu décrit un verdict autoriser-ou-bloquer sur le trafic lorsqu’il traverse la pile réseau. Ce verdict n’est ni un tunnel ni une connexion proxy, car il décide si quelque chose peut continuer, et non où il va. Un filtre seul applique parfaitement le refus et laisse l’application inutilisable, avec des journaux propres et sans explication. Le verdict d’un filtre peut arrêter une connexion mais ne fournit jamais le tunnel, donc l’associer à l’acheminement est la décision de conception et non un supplément facultatif.
Un ensemble de règles PF administré localement se situe à l’autre extrémité de ce spectre. C’est une décision de support légitime sur une machine qu’un administrateur possède, et ce n’est pas automatiquement la base d’un produit distribuable, car celui qui possède l’ensemble de règles possède aussi ses interactions avec les autres utilisateurs du pare-feu, son chemin de mise à jour et sa récupération lorsqu’une règle est erronée. Ajouter PF à un produit ne supprime pas cette question de propriété ; il la définit.
Le déploiement décide si la règle existe encore demain
La manière dont une Network Extension est déployée sur les plateformes Apple dépend du type de fournisseur, du conditionnement et de la version du système d’exploitation devant vous. Une extension d’app sur macOS s’exécute dans un contexte utilisateur et se termine lorsque cet utilisateur se déconnecte, tandis qu’une extension système a un contexte global qui ne dépend pas de la session. Si la protection doit survivre à une déconnexion, cette différence est toute la conception et non une note de bas de page. Confirmez la voie de déploiement avant de promettre le comportement, car le même code atterrit différemment selon le type d’extension livré.
La disponibilité des sources est une question distincte de l’application. Lire un dépôt vous dit comment quelque chose est implémenté, pas ce que le binaire installé est autorisé à faire sur cette machine. La signature, l’installation et l’autorisation s’appliquent toujours, et des instructions bâties autour d’une extension de noyau obsolète ou d’une astuce d’injection de bibliothèque décrivent une autre plateforme et une autre posture de risque, aussi bien qu’elles aient pu fonctionner autrefois.
Un cas d’acceptation qui nomme l’app
Choisissez une seule action que l’application effectue d’elle-même, notez l’adresse qu’elle devrait atteindre et si cette adresse est en IPv4 ou en IPv6, puis répétez la même action dans l’état approuvé sans tunnel. La seconde exécution doit produire le refus déclaré et non une nouvelle tentative directe silencieuse. C’est la moitié que les gens laissent non spécifiée, et la seule moitié qui prouve que le refus existe. Exécutez-la d’abord avec le tunnel disponible, afin qu’une différence entre les deux résultats ne puisse venir que du tunnel manquant.
Parcourez ensuite les transitions que l’exigence nomme : redémarrage de l’app, déclenchement d’un processus auxiliaire, reconnexion du tunnel, changement de réseau de la machine, et déconnexion ou redémarrage là où elles s’appliquent. Une page d’IP publique dans un navigateur n’est pas un test des sockets d’une autre application, elle ne peut donc pas remplacer celui-ci. Là où aucun déploiement pris en charge ne couvre le comportement réel de l’app, un environnement isolé autorisé avec une passerelle explicite et sans sortie alternative est une décision de confinement avec son propre coût de gestion, et non un substitut de case à cocher.
Terminez en notant quatre entrées : de quels composants l’app est faite, qui possède l’acheminement, qui possède le refus, et les états dans lesquels la règle doit encore tenir. Un dépôt public peut être un critère de sélection, mais il n’est pas l’une des quatre, et ce sont ces entrées qui décident si un outil donné satisfait l’exigence réseau.