Deux applications VPN à la fois : quel kill switch s’applique vraiment ?
Un second client VPN n’hérite jamais du kill switch du premier. Trois conditions décident quelle politique s’applique, et comment vérifier la vôtre.
Deux clients VPN peuvent tourner côte à côte, mais leurs kill switches ne fusionnent pas en une seule politique. Chaque client installe des règles pour son propre tunnel, et aucun ne sait que l’autre existe. Je l’ai constaté avec un client d’entreprise connecté en premier : la seconde application n’arrivait pas à terminer sa poignée de main, est restée sur « Connecting » pendant dix minutes, et le premier tunnel a tranquillement tout transporté. Savoir si la seconde application est protégée dépend de trois conditions, pas du fait que les deux icônes affichent « Connecté ».
À quoi un kill switch est réellement limité
Rien dans le système d’exploitation ne porte un unique drapeau de kill switch. Un client qui en annonce un installe un jeu de règles : tout supprimer ce qui ne sort pas par mon tunnel, et souvent se fermer en cas de disparition du tunnel. Sous Linux, c’est généralement une chaîne nftables ou iptables, sous Windows un ensemble de filtres Windows Filtering Platform, sous Android et iOS le routage propre du service de tunnel plus le réglage système qui bloque les connexions sans VPN. Le guide VPN d’Android décrit ce modèle de service si vous voulez le point de vue de la plateforme.
La portée est la partie qui compte. Une règle du type « n’autoriser que les paquets sur l’interface de sortie wg0 » ne se soucie pas de l’existence d’un second tunnel. Si un autre client monte wg1, les règles du premier client traitent ces paquets comme du trafic ordinaire : le plus souvent supprimés, parfois autorisés. Dans les deux cas, c’est le premier client qui décide, et il n’a aucune idée qu’une seconde application attend.
Trois conditions qui décident qui est couvert
Vous n’avez pas besoin d’énumérer toutes les combinaisons. Trois questions suffisent en quelques minutes.
- La plateforme autorise-t-elle seulement un second tunnel ? La plupart des téléphones Android et des iPhone n’acceptent qu’un seul service VPN actif par profil utilisateur, donc la seconde application ne détient jamais de tunnel et n’applique jamais rien. Vous obtenez une seule politique, celle de l’application qui a gagné la place.
- Quel processus possède la route par défaut ? Windows, macOS et Linux transportent volontiers deux tunnels. La route par défaut appartient au client qui l’a configurée en dernier ou avec la meilleure métrique, et l’autre client est connecté mais inactif. Sous Linux, le mode route par défaut de wg-quick utilise le routage par politique avec une table privée et une règle fwmark, si bien qu’un second tunnel wg-quick ajoute une règle concurrente au lieu de remplacer la première.
- Le second client peut-il joindre son propre serveur ? Si le premier kill switch est en refus par défaut, le point de sortie de la seconde application n’est qu’une destination supprimée de plus. Elle réessaie en silence et ne signale jamais d’erreur.
La version courte, pour les fils de support :
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Deux de ces lignes sont identiques vues de l’icône de la zone de notification, et c’est pourquoi cette icône est la pire preuve disponible ici.
Ce qui échoue en premier, et à quoi cela ressemble
Un client bloqué sur « Connecting » alors que l’autre est sain, c’est presque toujours la famine du point de sortie : le kill switch actif supprime la poignée de main du second client vers son propre serveur. Confirmez-le à moindres frais en suspendant les règles de blocage du premier client le temps d’une tentative. Si le second se connecte aussitôt, la question est réglée.
Le DNS est la deuxième défaillance. Les clients configurent le résolveur pour leur propre interface, et certains écrasent purement et simplement la liste globale. Avec les deux tunnels actifs, les requêtes peuvent sortir d’un côté alors que le résolveur appartient à l’autre. Déconnectez l’une des applications et la survivante garde un serveur de noms injoignable : les pages calent une minute puis se résolvent de nouveau, tandis que le VPN affiche toujours connecté.
La troisième est le battement de routes. Les reconnexions réordonnent la route par défaut, et un kill switch lié à une interface ne la suit pas. Le trafic qui était dans le tunnel un instant plus tôt correspond maintenant à une règle de rejet, ce qui se lit côté utilisateur comme un VPN qui cesse de fonctionner au hasard.
Vérifier quelle politique est réellement en vigueur
Faites-le avec du trafic anodin, pas avec quelque chose qui vous manquerait.
Sous Linux, demandez au noyau qui gagne et à quoi le pare-feu se lie. ip -4 route show default nomme le tunnel qui possède la sortie. ip rule show indique si le routage par politique est en jeu. sudo nft list ruleset | grep -n oifname indique si les rejets sont liés à un nom d’interface, à une marque ou à toute la chaîne de sortie.
Sous Windows, la même histoire se lit dans la métrique de route et la liste de filtres : Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric et Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". Sous macOS, netstat -rn -f inet | head -5 et scutil --dns | head -20.
Faites ensuite l’étape que les gens sautent : arrêtez le tunnel exprès et confirmez que le trafic censé échouer échoue vraiment. Une icône connectée est un état d’interface, pas une application de la règle.
Quand deux clients est la mauvaise conception
Si la seule exigence derrière la seconde application est plus de protection, supprimez-la. Deux politiques de blocage qui interagissent sont moins prévisibles qu’une seule, et chaque reconnexion est une chance d’atterrir dans un état qu’aucun éditeur ne teste.
Si vous avez vraiment besoin d’un chaînage, par exemple une passerelle d’entreprise atteinte via un saut commercial, choisissez une conception à point d’application unique. Cela signifie normalement un routeur ou un seul client qui prend en charge la chaîne, pas deux applications de bureau qui se disputent la même route par défaut. Sur un appareil géré, gardez le client autorisé et considérez tout le reste comme hors périmètre, quel que soit ce qu’il affiche dans sa zone de notification.
Liste de contrôle avant de garder les deux
Parcourez cette liste dans l’ordre ; le premier point qui échoue est celui à corriger.
- Confirmez qu’un seul client possède la route par défaut et le résolveur.
- Si vous voulez le second client actif, autorisez explicitement son point de sortie serveur et revérifiez après chaque mise à jour du client.
- Notez le résultat attendu quand l’un ou l’autre tunnel tombe, puis testez ce cas précis.
- Vérifiez le chemin de défaillance après un redémarrage, quand l’ordre de démarrage diffère.
- Sur un profil géré, arrêtez-vous et demandez au propriétaire avant d’ajouter quoi que ce soit.
Si la troisième étape échoue, la réponse honnête est qu’un seul client vous donne une politique. Décidez auquel vous faites confiance et laissez l’autre partir.