Apple IncludeAllNetworks : ce qui contourne encore le VPN

Vous ouvrez le profil dans la console MDM, vous voyez IncludeAllNetworks coché et vous supposez que chaque paquet de cet appareil entre désormais dans le tunnel. Le schéma d’Apple lui-même ne le promet pas. Le réglage achemine le trafic dans le VPN avec des exclusions : certaines sont des commutateurs facultatifs, d’autres sont nécessaires pour que le système continue de fonctionner. Le parcours ci-dessous suit ce document depuis le profil vers l’extérieur, de sorte que la première chose que vous lisez est le réglage lui-même, et non une capture provenant d’un appareil que personne n’a encore identifié.

Deux de ces exclusions expliquent l’essentiel de la confusion, et toutes deux concernent le service cellulaire.

Partez du profil géré, pas d’une capture

Ouvrez le schéma du profil VPN géré et lisez la description de la propriété avant de lire le moindre journal de paquets. Notez que la description porte sur le routage avec exclusions, non sur une garantie de tunnel complet. Cette seule phrase décide de la manière dont vous interpréterez tout ce que vous verrez ensuite.

Notez trois choses pendant que vous êtes dans la console : l’identifiant de charge utile qui porte le réglage, la version gérée du système d’exploitation sur l’appareil et l’implémentation VPN réellement installée. Qu’une clé soit décrite dans la documentation ne dit rien sur la question de savoir si un client tiers l’expose dans sa propre interface de configuration.

Lisez l’exclusion cellulaire comme deux cas distincts

Dans les configurations prises en charge, ExcludeCellularServices exclut le trafic des services cellulaires routables par internet, mais uniquement lorsqu’il est activé aux côtés de IncludeAllNetworks. Le schéma cite Wi-Fi Calling, IMS et les services liés à la messagerie comme exemples de cette catégorie. Ces flux peuvent quitter le tunnel par conception, et aucune revue du profil ne les fera passer par celui-ci tant que l’exclusion est active.

Le second cas est distinct et ne dépend d’aucun commutateur. Certains opérateurs fournissent les services cellulaires directement sur leur propre réseau plutôt que par internet, et Apple documente cette catégorie comme toujours exclue du tunnel. Ce n’est pas le cas conditionnel routable par internet ci-dessus, donc un profil qui vide toutes les cases d’exclusion ne le capturera pas davantage. Traiter les deux comme une seule fonctionnalité est le point de départ de la plupart des débats sur une fuite.

Si votre exigence est littéralement qu’aucun paquet ne quitte jamais le tunnel, ce second cas rend déjà cette exigence impossible sur un appareil cellulaire. Vous devez le savoir avant la revue de conception, pas après.

Vérifiez les clés que votre plateforme expose réellement

Le schéma décrit aussi le trafic nécessaire de connexion réseau et de réseaux captive, ainsi que des contrôles distincts pour d’autres catégories comme les réseaux locaux et la communication entre appareils. Ce sont des relations de configuration documentées, pas des observations de votre appareil. Confirmez chacune contre la version du système d’exploitation que vous gérez, car la disponibilité change d’une version à l’autre et une clé de profil silencieusement ignorée ressemble exactement à une clé qui fait son travail.

Une charge utile minimale pour cette décision ressemble généralement à ceci, avec l’indicateur cellulaire explicite plutôt qu’hérité d’un modèle :

<key>IncludeAllNetworks</key><true/>
<key>ExcludeCellularServices</key><true/>
<key>ExcludeLocalNetworks</key><true/>

Si une clé manque dans le profil livré, l’appareil revient à la valeur par défaut de cette clé, qui n’est pas forcément la valeur que l’auteur du modèle avait en tête. Comparez la charge utile livrée au modèle plutôt que de lire le modèle seul.

Déterminez ce qu’est un nom d’hôte inconnu

Quand un nom suspect apparaît, établissez ce que l’observation représente réellement : un nom demandé par le système, le résolveur qui a répondu, une destination de connexion ou une étiquette imprimée par un outil. Un nom lié à un opérateur n’identifie à lui seul ni le processus d’origine ni l’exception appliquée. Le poursuivre comme preuve d’un contournement, c’est ainsi qu’un fil de support passe une semaine sur la mauvaise couche.

Utilisez des diagnostics pris en charge et parlez à l’administrateur qui possède le profil, puis comparez le flux à la politique prévue. C’est cette comparaison, et non le nom d’hôte, qui vous dit si le trafic était attendu.

Résolvez l’exigence au lieu d’affaiblir le système

N’installez pas un certificat racine inexpliqué et ne désactivez pas des services système juste pour rendre une capture plus silencieuse. Rendre la capture silencieuse supprime la preuve et laisse l’exclusion en place, ce qui est une pire situation que la question d’origine. Si une règle de conformité interdit une catégorie que la plateforme exclut délibérément, portez ce conflit aux responsables de l’appareil et du réseau avec la section du schéma en main.

Clôturez le parcours en notant quelle exception expliquait le trafic, à quelle version du système d’exploitation elle s’applique et quelle valeur de profil l’a produite. Une icône de connexion ne peut pas concilier deux hypothèses incompatibles sur l’étendue de la portée du trafic du système d’exploitation.