Always On VPN ou VPN On Demand sur iPhone : que déployer

Deux iPhone peuvent tous deux annoncer VPN et se comporter de façon radicalement différente. On Demand ouvre un tunnel dès qu’une règle correspond, et l’utilisateur peut toujours le désactiver dans Réglages. Always On géré maintient la couverture imposée sur un appareil supervisé, y compris aux moments où le tunnel ne peut pas monter. Choisissez en demandant ce qui doit être vrai lorsque l’utilisateur ne fait rien, puis testez les transitions plutôt que l’état stable. Les étapes ci-dessous suivent l’ordre dans lequel un déploiement échoue réellement.

Étape 1 : établir ce que l’appareil peut imposer

Always On est une fonctionnalité réservée aux appareils supervisés. Si le parc n’est pas supervisé, la discussion est close avant de commencer, et aucune clé de payload ne transforme un téléphone non supervisé en appareil imposé. Confirmez la supervision du côté de la gestion et depuis l’appareil, puis confirmez qui a signé le profil.

Sur le téléphone : Réglages, puis Général, puis VPN et gestion de l’appareil. L’entrée du profil nomme son propriétaire, et un profil personnel installé à la main ne ressemble pas à celui livré par un service de gestion. Ne déduisez pas l’imposition du nom du profil ni d’une étiquette marketing de fournisseur ; l’étiquette n’est pas la politique de la plateforme.

Notez trois faits avant de toucher à la configuration : supervisé ou non, profil géré ou personnel, et quel client transporte le tunnel. Chaque étape ultérieure dépend de ces trois, et transférer un comportement d’un téléphone personnel vers un profil géré est la façon dont un déploiement est validé sur une mauvaise base.

Étape 2 : lire les règles on-demand, pas le nom de la fonctionnalité

On Demand est une liste de règles évaluées dans l’ordre. Chaque règle nomme une action et les conditions qui la sélectionnent, et les conditions sont la partie intéressante : type d’interface, SSID Wi-Fi, suffixe de domaine DNS ou URL de sonde. Un jeu de règles qui ne correspond jamais est une fonctionnalité qui ne se connecte jamais.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Lisez tout le tableau et posez deux questions par règle : cette condition peut-elle un jour être vraie sur ce parc, et que se passe-t-il quand aucune règle ne correspond ? Les réseaux d’entreprise renomment les points d’accès, fusionnent les SSID et changent les suffixes DNS, et chacune de ces modifications détache silencieusement une règle de la réalité.

La condition de suffixe DNS est la plus souvent fausse sur le terrain, car le suffixe qu’un téléphone signale sur un réseau invité n’est pas celui que sert le résolveur d’entreprise. Vérifiez le nom que l’appareil résout réellement avant de faire confiance à la règle.

Étape 3 : tester les transitions, pas la connexion statique

Un tunnel qui est monté pendant que vous le regardez prouve très peu. Exécutez chaque transition délibérément et notez ce que fait l’appareil, en utilisant la même ressource privée à chaque fois pour que les résultats soient comparables :

• Rejoignez un réseau où une règle devrait correspondre, puis demandez la ressource privée et confirmez qu’elle se charge.
• Passez au réseau cellulaire avec l’application en arrière-plan, ramenez-la au premier plan et répétez la requête.
• Connectez-vous à un Wi-Fi avec portail captif et voyez si le portail est joignable ou si l’imposition le bloque avant que vous puissiez vous authentifier.
• Désactivez le tunnel à la main sur un appareil supervisé et vérifiez s’il revient de lui-même, et à quelle vitesse.

Exécutez la même liste sur un appareil non supervisé si vous en avez un. La différence entre les deux résultats est le comportement réel du déploiement, et c’est la partie qu’une capture d’un tunnel connecté ne montre jamais.

Étape 4 : connaître les deux formes de défaillance

La couverture imposée échoue en bloquant. Quand le tunnel ne s’établit pas, l’appareil perd l’accès internet ordinaire en même temps que les ressources privées, et l’utilisateur vit un téléphone en ligne mais incapable de naviguer. Reconnexion et blocage sont des observations distinctes, donc journalisez les deux au lieu de traiter l’absence d’internet comme un seul symptôme.

On Demand échoue en ne se déclenchant pas. La règle ne correspond pas, aucun tunnel n’apparaît, et la ressource privée expire simplement. C’est facile à diagnostiquer à tort comme un problème de serveur, car le client se comporte exactement comme configuré.

Un portail captif se situe entre les deux : il a besoin de connectivité avant que le tunnel existe, donc une politique qui bloque tout jusqu’à ce que le tunnel monte a besoin d’un chemin documenté à travers le portail. Décidez-le à la conception, pas au centre d’appel.

Étape 5 : vérifier, puis répéter le retour arrière

La vérification se fait sur le chemin réel avec un trafic inoffensif : demandez une ressource privée qui ne doit pas être publique, confirmez quelle adresse l’appareil présente vers l’extérieur, et répétez après un redémarrage pour avoir vu la séquence de démarrage et pas seulement l’état chaud.

Répétez ensuite la suppression sur un appareil de test avant d’en avoir besoin en production. Retirer le profil ramène l’appareil à son état précédent, et savoir combien de temps cela prend et ce que l’utilisateur voit fait partie du runbook. Le guide de sécurité VPN d’Apple est la référence de ce que la plateforme documente sur ces politiques, et il vaut la peine d’être lu avant d’écrire une configuration qui affirme plus que la plateforme.

Gardez les trois faits de la première étape à côté du jeu de règles et des résultats de test. Quand la personne suivante demandera pourquoi un téléphone se connecte sur un réseau et pas sur un autre, ces notes répondent en une minute au lieu d’une reconstruction.