Client VPN Mac : Network Extension contre System Extension

Deux termes Apple sont employés comme s'ils désignaient la même chose, et cette confusion envoie les gens vers le mauvais panneau de réglages. Network Extension décrit une capacité : une manière prise en charge d'implémenter des tunnels VPN, des proxys et des filtres. System Extensions décrit un mécanisme de livraison et d'approbation pour les extensions en espace utilisateur. Un client VPN Mac moderne a généralement besoin des deux, ce qui explique qu'aucune des deux étiquettes ne suffise à expliquer un symptôme. Séparer les deux répond quel composant inspecter et quelle étape d'approbation attendre.

Deux questions, pas une étiquette

Demandez ce que fait le composant avant de demander comment il s'installe. La capacité décide quelle classe de fournisseur existe et donc quel code traite vos paquets. Le mécanisme de livraison décide comment le binaire arrive, comment il est approuvé et où son état est enregistré. Un produit peut implémenter un tunnel de paquets sans livrer d'extension système sur les versions antérieures, et il peut livrer une extension système qui implémente autre chose qu'un tunnel.

Les extensions de noyau sont le troisième terme que les gens mélangent. C'étaient l'ancienne manière d'exécuter du code réseau privilégié, elles exigeaient d'autres approbations, et Apple détourne les développeurs d'elles depuis des années. Appliquer une recette d'approbation d'extension de noyau à un client moderne fait perdre du temps sur une boîte de dialogue qui n'apparaîtra jamais.

Lisez les notes de déploiement du fournisseur pour la version de macOS que vous utilisez plutôt qu'un message de forum d'une version antérieure. L'architecture a changé plus d'une fois, et les instructions vieillissent mal. Une note qui mentionne l'approbation d'extension de noyau décrit une autre époque du produit.

Ce que fournit Network Extension

Le cadre fournit des types de fournisseur pour les tâches réseau courantes : un tunnel de paquets pour le trafic VPN, un proxy d'application pour les flux par application, un filtre de contenu pour inspecter le trafic et la gestion du proxy DNS pour le comportement du résolveur. Le type de fournisseur détermine ce que l'extension peut faire, et un client qui livre deux fournisseurs peut effectuer deux tâches différentes.

Cela compte pendant le diagnostic, car le même symptôme de connectivité peut venir d'un tunnel, d'un filtre ou d'un proxy DNS. Bloquer un site web est une décision de filtre, ne pas atteindre un sous-réseau privé est généralement une décision de tunnel, et résoudre la mauvaise adresse est généralement une décision de résolveur. Nommer le type de fournisseur resserre la recherche avant qu'un journal ne soit lu.

Rien dans le cadre n'implique une posture de confidentialité. Une extension en espace utilisateur a toujours des autorisations, une configuration et un opérateur derrière elle, alors traitez l'architecture comme un détail d'implémentation et non comme un signal de confiance. Demandez qui exploite le point de terminaison et ce qu'il est configuré pour collecter.

Ce que change System Extensions

Le mécanisme déplace le code privilégié hors du noyau vers l'espace utilisateur, et il change la manière dont le système d'exploitation demande le consentement. L'activation est une étape distincte de l'installation, et l'utilisateur ou un profil MDM doit l'autoriser. Un client qui s'installe mais ne s'active jamais semble présent dans le dossier Applications et ne fait rien pour la connectivité.

L'état est enregistré par le système plutôt que par l'application, ce qui est utile car il peut être interrogé. La commande ci-dessous liste les extensions que le système connaît et leur état d'activation.

systemextensionsctl list
scutil --nc list

La première commande répond si le composant est installé et activé. La seconde liste les configurations VPN que le système détient, ce qui est une autre question et souvent celle qui compte quand un profil de connexion manque plutôt qu'il n'est cassé.

Laquelle inspecter pour un symptôme donné

Associez le symptôme à la couche avant d'ouvrir un panneau de réglages. Une configuration absente est une question de profil, un composant installé mais inactif est une question de livraison, et un composant actif qui ne peut pas faire passer le trafic est une question de capacité.

Le flux de journal est la preuve commune des deux dernières lignes. Lire le sous-système d'extension réseau indique quel fournisseur a traité le flux, et une décision de filtre se présente différemment d'une panne de tunnel même lorsque l'utilisateur décrit les deux comme un VPN cassé.

log show --last 10m --predicate 'process == "nesessionmanager"'

Ne concluez pas qu'une extension est active parce qu'une icône est présente dans la barre de menus. Les icônes survivent aux activations échouées, et une icône obsolète est l'une des raisons les plus courantes pour lesquelles un appel au support commence au mauvais endroit. Lisez plutôt l'état d'activation, car c'est ce que le système enregistre.

Approbation, MDM et le mythe de l'extension de noyau

Sur les Mac gérés, l'étape d'approbation appartient au profil MDM, et un utilisateur qui clique sur Allow dans System Settings peut encore être bloque par une stratégie qui n'a pas été mise à jour. Demandez à l'équipe de postes de travail quel mécanisme approuve l'extension pour ce parc avant de demander à l'utilisateur de cliquer sur quoi que ce soit.

Sur un Mac non géré, l'invite d'approbation apparaît une fois et un refus peut être définitif jusqu'à ce que l'extension soit réinstallée. Ce comportement explique la machine où le client fonctionnait avant une mise à jour du système et signale maintenant une connexion qui ne s'établit jamais.

Notez le type de fournisseur, l'état d'activation et le mécanisme d'approbation du client que vous déployez. Ces trois faits répondent à la plupart des questions futures sur un VPN Mac sans rouvrir le débat entre capacité et livraison.