Démarrer un second VPN remplace l’état du premier

Deux clients, deux icônes connectées et la conviction que le trafic passe désormais par les deux. Comparez cette conviction à ce que chaque plateforme autorise réellement. Un téléphone dispose généralement d’un seul emplacement pour un service VPN ; un ordinateur peut exécuter plusieurs clients qui se disputent les mêmes routes et le même résolveur. La différence entre ces deux situations explique la plupart des signalements de VPN qui tombe lorsqu’un autre démarre.

Les icônes décrivent des processus, pas une chaîne.

Un emplacement sur téléphone, plusieurs prétendants sur ordinateur

Sur Android, la plateforme propose un modèle de service VPN avec un seul VPN actif par profil utilisateur, donc démarrer le second arrête le premier. C’est le système qui applique sa propre règle, pas un défaut de l’un des clients. Sur un ordinateur, plusieurs clients peuvent rester actifs simultanément, et ils se disputent alors la table de routage, les règles de stratégie, la configuration du résolveur et les interfaces virtuelles. Les deux issues sont la plateforme qui fonctionne comme prévu.

Aucune des deux issues ne produit à elle seule un tunnel imbriqué. Une chaîne exige qu’un tunnel transporte les paquets chiffrés de l’autre, ce qui relève de l’architecture et non d’une coïncidence d’ordre.

Ce que le second client écrase

Le second client installe généralement une route par défaut, ajoute ses propres règles et impose son propre résolveur. Le premier peut survivre comme processus sans trafic, ou conserver une route qui ne gagne plus. Les routes propres à un domaine sont la victime habituelle, ce qui explique que certaines destinations continuent de fonctionner alors que d’autres échouent. Le symptôme visible est une déconnexion, et l’état réel est un remplacement partiel.

Un contrôle de l’IP de sortie ne révélera pas cela. Il signale une adresse pour une destination et ne dit rien sur les routes écrasées ni sur le résolveur qui répond désormais. Pour voir les dégâts, lisez la table de routage et l’état du résolveur.

L’imbrication est une conception, pas un ordre de clics

Si l’imbrication est l’objectif, documentez le chemin extérieur de chaque extrémité, sa politique de défaillance et les conséquences pour le MTU. Décidez de ce qui se passe lorsque le tunnel extérieur tombe alors que l’intérieur croit encore être connecté. Démarrer les clients dans un ordre favorable n’est pas une configuration, car la prochaine mise à jour ou reconnexion les réordonne. Un agencement imbriqué demande le même soin que toute autre topologie.

Lorsqu’une connexion sert au travail et l’autre à un usage personnel, appuyez-vous sur l’isolation ou l’agencement géré que la plateforme prend en charge. Arracher les contrôles de l’entreprise n’est pas une stratégie de séparation.

Vérifiez avec l’application, pas avec l’icône

Exercez les applications qui comptent vraiment, depuis chaque contexte que vous comptez utiliser, et incluez le comportement du résolveur et les reconnexions dans le test. Une adresse de sortie finale ne peut pas identifier chaque route écrasée, et une icône verte ne peut en identifier aucune. Notez qui possède la connexion et quelle combinaison est réellement prise en charge.

Si un produit ne prend pas explicitement en charge la coexistence avec un autre, un changement aléatoire de route ou d’autorisation ne produira pas un déploiement maintenable. Il produira un déploiement qui fonctionne jusqu’à la prochaine mise à jour.

Notez quel client possède la route par défaut, quel résolveur répond et ce qui se passe lorsque chacun s’arrête.