Kill switch d’application contre kill switch de pare-feu : ce que chacun bloque

Un kill switch sur une liste de fonctions ne vous dit presque rien de ce qui se passe lorsque le tunnel tombe. Une implémentation ferme des processus sélectionnés, une autre installe des filtres de paquets à la frontière du système d’exploitation, et une troisième tente simplement de se reconnecter. La différence apparaît dans les secondes qui suivent une panne, pas sur l’écran des réglages. Parcourez ces vérifications dans l’ordre et arrêtez-vous à la première à laquelle vous ne pouvez pas répondre honnêtement, car c’est là que votre couverture réelle s’arrête.

Nommez d’abord le mécanisme d’application

La fin de processus est une fonction du cycle de vie de l’application. Elle trouve des programmes sélectionnés après une panne de tunnel détectée et les ferme. Tout ce qui n’est pas le processus principal survit : services auxiliaires, synchronisation en arrière-plan et toute application lancée une seconde plus tard ont leur propre cycle de vie et leur propre calendrier.

Le filtrage de paquets est une fonction du système d’exploitation. Il refuse le trafic qui ne suit pas le chemin autorisé, ce qui est une promesse plus forte, mais seulement à hauteur de ce que la règle couvre réellement. La famille d’adresses, l’interface, les applications exclues et les exceptions en décident, pas l’étiquette dans le client.

Le blocage survit-il au client ?

Posez quatre questions dans cet ordre : que se passe-t-il lors d’un plantage, d’une fermeture manuelle, d’une déconnexion et d’un redémarrage. Une règle maintenue par le client lui-même est généralement supprimée lors d’un arrêt propre et souvent laissée derrière après un plantage. Une règle installée dans le magasin de la plateforme peut se comporter à l’inverse : survivre au client et, parfois, à la désinstallation.

Fermez le client au milieu d’un long téléchargement et regardez si le transfert s’arrête ou continue.

Cherchez les trous classiques

IPv6 est le premier. Une règle écrite pour des adresses IPv4 laisse le trafic IPv6 intact, et beaucoup de clients n’écrivent que la moitié v4. Le deuxième est l’interface : le partage de connexion USB, un second adaptateur Wi-Fi et un modem cellulaire peuvent ne pas être inclus dans une règle limitée à la connexion principale. Applications exclues et les exceptions de réseau local sont le troisième.

Sous Windows, vous pouvez lire les règles installées plutôt que faire confiance à l’interrupteur : Get-NetFirewallRule -DisplayName '*VPN*' et netsh wfp show filters montrent tous deux ce qui existe. Sous Linux, iptables -S, ip6tables -S et nft list ruleset couvrent les cas courants, et comparer les trois est tout l’intérêt.

Le DNS est la fuite habituelle

Bloquer TCP tout en laissant UDP 53 ouvert vous donne un kill switch très convaincant qui répond encore à chaque requête de nom d’hôte. Il en va de même lorsque le DNS est confié à un résolveur sur une autre interface, ou lorsque le client ne bloque que v4 et que le résolveur est joignable en v6.

Tunnel coupé, résolvez un nom connu et voyez si une réponse revient. Si oui, le trafic n’est pas totalement bloqué, quoi que dise l’icône d’état.

Testez la transition, pas l’interrupteur

Éteindre le VPN depuis son propre menu est un arrêt propre, et le cas propre est celui que chaque implémentation gère bien. La transition qui compte est la brutale : tuez le processus du tunnel, coupez le réseau, laissez le serveur cesser de répondre. Lancez ensuite une requête et regardez si elle échoue ou utilise discrètement le lien physique.

Le résultat d’un ordinateur portable ne se transpose pas à un téléphone ni à un routeur. Des API de plateforme différentes, des valeurs par défaut différentes, et sous Android la différence est flagrante : le mode always-on avec blocage est appliqué par le système et non par le client, il continue donc de fonctionner quand le client ne le fait pas. Le guide VPN d’Android décrit cette séparation.

Gardez un chemin de retour

Le blocage au niveau du système a le mode de défaillance inverse. Des filtres qui survivent au client peuvent laisser une machine sans aucun réseau après une désinstallation, ce qui est un appel au support sans cause évidente. Avant d’activer un kill switch qui écrit des règles de plateforme, notez comment il est retiré, et gardez le chemin de réparation du fournisseur là où vous pouvez le trouver.

Si vous ne pouvez pas répondre aux vérifications de plantage, d’IPv6, de DNS et de transition pour votre client, traitez-le comme un interrupteur de niveau applicatif avec des trous connus et planifiez en conséquence.