Le VPN de l’iPhone se reconnecte après désactivation : qui le relance ?

Touchez déconnecter sur le VPN de l’iPhone, ouvrez un navigateur, et le tunnel est de nouveau actif avant même que la page se charge, ce qui donne l’impression que l’interrupteur est cassé. En général, tout fonctionne comme prévu, mais pas comme l’utilisateur l’entendait. Une déconnexion termine une session ; autre chose détient encore l’autorisation d’en démarrer une nouvelle. Trois responsables différents peuvent le faire sur iOS, et chacun laisse une empreinte différente dans le moment où la reconnexion se produit.

Déconnecter n’est pas désactiver

Une déconnexion manuelle dit au tunnel de s’arrêter. Elle ne dit pas forcément au système de cesser de le demander. Les règles de connexion à la demande, la politique de connexion automatique propre à l’app d’un fournisseur et une configuration gérée Always On survivent toutes à une déconnexion, et chacune peut relancer la connexion sans que l’utilisateur touche à quoi que ce soit.

La distinction compte parce que la correction se trouve chez le responsable. Actionner l’interrupteur plus fort n’aide jamais, et supprimer le profil est une action bien plus lourde que ne l’exige le problème. Trouvez d’abord le déclencheur, puis décidez si c’est à vous de le changer. Cet ordre vous évite aussi de retirer une configuration qui fonctionne en courant après une règle qui vit ailleurs.

Comparez les trois responsables selon leur déclencheur

La connexion à la demande réagit à des conditions qu’évalue le système d’exploitation : rejoindre un réseau, ou une requête impliquant un domaine que la règle vise. L’app d’un fournisseur peut établir une connexion au démarrage ou lorsque sa propre politique d’arrière-plan le décide. Un déploiement géré Always On est une exigence au niveau de l’appareil que l’utilisateur n’est pas censé contourner du tout.

Observez quel événement précède la reconnexion et le responsable devient assez évident. C’est la différence entre une règle que vous pouvez modifier et une politique sur laquelle vous ne pouvez que vous renseigner.

Ce que font réellement les règles à la demande

Le comportement à la demande est une liste ordonnée. Chaque entrée correspond à une condition et produit une action : connecter, déconnecter, évaluer une tentative de connexion ou ignorer. Une règle de connexion placée avant une règle de déconnexion l’emporte dès que les deux correspondent, et c’est pourquoi un appareil peut se reconnecter immédiatement après une déconnexion manuelle.

Les règles peuvent aussi être pilotées par le domaine, en correspondant à un nom d’hôte dans une requête plutôt qu’à un changement d’interface. C’est le schéma derrière « le VPN revient quand j’ouvre le site de l’intranet », et il désigne le fournisseur ou le profil qui a installé la règle, pas iOS lui-même.

Le Always On géré n’est pas une option personnelle

Sur un appareil supervisé et géré, l’organisation peut exiger qu’un VPN reste actif et retirer à l’utilisateur la possibilité de le désactiver. Aucun nombre de manipulations dans Réglages n’y changera rien, et la réponse honnête est que le comportement appartient à la politique de l’administrateur.

Demandez quelle politique s’applique et quel processus d’exception existe, s’il y en a un. Supprimer le profil de gestion installé n’est pas une solution prise en charge ; cela peut retirer d’autres configurations dont l’appareil dépend et casser la remontée de conformité.

Testez en retirant le déclencheur, pas le profil

Laissez le profil installé, déconnectez, puis répétez l’événement qui relançait auparavant le tunnel : rejoignez le même Wi-Fi, ouvrez la même app, demandez le même nom interne. Si le tunnel revient à ce moment-là, vous avez identifié le déclencheur et pouvez chercher le réglage qui le possède.

Changez un réglage chez le responsable, puis répétez le même test. Si la reconnexion s’arrête, vous avez la réponse ; si elle persiste, le déclencheur est ailleurs et le profil n’a jamais été le problème. Un fichier de réglages téléchargé qui traîne encore dans Fichiers n’est pas non plus une configuration installée, donc supprimer le fichier ne prouve rien.

Le résultat utile est une phrase que vous pouvez noter : cette connexion est lancée par cette règle ou politique, et elle appartient à cette partie. Une fois cela vrai, l’interrupteur cesse de paraître imprévisible, et la prochaine personne qui le signale obtient une réponse directe au lieu d’une nouvelle réinstallation.