VPN par application sur les apps iPhone gérées : ce qui est routé et ce qui ne l'est pas

Le VPN par application sur iPhone n'est pas un interrupteur pour tout le téléphone. C'est une association entre une app gérée et un profil VPN, créée lors du déploiement de l'app, et le trafic de tout le reste conserve la route qu'il avait avant. C'est pourquoi le même téléphone se comporte de façon incohérente: l'app de travail ouvre une page privée alors que Safari n'atteint pas le même hôte, ou le tunnel ne monte jamais et l'app signale un délai d'attente qui ressemble à de mauvais identifiants. Les vérifications vont de la cause la plus large vers le bas, alors arrêtez-vous à la première qui échoue.

Vérifiez d'abord le profil et l'enregistrement de l'app

L'association vit dans deux objets, pas un. Le profil VPN définit le tunnel : type, serveur, authentification, DNS et l'identifiant de paquet du fournisseur lorsqu'un client personnalisé est utilisé. L'enregistrement de l'app pointe vers ce profil, et la plupart des consoles de gestion l'exposent comme option par application dans la configuration de l'app, sous un nom proche de Per-App VPN. Un profil vers lequel aucune app ne pointe ne route rien par application ; il se comporte comme un tunnel ordinaire que quelqu'un doit démarrer à la main.

Lisez les deux objets avant de toucher au téléphone. Confirmez que la configuration de l'app référence le profil que vous testez et non une copie plus ancienne, car les profils dupliqués aux noms presque identiques sont courants après une migration et l'app pointera volontiers vers celui qui est retiré. Confirmez ensuite que la configuration a atteint l'appareil : Réglages, Général, VPN et gestion de l'appareil doivent l'afficher comme profil installé. La liste VPN à cet endroit n'est pas le test. Un service par application n'a généralement pas d'interrupteur manuel, donc une configuration correctement déployée peut ne jamais apparaître parmi les VPN démarrables. L'absence se voit dans l'enregistrement de l'app et dans le fait que le tunnel monte ou non à la première requête de l'app.

Une condition explique beaucoup de tickets : ce modèle exige que l'app arrive via la gestion. Une copie installée à côté ou achetée à titre personnel n'obtient pas l'association, même quand son identifiant de paquet correspond. Le guide de déploiement VPN d'Apple décrit le modèle de profil derrière cela (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).

Confirmez que l'app installée est la copie gérée

L'association suit l'app installée et gérée. Si quelqu'un l'a réinstallée depuis l'App Store avec un Apple ID personnel, l'a remplacée par une build d'entreprise re-signée, ou si l'appareil a été réinscrit et que l'app est revenue par un autre canal, le tunnel peut rester en bas alors que l'app elle-même semble parfaitement normale.

Testez par comparaison, pas par une seule observation. Dans l'inventaire de gestion, l'app doit apparaître comme gérée pour cet appareil avec le mappage VPN dans son enregistrement. Sur le téléphone, le tunnel doit monter au lancement de l'app et à la sortie de sa première requête, pas seulement quand quelqu'un démarre une configuration manuelle séparée dans Réglages. Si lancer l'app ne change rien et que cette configuration manuelle change quelque chose, l'app n'est pas liée du tout à un tunnel par application.

Les mises à jour comptent : celle poussée via la gestion conserve le mappage, tandis qu'une réinstallation lancée par l'utilisateur peut le perdre. Quand la plainte date d'une mise à jour, vérifiez l'enregistrement de l'app avant le réseau.

Vérifiez ce que le tunnel est autorisé à prendre

Un tunnel par application est sélectionné par l'app source, donc la route par défaut du téléphone appartient toujours au Wi-Fi ou au cellulaire. OverridePrimary est la clé qui change cela. Quand un profil la définit, le tunnel se comporte comme un tunnel complet et chaque app en hérite, si bien que tout ce qui passe par le VPN devient une question de profil plutôt qu'une panne d'app.

Les règles à la demande décident de la persistance. OnDemandEnabled et son jeu de règles font revenir le tunnel quand l'app envoie du trafic, survivre à un passage du Wi-Fi au cellulaire ou tomber dès que l'app passe en arrière-plan. Un déploiement qui se connecte puis meurt silencieusement a généralement une règle qui ne correspond qu'à une sonde qui ne se déclenche jamais tant que l'app est inactive.

Lisez ensuite le côté routes honnêtement. Si un profil de fournisseur ou de vendeur fournit une liste d'inclusion, un tunnel ne portant que 10.20.0.0/16 ne portera pas un service en 10.30.0.0/16 ; c'est la liste qui fait son travail, pas une panne par application. Le profil iOS intégré n'a pas de liste d'inclusion. Sans elle, la division suit les valeurs par défaut du fournisseur et IncludeAllNetworks, pas une liste cachée.

Testez l'app, puis ce qui en sort

Testez avec un nom, pas seulement une adresse. Résoudre un hôte interne dans l'app gérée prouve que le DNS a aussi traversé le tunnel, car le profil décide quel résolveur répond et quels domaines de recherche s'appliquent. Le routage peut être parfait alors que la résolution de nom échoue, et les deux symptômes pointent vers des réglages différents.

Testez ensuite la frontière des deux côtés. Une app personnelle ou Safari doit atteindre une page publique ordinaire et rapporter l'adresse de l'opérateur ou du domicile, tandis que l'app gérée atteint le service privé. Si les deux rapportent la même adresse publique, le tunnel n'est plus par application, quoi qu'affirme l'enregistrement de l'app.

Les flux qui quittent l'app produisent les tickets confus. Un lien qui s'ouvre dans Safari, un document transmis via la feuille de partage ou une connexion SSO qui bascule vers un navigateur quittent le processus de l'app et le tunnel avec lui. Une connexion affichée dans l'app est généralement attribuée à l'app, donc une connexion intégrée peut réussir là où la même URL échoue dans Safari ; vérifiez-le plutôt que de le supposer. Quand le fournisseur d'identité n'est joignable que par le tunnel, gardez la connexion dans l'app ou ajoutez le domaine du fournisseur aux domaines Safari du profil pour que le trafic Safari correspondant soit capturé.

Associez le symptôme à la couche

La forme de la panne indique quelle vérification répéter.

Deux détails se cachent derrière les lignes du milieu : un tunnel par application peut être sain et manquer un sous-réseau qu'aucune liste de fournisseur n'inclut, et un téléphone géré peut contenir plus d'une configuration VPN, donc confirmez à laquelle l'app est liée au lieu de supposer que c'est celle que vous lisez.

Corrigez dans cet ordre : corrigez l'enregistrement de l'app pour qu'il référence le profil actif, réinstallez l'app via la gestion, confirmez que le tunnel monte à la première requête de l'app, puis répétez les tests de nom et de frontière. Si la première requête ne peut pas du tout démarrer un tunnel, arrêtez-vous et vérifiez le côté fournisseur, car un client personnalisé a besoin de son Network Extension présent et de son identifiant correspondant à l'app installée.

Rendez trois faits plutôt qu'une capture d'écran : quel profil l'enregistrement de l'app référence, si Réglages l'affiche comme profil installé et quelle était la requête en échec, un nom, une adresse ou un passage au navigateur. Ces trois réponses séparent une erreur de déploiement d'une erreur de routage, et la personne suivante peut agir sans répéter le diagnostic.