Un kill switch n'a de sens que parce que les tunnels VPN se rompent, en pratique, plus souvent qu'on ne le pense. La page consacrée au principe général du kill switch VPN introduit brièvement plusieurs de ces causes. Cette page les détaille une à une, avec ce que chacune implique concrètement pour la durée d'exposition et pour la probabilité qu'elle se reproduise.
C'est la cause la plus fréquente et la plus banale. Un tunnel VPN, quel que soit le protocole utilisé, dépend d'un flux de paquets suffisamment régulier avec le serveur distant. Sur une connexion Wi-Fi publique de mauvaise qualité, sur une ligne mobile en zone de faible couverture, ou sur une connexion domestique saturée par d'autres usages, les micro-coupures et pertes de paquets peuvent atteindre un seuil qui force le client VPN à considérer le tunnel comme rompu, même si la coupure réelle ne dure qu'une fraction de seconde. Ce type de cause a la particularité de se répéter fréquemment dans certains environnements, ce qui multiplie mécaniquement le nombre d'occasions où le kill switch doit intervenir.
De nombreux clients VPN modernes proposent une fonction de sélection automatique du meilleur serveur, ou permettent une bascule manuelle vers un autre point de sortie. Ce changement implique nécessairement une fermeture du tunnel existant et l'établissement d'un nouveau tunnel vers un serveur différent. Contrairement à une coupure accidentelle, cette rupture est volontaire et prévisible du point de vue du logiciel, ce qui devrait en théorie permettre une transition sans aucune fenêtre d'exposition. En pratique, la qualité de cette transition dépend entièrement de la manière dont le client a été programmé pour l'orchestrer.
Après un redémarrage — qu'il soit volontaire, provoqué par une mise à jour automatique, ou consécutif à une erreur système — la connexion VPN n'est plus active tant que l'application n'a pas été relancée et n'a pas rétabli le tunnel. Si l'appareil se reconnecte au réseau avant que l'application VPN ne soit relancée, un intervalle existe pendant lequel toute application configurée pour démarrer automatiquement peut émettre du trafic non protégé. Un kill switch correctement implémenté au niveau système doit couvrir cette phase précise, ce qui suppose qu'il soit lui-même actif dès le démarrage du système, indépendamment du lancement de l'application VPN.
Les abonnements VPN limitent généralement le nombre d'appareils pouvant être connectés simultanément avec un même compte. Lorsqu'un nouvel appareil tente de se connecter alors que cette limite est déjà atteinte, certains fournisseurs déconnectent automatiquement la session la plus ancienne pour libérer un emplacement. Du point de vue de l'appareil ainsi déconnecté, il s'agit d'une coupure de tunnel identique à n'importe quelle autre, avec les mêmes implications pour le kill switch, alors que la cause n'a rien de technique ou d'accidentel : elle résulte simplement d'une politique commerciale de gestion des connexions.
Dans certains contextes réseau, en particulier dans les pays qui restreignent ou surveillent étroitement l'usage des VPN, les fournisseurs d'accès peuvent employer des techniques d'inspection approfondie des paquets pour identifier des signatures caractéristiques de certains protocoles VPN et interrompre activement ce trafic. Cette cause est particulièrement importante à comprendre pour les utilisateurs situés dans ce type de contexte, car elle implique un risque de déconnexions répétées et potentiellement délibérées, avec une probabilité de récidive nettement plus élevée que pour une simple instabilité réseau domestique.
Un serveur VPN qui approche ou dépasse sa capacité peut fermer des connexions existantes pour préserver sa stabilité globale, ou simplement dégrader la qualité de la connexion jusqu'au point où le client la considère comme rompue. Cette cause a une conséquence pratique directe sur le choix d'un fournisseur : un réseau de serveurs plus étendu et mieux réparti géographiquement réduit statistiquement la probabilité de tomber sur un serveur saturé, et donc la fréquence des déclenchements du kill switch liés à cette cause précise.
Certaines configurations de sécurité locale, en particulier des pare-feux ou antivirus tiers configurés de manière stricte, peuvent bloquer des ports spécifiques utilisés par un protocole VPN, interpréter des connexions répétées vers la même adresse IP comme un comportement suspect, ou interférer avec les protocoles de tunnellisation comme OpenVPN ou IPsec. Cette cause est particulière parce qu'elle provient de l'appareil de l'utilisateur lui-même plutôt que du réseau ou du fournisseur VPN, ce qui signifie qu'elle peut souvent être corrigée en ajoutant des règles d'exception explicites pour le logiciel VPN utilisé, une fois identifiée.
Sur smartphone et sur certains ordinateurs portables équipés d'une connexion cellulaire, le système d'exploitation peut basculer automatiquement d'un réseau Wi-Fi vers les données mobiles, ou inversement, en fonction de la qualité du signal disponible à un instant donné. Ce changement d'interface réseau modifie l'adresse IP locale de l'appareil et force, dans la plupart des implémentations, une reconstruction complète du tunnel VPN plutôt qu'une simple reprise de la session existante. Cette cause est particulièrement fréquente chez les utilisateurs mobiles qui se déplacent entre des zones de couverture Wi-Fi et des zones sans Wi-Fi, et elle explique pourquoi le comportement d'un kill switch peut sembler nettement moins fiable sur téléphone que sur un ordinateur resté connecté au même réseau pendant toute une session.
Les protocoles VPN modernes comme WireGuard ou OpenVPN reposent sur des mécanismes de renégociation périodique des clés de chiffrement pendant la durée d'une session, une pratique de sécurité qui limite la fenêtre d'exploitation d'une éventuelle compromission de clé. Dans de rares cas, cette renégociation peut échouer, notamment sur des réseaux qui appliquent une inspection ou une limitation stricte de certains types de paquets. Un échec de renégociation entraîne alors une coupure du tunnel qui n'a ni cause réseau évidente ni origine dans une action de l'utilisateur, ce qui la rend plus difficile à anticiper que les causes précédentes, mais pas moins réelle pour autant en termes d'exposition potentielle du trafic.
Deux enseignements se dégagent de ce panorama. D'abord, la plupart de ces causes ne relèvent pas d'un défaut du VPN lui-même : elles sont la conséquence normale du fonctionnement d'un réseau, d'un système d'exploitation ou d'une politique commerciale. Un kill switch n'existe pas pour compenser un mauvais VPN, mais pour absorber la variabilité inhérente à toute connexion réseau. Ensuite, la fréquence et la prévisibilité de ces causes varient fortement selon le contexte d'usage : un utilisateur sur réseau domestique stable et un utilisateur voyageant régulièrement sur des réseaux publics n'ont statistiquement pas la même exposition au risque, ce qui justifie une évaluation personnalisée plutôt qu'une réponse universelle. Cette évaluation par profil de risque, plus utile qu'une réponse universelle, fait l'objet de notre page qui a vraiment besoin d'un kill switch VPN ?.
Pour vérifier concrètement comment votre kill switch réagit face à plusieurs de ces scénarios simulés, le protocole détaillé sur la page tester un kill switch VPN : protocole de vérification étape par étape reproduit plusieurs de ces causes de manière contrôlée.