Le VPN à la demande de l’iPhone se connecte au Wi-Fi du bureau, pas au réseau mobile

À neuf heures, le téléphone rejoint le réseau sans fil du bureau, et le tunnel monte tout seul et y reste toute la journée. Le réseau mobile se comporte ensuite exactement comme tout le monde l’avait prévu. Quelqu’un a ajouté une exclusion pour le réseau d’entreprise il y a des semaines, donc le profil se relit proprement, et chaque matin produit toujours le même résultat. L’appareil suit la liste qu’on lui a donnée, et la liste dit autre chose que ce que son auteur croyait.

La liste se lit du haut, et la première correspondance gagne

Les entrées sont évaluées dans l’ordre. La première dont les conditions tiennent décide du résultat pour cet instant, et tout ce qui est en dessous n’est jamais regardé. L’ordre porte donc autant de sens que n’importe quelle condition écrite dans une règle. Lire le tableau depuis le haut explique un profil qui semble ignorer une exclusion qu’il contient manifestement.

Une entrée générale de connexion sans fil placée au-dessus de l’exclusion du bureau garantit un tunnel sur place. Rien d’autre dans la charge n’a besoin de bouger pour que le comportement bascule.

Une entrée de déconnexion fait deux choses

Quand l’action est Déconnecter, l’entrée ferme une session déjà en cours et bloque une nouvelle tant que ses conditions restent vraies. Les deux moitiés comptent pour une exclusion, et la seconde est souvent oubliée. La même entrée dans un second profil explique un étage où le VPN refuse de démarrer alors que le reste du bâtiment fonctionne. Personne n’a touché au tunnel ; c’est la liste qui l’a fait.

Le tableau montre la forme, l’exclusion d’abord, avec des noms qui doivent venir de votre propre déploiement. Deux entrées suffisent généralement, et une troisième pour le réseau mobile rend le reste prévisible.

Gardez les deux conditions sur l’exclusion

Associez le nom du réseau au type d’interface. Un nom seul peut se déclencher sur une liaison partagée portant la même étiquette, tandis qu’un type d’interface seul exclut tous les réseaux sans fil que l’utilisateur visite ce jour-là. Les deux moitiés appartiennent à une entrée, pas à deux règles qui se trouvent être côte à côte.

La comparaison du nom est exacte et sensible à la casse. Cela convient à un réseau connu et crispe partout ailleurs, parce que les réseaux invités réutilisent des étiquettes familières, les sites sont renommés après une fusion, et un poste filaire ne porte aucun nom. Demandez l’étiquette exacte à l’équipe réseau plutôt que de la lire sur un panneau mural.

Quand une sonde bat un nom

Une entrée de sonde demande une URL et lit une réponse réussie comme une condition vraie. Choisissez un hôte qui ne répond que de l’intérieur, comme un service intranet qui ne peut pas se résoudre publiquement, et la règle cesse de se soucier du nom que le réseau se donne. Une sonde qui répond de partout teste internet, pas le bâtiment. La propriété qui décide si cela fonctionne est que la réponse arrive sans redirection ; un portail invité qui renvoie chaque requête transforme la sonde en bruit.

Les règles basées sur le domaine sont une forme à part : NEEvaluateConnectionRule fait correspondre les domaines demandés et peut se connecter quand un nom est résolu. Son joker n’est accepté que comme étiquette la plus à gauche, donc *.example.com est valide tandis que example.*.com ne l’est pas. Si un profil n’utilise ni conditions d’interface ni sondes d’accessibilité, vérifiez s’il utilise plutôt ce type de règle.

Ce que les règles à la demande ne contrôlent pas

Les règles choisissent si un tunnel démarre et n’ont pas leur mot à dire sur son maintien en marche. Une session qui apparaît puis disparaît quelques minutes plus tard pointe vers des minuteries d’inactivité, des limites de session de la passerelle ou la taille du chemin. Chacun laisse une trace différente, et c’est pourquoi il faut écarter la liste de règles avant de changer l’un d’eux. Les réglages de keep-alive n’expliquent pas ce schéma, et les modifier déplace le travail sans toucher à la cause.

Les utilisateurs peuvent désactiver l’accès à la demande dans Réglages, et une affectation gérée peut le rétablir au prochain pointage. Quand l’interrupteur continue de revenir à sa position précédente, l’affectation est la partie active. La distinction compte, parce que l’application forcée revient d’elle-même tandis qu’une offre reste désactivée.

Confirmez quel groupe de profils possède l’appareil et si l’intention est d’imposer le tunnel ou simplement de le proposer. Cette réponse décide si la préférence de l’utilisateur compte comme un défaut ou comme une fonctionnalité.