Tester son kill switch VPN en 2026 : comment prouver qu'il coupe vraiment

Transparence : cet article contient des liens affiliés. Si vous achetez via ces liens, nous pouvons percevoir une commission sans surcoût pour vous. Nous ne recommandons que des services que nous utiliserions nous-mêmes, sur la base de leurs caractéristiques publiées et de leur historique public.

Presque personne ne teste son kill switch. Le bouton est activé, l'application dit protégé, et cela s'arrête là. Voici la partie gênante.

Le réglage est une affirmation, pas une preuve

Un kill switch activé et un kill switch qui fonctionne sont deux choses différentes, et l'interface ne peut pas les distinguer. Le bouton rapporte ce que l'application a l'intention de faire, pas ce que le système d'exploitation fera réellement quand le tunnel tombera au mauvais moment.

Trois défaillances réelles, dont aucune ne change l'état du bouton :

le processus VPN plante avant que ses règles de pare-feu prennent effet, et il ne reste rien pour les faire appliquer ;
les règles couvrent IPv4 et oublient IPv6, si bien que le trafic sort à côté du tunnel dès que le réseau le propose ;
l'appareil sort de veille avec le réseau revenu et le tunnel pas encore remonté.

Vue par-dessus l'épaule d'un portable posé sur une table en bois : l'écran affiche une application VPN bleue avec un logo de montagne blanc et un interrupteur portant la mention VPN, You are connected, un petit cactus en pot est posé à droite de la table, et une personne en manche bleu clair tient un téléphone blanc au premier plan flou

L'écran de cette photo affiche « You are connected ». Cette phrase est l'application qui se décrit elle-même, et c'est exactement ce à quoi servent les tests ci-dessous. Photo de Stefan Coders via Pexels.

Les quatre tests, du plus facile au plus honnête

1. Notez votre adresse, puis cassez le tunnel exprès

Relevez votre IP publique avec le tunnel actif et notez-la. Puis tuez le processus du VPN plutôt que de cliquer sur déconnecter, parce que le clic sur déconnecter est justement le cas auquel le développeur a pensé.

Vérifiez aussitôt votre IP et essayez de charger n'importe quoi. Si l'un des deux aboutit et montre votre adresse réelle, le dispositif n'a pas coupé.

2. Recommencez pendant un transfert

Lancez un gros téléchargement ou une vidéo, puis cassez le tunnel.

Beaucoup de kill switches bloquent les nouvelles connexions et laissent courir celles qui sont établies. Une machine au repos passe un test qu'une machine qui travaille échoue, et c'est pour cela que le test au repos flatte votre installation.

3. Vérifiez les deux piles, pas une

Utilisez un vérificateur qui rapporte IPv4 et IPv6 séparément. Un jeu de règles écrit pour l'une et pas pour l'autre est l'un des échecs les plus courants, et un test qui n'affiche qu'IPv4 masquera exactement la fuite que vous cherchez.

4. Mettez la machine en veille, réveillez-la, et regardez vite

Rabattez l'écran, attendez, rouvrez. Le réseau revient en général avant le tunnel. Cet intervalle est du vrai trafic sur une vraie route, et c'est la défaillance que personne ne remarque parce qu'elle dure quelques secondes et ne laisse aucune trace à l'écran.

Ce qu'un kill switch NE couvre PAS

C'est là que la plupart des articles s'arrêtent, et c'est là que la partie utile commence.

Ce n'est pas un correctif de fuite DNS. Un kill switch décide si les paquets sortent quand le tunnel est tombé. Une fuite DNS est une requête envoyée au mauvais résolveur pendant que le tunnel est actif. Deux défauts différents, deux correctifs différents, et une machine peut passer l'un et échouer à l'autre. Notre guide de prévention des fuites DNS couvre le second.

Ce n'est pas un correctif WebRTC. Un navigateur peut révéler une adresse locale via WebRTC avec un tunnel en parfaite santé. Voyez notre test de fuite WebRTC.

Il ne rend pas anonyme. Il tient une promesse précise : que le trafic s'arrête au lieu de s'échapper quand le tunnel tombe. Cette promesse vaut d'être tenue, et elle est étroite.

Applicatif ou pare-feu, et pourquoi cela décide de tout

Deux mises en œuvre portent le même nom.

Au niveau applicatif : le client VPN arrête le trafic qu'il gère. Si le client meurt, l'application de la règle meurt avec lui.
Au niveau du pare-feu : des règles du système bloquent tout sauf le point de sortie du VPN. Elles survivent au plantage du client, ce qui est précisément la défaillance qui compte le plus.

Si vous auto-hébergez, vous écrivez ces règles vous-même et vous savez laquelle des deux vous avez. Notre kill switch Linux avec iptables et systemd est la version au niveau du pare-feu, et il continue de fonctionner quand le processus du tunnel ne fonctionne plus, parce que les règles ne dépendent pas de lui.

C'est l'argument honnête en faveur de l'auto-hébergement ici : non pas qu'il soit plus sûr par nature, mais que vous pouvez lire la règle qui vous protège. Avec un client commercial, vous faites confiance à une description de comportement ; avec vos propres règles, vous regardez le comportement.

Que faire du résultat

Si votre kill switch échoue à l'un de ces tests, le correctif n'est généralement pas un autre fournisseur. C'est une règle de pare-feu qui ne dépend d'aucune application restée en vie, et sur un VPS que vous contrôlez cela tient en quelques lignes. Notre classement des VPS les moins chers pour WireGuard compare les hébergeurs sur le prix et la bande passante.

Et s'il passe les quatre : notez la date. Un kill switch n'est pas une propriété permanente d'une machine. Une mise à jour du système, une nouvelle interface réseau ou un jeu de règles modifié peuvent le défaire, et le bouton dira toujours qu'il est actif.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · 200+ Mbps garantis

Héberge ton VPN sur ton propre VPS → ContaboAccès root complet · IPv4 publique · choisis ta région→

Questions fréquentes

Comment tester un kill switch VPN ?

Notez votre adresse IP publique avec le tunnel actif, puis cassez le tunnel sans le prévenir : tuez le processus du VPN, débranchez le câble réseau ou désactivez l'interface. Vérifiez immédiatement votre IP et essayez de charger n'importe quel site. Si l'un des deux aboutit et montre votre adresse réelle, le kill switch n'a pas coupé. Recommencez pendant qu'un transfert est en cours, car un dispositif qui bloque les nouvelles connexions peut laisser courir une connexion déjà établie.

Le réglage activé signifie-t-il que le kill switch fonctionne ?

Non, et c'est tout l'objet de ce test. Le réglage est une affirmation de l'application sur son propre comportement. Un kill switch échoue de façons que le bouton ne peut pas rapporter : un plantage qui emporte le processus avant que ses règles de pare-feu s'appliquent, un jeu de règles qui couvre IPv4 et oublie IPv6, un appareil qui sort de veille avec le réseau revenu et le tunnel pas encore remonté. Le bouton reste allumé dans les trois cas.

Que fait réellement un kill switch VPN ?

Il empêche le trafic de sortir de la machine quand le tunnel n'est pas actif. Les mises en œuvre diffèrent : certaines écrivent des règles de pare-feu qui bloquent tout sauf le point de sortie du VPN, d'autres se contentent d'arrêter les applications qu'elles gèrent, et la différence compte énormément. Un dispositif au niveau du pare-feu survit à la mort du processus VPN ; un dispositif applicatif meurt avec lui.

Faut-il activer le kill switch de son VPN ?

Si la conséquence d'un seul paquet non protégé compte pour vous, oui. Si vous utilisez un VPN pour joindre vos propres machines ou pour tenir le réseau d'un café hors de votre trafic, c'est le kill switch qui fait tenir cette garantie au moment d'une coupure. Si votre modèle de menace tolère quelques secondes de trafic exposé, c'est un confort plutôt qu'une nécessité. Décidez d'après la conséquence, pas d'après la liste des fonctionnalités.

Les kill switches laissent-ils fuir l'IPv6 ?

Certains oui, et c'est l'un des échecs réels les plus fréquents. Un jeu de règles écrit pour IPv4 peut laisser IPv6 intact, si bien que dès que votre réseau propose de l'IPv6 le trafic sort à côté du tunnel. Testez avec un vérificateur d'adresse qui rapporte les deux piles, pas un qui n'affiche qu'IPv4, sinon le test lui-même masquera le problème.

Un kill switch protège-t-il des fuites DNS ?

Pas en lui-même. Un kill switch décide si les paquets sortent quand le tunnel est tombé ; une fuite DNS est une requête envoyée au mauvais résolveur pendant que le tunnel est actif. Ce sont deux défauts différents avec deux correctifs différents, et une machine peut passer un test et échouer à l'autre. Testez les deux.

Pourquoi ma connexion survit-elle quelques secondes après la chute du VPN ?

Parce que beaucoup de kill switches bloquent les nouvelles connexions sans couper celles qui sont établies. Un téléchargement ou une vidéo déjà en cours peut continuer sur l'ancienne route. C'est pour cela que le test honnête se fait pendant un transfert, et non sur une machine au repos où tout paraît propre.