L’application VPN iPhone sur un Mac Apple Silicon : ce qui tourne réellement

Quelqu’un installe la version iPhone d’un client VPN sur un Mac de la série M, elle s’ouvre, elle se connecte, et l’équipe conclut que la question de la plateforme est réglée. Elle ne l’est pas. Ce qui sépare ici le réglé du simple fonctionnement, c’est la différence entre une extension d’application dans une session utilisateur et une extension système à contexte global. Apple prend bien en charge les fournisseurs de tunnel de paquets dans le modèle applications iOS sur Mac, et répertorie ce montage séparément du macOS natif et de Mac Catalyst. Ce que signifie cette prise en charge est plus étroit que cela n’en a l’air. Elle dit que le montage est autorisé, pas qu’une application donnée le fait bien, ni que le tunnel couvre ce que vous supposez.

Trois montages, un tableau

Trois montages comptent sur un Mac et ils ne sont pas interchangeables. Un client macOS natif livre une extension système, qui s’exécute dans un contexte global et peut être présente avant que quiconque se connecte. Une application iPhone sur Apple Silicon livre une extension d’application, qui s’exécute dans la session de l’utilisateur et se termine avec elle. Mac Catalyst appartient à la même famille d’empaquetage que la version téléphone, mais c’est une cible différente avec sa propre ligne de déploiement.

La comparaison ci-dessous est la partie des consignes de déploiement d’Apple qui vaut la peine d’être mémorisée, car elle répond à la plupart des questions de conception avant un appel à un fournisseur.

Lisez la colonne d’empaquetage avant la page marketing : elle prédit ce qui se passe à la déconnexion bien plus fiablement que n’importe quelle liste de fonctions.

Ce que prouve une requête réussie

La ligne applications iOS sur Mac est un montage réellement pris en charge et non une astuce de simulateur, et c’est pourquoi la question revient sans cesse. Elle hérite aussi de la distribution via le Mac App Store, donc une application dont l’éditeur n’a jamais activé la disponibilité Mac n’apparaîtra pas, quelle que soit la tolérance de la documentation développeur.

Une connexion fonctionnelle prouve qu’une requête d’une application a atteint sa destination. Elle n’inventorie ni le résolveur du navigateur, ni les applications exclues, ni la seconde famille d’adresses, ni les appareils locaux que l’utilisateur compte encore joindre. Un tunnel de paquets transporte ce que disent ses routes et sa portée, et cette portée vient de la configuration de l’application, non de l’existence du tunnel.

L’écart tient généralement à la couverture par application

Un client qui achemine tout est facile à décrire et facile à tester. Celui qui inclut une liste définie d’applications exige que ces règles soient respectées dans ce déploiement, pas seulement dans la version Mac native. L’accès aux appareils locaux, les exceptions de tunnel partagé et tout ce qui dépend d’un élément de barre de menus que la version téléphone n’a jamais eu se heurtent au même mur.

Demandez la portée par écrit, puis testez le second cas plutôt que le premier. N’importe qui peut montrer un navigateur atteignant Internet par le tunnel.

Où les deux divergent en exploitation

La durée de session est la différence la plus nette et la moins visible en démonstration. Apple documente les extensions d’application comme s’exécutant dans un contexte utilisateur et se terminant à la déconnexion, donc un Mac qui redémarre sur une fenêtre de connexion n’a pas de tunnel tant que personne ne se connecte. Si l’exigence couvre une machine à protéger avant authentification, la version téléphone ne peut pas y répondre, quelle que soit la rédaction du profil.

Tout le reste est relativement cosmétique : une présence dans la barre de menus, la façon dont le DNS est affiché, si l’application peut quitter alors que le tunnel reste actif. Ce sont de vraies différences d’usage et non des décisions d’architecture, alors classez-les après la question de la session.

Décidez dans un ordre fixe

Ordonnez les questions délibérément : couverture sans assistance d’abord, portée par application ensuite, distribution en troisième, finition de l’interface en dernier. Seul un client natif doté d’une extension système répond à la première, et il atteint l’appareil via MDM et un profil géré. Une application iOS sur Apple Silicon est une réponse raisonnable quand une personne est devant la machine, se connecte et veut le tunnel pour cette session.

Avant de vous engager, posez trois questions précises à l’éditeur. Le fournisseur de tunnel de paquets est-il pris en charge dans le déploiement applications iOS sur Mac, les règles par application s’y appliquent-elles, et que se passe-t-il à la déconnexion. Un fournisseur qui répond aux trois en un seul message connaît sa surface de déploiement ; celui qui ne répond qu’à la première décrit une application qui s’ouvre sur un Mac.

Vérifiez ensuite sur la machine que vous allez prendre en charge, avec le compte et la passerelle que vous utiliserez réellement. Une version téléphone connectée à une passerelle de test sur un seul portable est une preuve, pas un déploiement.