En résumé : une connexion VPN n'est pas un état permanent — c'est une session réseau qui peut tomber. Les transitions Wi-Fi, les changements d'antenne cellulaire, les redémarrages de serveur, les pics de perte de paquets, les suspensions d'applications et les cycles de veille du système d'exploitation interrompent régulièrement le tunnel. Quand le tunnel tombe, la règle de routage par défaut du système d'exploitation dit « s'il n'y a pas de route spécifique, utilise l'interface physique » — ce qui signifie que votre trafic bascule vers votre connexion réelle, exposant votre vraie IP à ce avec quoi vous étiez en train de communiquer. Un kill switch est le mécanisme qui dit « non, arrête simplement d'envoyer du trafic jusqu'à ce que le tunnel soit rétabli ». Conceptuellement simple. Dans la pratique, le terme a été utilisé pour désigner au moins trois choses assez différentes, avec des modes de défaillance très distincts.
Pourquoi les kill switches existent — le problème du basculement silencieux
Voyons ce qui se passe sans kill switch. Vous êtes dans un café, VPN connecté, en train de lire vos e-mails via un client webmail. Le Wi-Fi a une brève interruption — peut-être deux secondes. Le client VPN tente de se reconnecter, mais le réseau sous-jacent est indisponible, donc la reconnexion échoue. Après 30 secondes, le réseau revient. Ce qui se passe ensuite dépend du comportement du client VPN :
- Sans kill switch — dès que le Wi-Fi revient, la route par défaut de votre système d'exploitation revient sur l'interface Wi-Fi. Le client VPN est encore en train de se reconnecter, mais vos applications n'attendent pas. La synchronisation en arrière-plan de votre webmail envoie la prochaine requête sur le Wi-Fi nu, avec votre vraie IP, en utilisant le résolveur DNS fourni par le réseau. Le temps que le VPN finisse de se reconnecter (5 à 20 secondes plus tard), la fuite a déjà eu lieu.
- Avec un kill switch — quand le VPN se déconnecte, le kill switch installe une règle de pare-feu qui bloque tout le trafic qui ne transite pas par le tunnel. Même quand le Wi-Fi revient, vos applications ne peuvent rien envoyer tant que la session VPN n'est pas pleinement rétablie. La requête de synchronisation du webmail échoue avec une erreur réseau (l'application réessaie), mais aucun trafic ne quitte votre appareil via l'interface nue.
Le problème du basculement silencieux est la raison centrale pour laquelle les kill switches ont été conçus. Il ne s'agit pas de « le VPN a planté et je navigue maintenant en clair » — c'est le cas bien plus subtil où le VPN est brièvement indisponible, où vos applications ne le savent pas, et où elles fuient dans l'intervalle.
Les trois types de kill switch
Quand les fournisseurs parlent de « kill switch », ils peuvent désigner l'une de ces trois architectures. Les différences importent car les modes de défaillance diffèrent.
1. Kill switch à l'échelle du système (basé sur le pare-feu)
Le modèle le plus robuste. Le client VPN installe une règle de pare-feu sur le système d'exploitation — en utilisant pf sur macOS, la plateforme de filtrage Windows (WFP) sur Windows, iptables ou nftables sur Linux, ou une extension réseau système sur iOS/Android — qui bloque tout paquet sortant qui n'est pas destiné à l'IP du serveur VPN. Quand le VPN est actif, le tunnel lui-même achemine le trafic vers le serveur VPN, les paquets passent donc. Quand le VPN est hors ligne, rien ne correspond à la règle « autoriser », donc tout est bloqué. La règle de pare-feu reste en place même si le client VPN plante, car le pare-feu du système d'exploitation est indépendant de l'application qui a installé la règle.
2. Kill switch au niveau applicatif (par application)
Au lieu de bloquer tout le trafic, le kill switch ne bloque que les applications spécifiques que vous avez ajoutées à une liste. Quand le VPN tombe, ces applications perdent la connectivité réseau jusqu'au retour du VPN ; les autres applications continuent de fonctionner normalement. C'est utile pour des scénarios très précis — protéger un navigateur spécifique, un client IRC, ou un client BitTorrent — mais c'est moins efficace comme défense générale car cela laisse une large surface d'attaque (les applications de la barre des tâches, les services en arrière-plan, les composants du système d'exploitation et les applications que vous avez oublié d'ajouter à la liste).
3. Pare-feu au niveau réseau (VPN toujours actif)
Sur Android en particulier, il existe un mécanisme plus robuste que les kill switches implémentés par les applications VPN elles-mêmes : le paramètre système « VPN permanent » avec « Bloquer les connexions sans VPN » activé. C'est le système d'exploitation lui-même qui applique la règle — Android refuse d'acheminer tout trafic non-VPN, quelle que soit l'application qui le demande. Même si l'application VPN plante, le système d'exploitation maintient la règle. C'est le comportement de kill switch le plus robuste disponible sur mobile et il est strictement plus fort que les kill switches implémentés par les applications.
Comment chaque type fonctionne concrètement au niveau du système d'exploitation
Les détails d'implémentation importent car ils permettent de prévoir les modes de défaillance. Un kill switch basé sur le pare-feu échoue quand l'API du pare-feu est défectueuse. Un kill switch basé sur l'application échoue quand l'application plante. Un VPN permanent imposé par le système d'exploitation échoue pratiquement jamais, sauf si vous redémarrez en mode sans échec.
Implémentation iOS — NetworkExtension et règles à la demande
iOS n'expose pas d'API littérale de « kill switch » aux applications VPN tierces. Ce qu'il expose, c'est le mécanisme de « règles à la demande » du framework NetworkExtension : des règles qui disent « chaque fois qu'une application tente d'établir une connexion réseau qui ne correspond pas à une exception, forcer d'abord la connexion du VPN ». Si le VPN ne peut pas s'établir, la demande de connexion reste en attente. Du point de vue de l'utilisateur, cela se comporte comme un kill switch — mais c'est en réalité une règle « forcer le VPN à s'activer » plutôt qu'une règle « bloquer tout si le VPN est hors ligne ». Le résultat fonctionnel est similaire ; l'implémentation est différente.
L'API NetworkExtension prend également en charge l'option includeAllNetworks (ajoutée dans iOS 14) qui fait du VPN un filtre réseau au niveau du système — même le trafic du noyau et des services système est forcé à passer par le VPN. Avec cet indicateur activé, le VPN fonctionne vraiment comme un kill switch complet, le système d'exploitation garantissant qu'aucun trafic n'échappe au tunnel. Tous les fournisseurs VPN ne l'activent pas ; l'indicateur a des implications de compatibilité.
Implémentation Android — VPN permanent + Bloquer les connexions sans VPN
Le comportement de kill switch le plus robuste d'Android se trouve dans Paramètres, puis Réseau et internet, puis VPN, puis l'icône d'engrenage à côté de votre VPN, puis les deux boutons bascule : « VPN permanent » et « Bloquer les connexions sans VPN ». Quand les deux sont activés, c'est le système Android lui-même — pas l'application VPN — qui refuse d'acheminer le trafic tant que le VPN n'est pas connecté. L'application VPN peut planter, être forcée à se fermer, ou être désinstallée, et la règle persiste. La documentation officielle pour les développeurs Android décrit le mécanisme en détail. C'est le standard de référence pour le comportement de kill switch sur les appareils mobiles grand public.
Implémentation macOS — extensions réseau système
macOS 11 (Big Sur) et les versions ultérieures font tourner les VPN via le framework System Extension — la même architecture qui prend en charge les filtres de contenu et les filtres réseau au niveau du système. Le kill switch est généralement implémenté sous forme de règle de filtrage de paquets (pf) installée par le client VPN, combinée à une extension réseau qui maintient la modification de la table de routage. Quand le VPN tombe, la règle pf reste en place et continue de bloquer le trafic jusqu'à ce que le VPN se rétablisse. Si le client VPN lui-même plante, le comportement dépend de si l'extension système est configurée pour rester chargée — les clients bien conçus maintiennent les règles en place ; les clients mal conçus les suppriment lors du plantage et fuient.
Implémentation Windows — plateforme de filtrage Windows
Les VPN Windows implémentent généralement le kill switch en installant des règles de filtre de la plateforme de filtrage Windows (WFP) qui bloquent le trafic sur l'adaptateur physique tout en autorisant le trafic sur l'adaptateur VPN virtuel. Les filtres persistent à travers les redémarrages du processus client VPN (ils appartiennent à la couche de filtre du noyau, pas à l'application en espace utilisateur), donc même si l'application VPN plante, le filtre reste. Le risque est que certains clients VPN utilisent des stratégies de règles de pare-feu de moindre qualité — par exemple, manipuler le Pare-feu Windows Defender via PowerShell ou netsh — qui peuvent être contournées par d'autres règles de pare-feu ou par une mauvaise configuration.
Quand les kill switches échouent — fuites à connaître
Un kill switch n'est pas une garantie parfaite. Il existe des conditions bien documentées dans lesquelles le trafic peut fuir même avec un kill switch activé. Chaque fournisseur VPN gère ces situations différemment ; certaines sont résolues par une implémentation soignée, d'autres sont inévitables sans la coopération du système d'exploitation.
Empoisonnement DNS lors du démarrage de la connexion
Pour se connecter au serveur VPN, le client VPN doit d'abord résoudre le nom d'hôte du serveur. Si le kill switch impose « pas de trafic sans VPN », mais que le client VPN lui-même doit effectuer une recherche DNS pour trouver le serveur VPN, il doit y avoir une exception — et cette exception est une petite surface de fuite. Un réseau local malveillant pourrait empoisonner la réponse DNS et rediriger le client VPN vers un faux serveur. La plupart des clients gèrent cela en utilisant une IP codée en dur pour le serveur VPN, ou en épinglant le certificat TLS pour qu'un serveur redirigé ne soit pas validé. Les clients VPN bon marché sautent parfois cette étape.
Fuites IPv6
Si votre réseau dispose d'une connectivité IPv6 mais que le kill switch du client VPN ne bloque que le trafic IPv4, votre trafic IPv6 peut circuler sur l'interface nue même quand le kill switch est « actif ». C'est l'un des modes de fuite les plus courants dans la réalité. La solution est que le client VPN installe des règles de pare-feu IPv6 correspondantes. Beaucoup de clients plus anciens ne le font pas. Testez toujours les fuites IPv6 après avoir activé un kill switch en effectuant un test de fuite.
Portails captifs (pages de connexion Wi-Fi)
Les cafés, aéroports et hôtels vous obligent souvent à vous connecter via un portail captif avant d'accéder à internet — y compris au serveur VPN. Un kill switch strict refusera de vous laisser accéder au portail captif car le portail captif n'est pas le serveur VPN. La plupart des clients VPN disposent d'un mode « mettre le kill switch en pause pour le portail captif » que vous devez activer manuellement. Pendant la pause, vous n'êtes pas protégé, donc ne naviguez rien de sensible tant que le kill switch n'est pas réactivé. Le VPN permanent natif du système d'exploitation sur Android gère cela légèrement plus élégamment via la détection de portail captif système, mais le compromis est le même.
Courses à la suspension d'application et au redémarrage en arrière-plan
Sur mobile, le système d'exploitation peut suspendre l'application VPN pour économiser la batterie. Quand l'application reprend, il y a une petite fenêtre pendant laquelle le tunnel est en train d'être rétabli. Si le kill switch est implémenté au niveau du système d'exploitation (via includeAllNetworks sur iOS ou le VPN permanent sur Android), il n'y a pas de fuite. Si le kill switch est implémenté purement dans l'application, il peut y avoir une brève fenêtre où le système d'exploitation a relancé les applications mais où le VPN ne s'est pas reconnecté, et les applications effectuant des appels réseau pendant cette fenêtre fuiront.
Course au démarrage
Sur ordinateur de bureau, la période entre le démarrage du système et le lancement du client VPN n'est pas protégée. Les applications réseau qui démarrent automatiquement (Mail, Slack, Steam, les vérifications de mises à jour système) établissent souvent des connexions avant que le VPN ne soit actif. Un kill switch robuste installe sa règle de pare-feu comme règle persistante au démarrage afin que, même au boot, le trafic soit bloqué jusqu'à ce que le VPN se connecte. La plupart des clients VPN grand public ne font pas cela ; la règle s'applique seulement après le démarrage du client.
Comparaison des types de kill switch
| Type | Ce qu'il bloque | Support système d'exploitation | Modes de défaillance courants |
|---|---|---|---|
| Pare-feu à l'échelle du système | Tout le trafic non-VPN au niveau du noyau | macOS, Windows, Linux ; iOS via includeAllNetworks | Fuites IPv6 si les règles sont uniquement IPv4 ; course au démarrage ; exception DNS bootstrap |
| Au niveau applicatif (liste de blocage par application) | Uniquement le trafic des applications listées | Windows, certains clients macOS | Les applications absentes de la liste continuent de fuir ; les composants du système d'exploitation fuient ; les services système fuient |
| VPN permanent imposé par le système d'exploitation | Tout le trafic au niveau du système d'exploitation, quel que soit le plantage de l'application | Android (VPN permanent + Bloquer sans VPN), iOS (NetworkExtension à la demande) | La connexion au portail captif est bloquée jusqu'à la pause ; très peu d'autres modes de défaillance |
| Surveillant d'application (la forme faible) | Rien directement ; ferme simplement les applications spécifiées quand le VPN tombe | Certains clients Windows proposent encore ceci | Course entre la détection et la fermeture provoque des fuites ; pas vraiment un kill switch |
Ce que le « VPN permanent » vous offre vraiment qu'un kill switch applicatif n'offre pas
La distinction la plus importante en 2026 est entre les kill switches implémentés par les fournisseurs et le VPN permanent imposé par le système d'exploitation. Voici pourquoi la version imposée par le système d'exploitation est significativement plus robuste :
- Survit aux plantages de l'application VPN. Si l'application VPN plante pour quelque raison que ce soit, un kill switch applicatif disparaît avec elle. La règle de pare-feu qu'elle a installée peut ou non persister selon l'implémentation. Une règle imposée par le système d'exploitation est maintenue par le système lui-même et continue de s'appliquer.
- Survit aux redémarrages. De nombreux kill switches applicatifs installent des règles au lancement de l'application et les suppriment à la fermeture, laissant un intervalle au démarrage. Les paramètres de VPN permanent au niveau système sont respectés dès le premier paquet réseau que le système d'exploitation achemine après le démarrage.
- Couvre les services système. La synchronisation cloud, les vérifications de mises à jour du système d'exploitation, les démons de notifications push et autres services au niveau du système d'exploitation ne passent pas par le routage normal du client VPN. Le VPN permanent imposé par le système les couvre ; un kill switch applicatif peut ne pas le faire.
- Ne peut pas être contourné par erreur utilisateur. Un kill switch applicatif a un bouton bascule dans l'interface de l'application. Un utilisateur (ou une autre application avec les permissions) peut le désactiver. Le VPN permanent au niveau système est dans les paramètres système et est plus difficile à désactiver accidentellement.
Sur Android, préférez la version imposée par le système d'exploitation : activez « VPN permanent » et « Bloquer les connexions sans VPN » dans les paramètres système, et considérez le kill switch du client VPN comme un complément. Sur iOS, recherchez des clients VPN qui activent includeAllNetworks ; c'est l'indicateur équivalent et il offre des garanties similaires.
Ce que fait Casper — la réponse honnête
Casper's Cloak utilise un kill switch intégré au système d'exploitation sur chaque plateforme — includeAllNetworks sur iOS pour que le système lui-même applique la règle anti-fuite, les paramètres de VPN permanent sur Android, et des règles de filtrage de paquets au niveau du noyau sur macOS. Le comportement est identique sur les trois : quand le tunnel tombe, tout le trafic s'arrête, y compris IPv6 et y compris les services au niveau du système d'exploitation. Quand le tunnel revient, le trafic reprend. Pas de bouton bascule à oublier, pas de liste par application à maintenir, pas de carve-out IPv6.
Nous couplons cela avec la protection contre les menaces et le bouclier anti-menaces pour un filtrage actif contre les domaines malveillants connus, de sorte que le tunnel n'est pas seulement une couche de routage — il rejette activement les connexions vers le phishing, les serveurs C2 malveillants et les infrastructures connues comme dangereuses. Le kill switch est la garantie de base qu'aucun trafic ne contourne le filtrage quand le tunnel tombe brièvement. L'effet combiné : même sur des réseaux hostiles comme ceux décrits dans notre article sur les attaques Wi-Fi public, vous n'avez pas cette « fenêtre de deux secondes en clair » que laisse ouverte un kill switch uniquement applicatif.
Notre position sur les kill switches en général : c'est une exigence de base, pas une fonctionnalité premium. Tout VPN grand public qui n'en propose pas en 2026 manque d'un mécanisme de sécurité fondamental. Pour le contexte de modélisation des menaces expliquant pourquoi cela importe au niveau système, le guide de la NSA sur la sélection et le renforcement des VPN d'accès à distance couvre le raisonnement architectural en détail, avec une recommandation en faveur des architectures full-tunnel soutenues par une application au niveau du noyau.
En résumé
« Est-ce que ce VPN a un kill switch » est la mauvaise question. Les bonnes questions sont : où dans la pile le kill switch est-il appliqué (application, système ou système d'exploitation), couvre-t-il IPv6, persiste-t-il à travers les plantages d'application et les redémarrages, et est-il activé par défaut. Si les réponses sont « niveau système d'exploitation », « oui », « oui » et « oui », le kill switch fait son travail. Si les réponses sont « niveau applicatif uniquement », « non », « ça dépend » et « désactivé par défaut », vous avez un kill switch de nom mais pas de protection.
La pratique simple : sur Android, activez le VPN permanent système avec « Bloquer les connexions sans VPN ». Sur iOS, utilisez un client VPN qui active includeAllNetworks. Sur ordinateur de bureau, vérifiez après l'installation en effectuant un test de fuite, puis déconnectez brièvement le côté serveur VPN (ou débranchez votre câble réseau) et confirmez que le trafic s'arrête réellement. Si le test de fuite affiche toujours votre vraie IP, le kill switch ne fonctionne pas comme annoncé — enquêtez avant de lui faire confiance.