Le verrouillage VPN de votre iPhone est une politique, pas le protocole

L’icône VPN affiche connecté, le tunnel tombe un instant lors d’un changement de réseau, et le trafic qui aurait dû être bloqué sort par le réseau cellulaire. Rien dans l’interface n’a annoncé de trou. La fonction sur laquelle vous comptiez est une politique du client et de la plateforme, et un nom de protocole dans les réglages ne décrit pas ce qui se passe pendant cette seconde.

Décrivez le verrouillage comme un contrat sur des états, non comme une propriété d’IKEv2 ou d’On Demand.

Le symptôme : l’icône dit connecté

Une icône reflète la vision que le client a de son propre état, et cette vision peut accuser un retard sur la réalité de la durée d’une reconnexion. Une page en cache, une reconnexion rapide ou un rafraîchissement d’état masquent tous l’intervalle. La question qui vaut la peine n’est pas de savoir si l’icône était verte, mais ce que l’appareil a autorisé pendant l’absence du tunnel. Le même retard explique pourquoi une capture d’écran de l’application est une preuve si faible : elle enregistre un état, pas une transition.

Cette question n’a de réponse que si la politique la définit.

Ce que le protocole maintient réellement

IKEv2 maintient et renouvelle une relation IPsec authentifiée, et les fonctions de mobilité aident à la rétablir après un changement d’adresse. C’est une affirmation sur le cycle de vie du tunnel. Elle ne dit rien de l’autorisation de l’iPhone d’envoyer d’autre trafic dans le trou, car cette autorisation appartient à la plateforme et au client, pas à l’échange de clés. Un appareil qui se reconnecte en moins d’une seconde avait quand même une fenêtre, et c’est dans cette fenêtre que vit le comportement intéressant.

On Demand est de même une description du comportement d’activation, pas une garantie de blocage universelle.

Ce que la plateforme offre à un développeur

Network Extension d’Apple expose des contrôles de portée du trafic, et son guide de routage distingue le comportement d’inclusion de tous les réseaux des routes incluses ordinaires et énumère les exceptions du système. Il existe aussi un modèle de déploiement Always On supervisé, distinct du réglage de connexion automatique d’une application personnelle. Qu’une application donnée utilise l’une de ces briques est une propriété de l’application, pas du protocole qu’elle parle.

Le nom d’un interrupteur ne prouve pas quelle API l’application appelle.

Lisez la fonction comme un contrat

Demandez au fournisseur de préciser cinq états : activation initiale, perte inattendue du tunnel, déconnexion volontaire, sortie de l’application et redémarrage de l’appareil. Placez les exceptions du système et tout accès intentionnel au LAN à côté de cette liste. Demandez ensuite si la fonction est facultative, imposée par la gestion ou conditionnée à un mode client, car une pause choisie par l’utilisateur et un verrouillage imposé par une organisation sont deux produits différents. Inscrivez ces cinq réponses dans le dossier de déploiement, car le prochain relecteur posera exactement ces questions.

Une fonction qui bloque lors d’une perte inattendue mais pas lors d’une déconnexion volontaire est une conception cohérente. Ce n’est simplement pas celle que décrivait la page marketing.

Comment tester les trous

Testez une transition à la fois avec un trafic inoffensif, dans l’application et la famille d’adresses qui vous intéressent. Confirmez ce qui a été autorisé pendant le trou, pas ce que l’icône a montré ensuite. Notez la version du client et la politique à côté du résultat, car les deux changent et ni l’une ni l’autre n’est visible depuis l’écran de réglages du téléphone. C’est le seul moyen de distinguer un vrai trou d’une icône lente.

Si la réponse compte pour la conformité, demandez-la par écrit plutôt que de la déduire d’un nom de produit.