Deux VPN iPhone à la fois : lequel transporte votre trafic ?

Deux applications VPN affichent toutes deux Connecté, et l’on suppose que le trafic passe désormais par les deux, l’une dans l’autre. En général, ce n’est pas le cas. iOS a un modèle de coexistence précis, et ce n’est pas une chaîne. Une classe de configuration est limitée à une seule instance activée, l’autre peut fonctionner à côté, et la priorité des routes tranche les conflits. Deux interrupteurs allumés ne font pas deux sauts. Le modèle est documenté, ce qui signifie que le chemin peut être prédit au lieu d’être deviné d’après les icônes.

Mythe : deux VPN connectés forment une chaîne

Une chaîne à deux sauts exige un transport extérieur défini, un tunnel intérieur défini, un routage de points de terminaison compatible et un plan pour ce qui se passe quand l’un des deux échoue. Deux configurations indépendantes ne créent pas cela simplement en coexistant. La priorité de route n’est pas la même chose que l’encapsulation, et le fait qu’une configuration gagne une recherche de route ne dit rien sur le fait que l’autre transporte les paquets résultants.

Si vous avez besoin d’imbrication, concevez-la comme une imbrication. Ne la déduisez pas de deux indicateurs de connexion. Cette distinction épargne beaucoup de débogage.

Le modèle documenté derrière ce mythe

NETunnelProviderManager d’Apple décrit les configurations VPN d’entreprise ordinaires et indique qu’une seule de ce type peut être activée à la fois. La même référence autorise un Personal VPN à rester activé et connecté à côté, et donne la priorité aux routes d’entreprise là où les deux se chevauchent.

Personal VPN est ici le terme d’API désignant l’implémentation IPsec ou IKEv2 intégrée, gérée via NEVPNManager. NETunnelProviderManager est le modèle de fournisseur de tunnel. Une application grand public peut utiliser le modèle de fournisseur, donc un nom de produit contenant personal ne le classe pas.

Apple documente une seule combinaison autorisée, et l’autorisation ne vous dit pas que les profils de deux fournisseurs sont compatibles, alors demandez à chaque fournisseur quelle paire est prise en charge. Leurs types de configuration, routes et stratégies décident toujours du résultat.

Mythe : le VPN personnel reçoit le trafic de navigation

Un profil professionnel qui revendique toutes les destinations gagnera aussi la recherche de route pour la navigation publique, donc la sortie personnelle n’en transporte rien. Selon la priorité documentée, les routes d’entreprise l’emportent là où elles entrent en conflit, donc la navigation publique ne prend pas automatiquement la sortie personnelle simplement parce que cette application signale aussi une connexion. Une configuration professionnelle plus étroite peut changer le tableau du routage, mais le client de l’organisation peut encore imposer des exigences DNS, de blocage ou d’appareil. Obtenez l’arrangement pris en charge auprès de son propriétaire au lieu de modifier ces exigences localement.

Les configurations gérées par application ont leur propre portée. N’extrapolez pas une règle au niveau de l’appareil à chaque déploiement géré.

Notez les deux flux avant de tester : le nom et la plage privés du service professionnel, et une nouvelle requête de navigation publique. Les deux sont légitimes, et ils demandent des vérifications différentes.

Priorité des routes avec un profil professionnel à tunnel divisé

Un profil professionnel à tunnel divisé revendique les préfixes privés et le suffixe DNS interne qu’il liste, et ces routes gagnent toute recherche qui y correspond. Les destinations publiques qui ne correspondent à aucune route d’entreprise retombent sur le lien physique, sauf si le VPN personnel les revendique d’abord. La règle de priorité ne tranche que les correspondances qui se chevauchent, c’est pourquoi les deux profils doivent être lus comme des tables de routage et non comme des icônes.

Écrivez la paire en deux lignes et nommez le gagnant attendu pour chacune : un nom d’hôte professionnel qui se résout en 10.x ou 172.16.x devrait sortir par le tunnel d’entreprise, et une adresse publique sans préfixe correspondant devrait prendre la route par défaut restante. Si les deux lignes nomment la même sortie, la division ne fait pas ce que décrit la documentation.

Notez deux flux et testez chacun

Pour chaque flux, notez quelle configuration approuvée devrait le transporter et quel résolveur devrait recevoir chaque type de nom. Vérifiez ensuite avec des requêtes fraîches, pas avec une page professionnelle en cache ni un ancien résultat IP.

Arrêtez une configuration et répétez les deux flux. Le comportement en cas d’échec fait partie de la conception, et c’est la partie que les utilisateurs remarquent. Quand les deux fournisseurs ne peuvent pas prendre en charge la combinaison, retenez une configuration approuvée et documentez quel flux elle transporte, ou passez à une conception gérée à tunnel unique. La documentation de NETunnelProviderManager est la source de la règle de coexistence.