Verrou VPN PF sur Mac : une politique de site, pas une fonction livrable

Cela fonctionne sur votre Mac, donc cela ressemble à quelque chose que vous pouvez remettre aux utilisateurs. Cette hypothèse est la première à perdre. Le TN3165 d'Apple indique clairement que Packet Filter n'est pas une API prise en charge pour les produits distribués au sens large, et il présente l'administration de site privilégiée et contrôlée comme le cas raisonnable. Un verrou VPN bâti sur PF est donc une politique d'exploitation locale avec un propriétaire, pas une fonction que vous pouvez livrer dans une application.

PF n'est pas une surface de conditionnement

La distinction n'est pas académique. Un produit distribué qui dépend de PF hérite de chaque changement qu'Apple y apporte, de chaque conflit avec un autre outil qui écrit aussi des règles, et d'aucun engagement de support que l'arrangement continuera de fonctionner. Un site qui administre ses propres machines a une relation différente : il peut documenter la dépendance, la tester contre chaque version du système et accepter la maintenance.

Certains conseils d'installation franchissent une ligne qu'il vaut la peine de nommer. Réécrire tout le jeu de règles du système pour qu'une seule ancre se charge, modifier la configuration de démarrage du système d'Apple ou désactiver System Integrity Protection ne sont pas des exigences acceptables pour une recette réutilisable. Si un guide publié a besoin de l'une de ces choses, il décrit un laboratoire, pas une politique déployable.

Écrivez l'intention de sortie avant la syntaxe

Décidez de ce qui est autorisé avant de choisir un seul mot-clé. Trois chemins doivent généralement exister : le transport propre du client VPN vers son serveur, le trafic de l'application protégée à l'intérieur du tunnel et tout ce que la configuration ou les services locaux exigent vraiment comme chemin direct.

Donnez à chaque exception proposée une destination, un transport et un propriétaire. Autoriser tous les ports vers un point de terminaison permet bien plus que le seul transport utilisé par le tunnel, et l'exposition supplémentaire arrive sans que personne ait décidé qu'elle devait exister. Autoriser un résolveur public est le même piège sous un déguisement plus aimable : il crée un chemin DNS direct même lorsque le tunnel est tombé, si bien que les résolutions de noms fuient encore.

Le test utile pour une exception est de savoir si vous pouvez nommer la personne qui l'a demandée et la panne qu'elle évite. Si aucune des deux réponses n'existe, la règle est probablement un contournement d'une mauvaise configuration qui resterait sinon invisible.

Les numéros utun ne sont pas une identité

MacOS crée des interfaces de tunnel sous forme de périphériques utun, et le numéro attribué à votre VPN n'est pas stable d'un redémarrage, d'une reconnexion ou de la présence d'un autre client à l'autre. Une règle qui énumère plusieurs numéros devinés n'est pas une politique ; c'est un instantané d'un après-midi.

Ancrez la règle à quelque chose qui identifie le fournisseur voulu : le plan d'adressage attribué par le tunnel, le processus qui possède l'interface ou une configuration que le client VPN maintient lui-même. Enregistrez ensuite comment cette identification fonctionne, car la personne qui relira la règle dans un an n'aura pas votre historique de shell.

Rendez la politique chargée attribuable

Un nom d'ancre organise des règles ; il ne prouve pas que la politique effective est celle que vous vouliez. La priorité entre ancres, les règles chargées par d'autres logiciels et l'état existant peuvent tous changer le résultat. Passez en revue l'ensemble effectif avec quiconque possède aussi PF sur cette machine, et documentez la propriété au même endroit que la configuration. Deux propriétaires modifiant des ancres différentes avec des hypothèses différentes, c'est la manière ordinaire dont un verrou développe un trou.

Gardez le jeu de règles dans le chemin de configuration pris en charge du site, versionnez-le et notez quelles versions de macOS ont été testées. Un changement appliqué à la main et retenu par une seule personne n'est pas une infrastructure maintenue, quoi que dise l'en-tête du fichier.

Testez les transitions, pas l'état connecté

Une capture d'écran prise pendant que le tunnel est actif ne prouve presque rien. Parcourez plutôt les états : démarrage avant toute connexion, tunnel fonctionnel, tunnel qui tombe sans avertissement, déconnexion volontaire et passage du Wi-Fi au partage de connexion. Chaque état a sa propre réponse, et les intéressants sont les échecs plutôt que le chemin heureux.

Dans chaque état, notez ce qui est accessible intentionnellement. Vérifiez IPv4 et IPv6 séparément, testez la résolution de noms et incluez un flux déjà établi avant la transition, car les connexions existantes ne suivent pas toujours la nouvelle politique. Un navigateur qui échoue alors que le tunnel est tombé est un point de données, pas la preuve que tous les autres chemins sont bloqués.

Enfin, conservez une méthode de récupération qui ne dépend pas du chemin réseau que vous modifiez. Une configuration bonne connue sur un stockage local et une manière documentée de la charger transforment un verrou en politique ; sans elles, une mauvaise révision enferme l'administrateur hors de la machine censée être protégée.