Fail-open ou fail-closed : ce que décide un kill switch de VPN
Les deux termes décrivent ce qui arrive quand le tunnel disparaît, pas la robustesse du chiffrement. L’étendue que vous choisissez décide si le trafic fuit vraiment.
Le mythe veut que fail-closed soit le réglage sûr et fail-open le négligent. Les deux décrivent ce qui arrive au trafic une fois le tunnel disparu, et ni l’un ni l’autre ne change la qualité du chiffrement de ce tunnel. Une politique fail-closed avec une longue liste d’exceptions peut fuiter plus qu’une politique fail-open sur un appareil qui ne quitte jamais le réseau du bureau. Choisissez l’issue que vous pouvez expliquer à la personne qui possède le trafic.
L’étiquette décrit une issue, pas une force
Le vocabulaire vient des systèmes de contrôle : fail-open autorise le fonctionnement quand un composant tombe en panne, fail-closed le refuse. Appliqué à un VPN, le composant qui tombe est le tunnel, et la question est de savoir si le trafic peut continuer par un autre chemin. Le choix du chiffrement, la longueur de clé et le protocole sont des décisions distinctes.
La confusion persiste parce qu’un kill switch sonne comme une fonction de sécurité, et les fournisseurs le vendent comme telle. Mécaniquement, c’est une règle de routage et de pare-feu qui bloque le trafic que le tunnel était censé porter, implémentée dans le client, dans le système d’exploitation ou sur la passerelle. La couche qui l’applique définit aussi sa couverture, et une règle d’une couche ne couvre pas une autre. Une règle sur la passerelle ne peut pas protéger un portable déjà passé sur un autre réseau.
À quoi ressemble chaque issue
La même politique peut se comporter très différemment selon la panne que vous rencontrez, alors comparez les événements plutôt que les étiquettes.
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
La dernière ligne est celle qui piège ceux qui supposent qu’un kill switch est un interrupteur unique. Une règle écrite pour la table de routage IPv4 laisse la route par défaut IPv6 intacte, et l’application peut l’utiliser allègrement.
L’étendue décide de la fuite
Demandez ce que la politique couvre avant de demander de quel mode il s’agit. Une règle par application protège une application et rien d’autre, une règle à l’échelle de l’appareil protège tout sauf les exceptions, et une règle sur la passerelle ne protège que le trafic qui atteint cette passerelle. Le DNS a besoin de sa propre décision, car une requête envoyée à un résolveur local peut révéler des noms même quand la charge utile est bloquée.
Les exceptions de réseau local existent pour les imprimantes, la diffusion d’écran et les portails captifs, et chacune est un trou dans le blocage. Documentez-les à côté de la politique, sinon la personne qui hérite de la configuration lira fail-closed comme absolu.
Reconnexion et blocage sont aussi des contrôles distincts. Un client peut se reconnecter automatiquement sans jamais bloquer, ou bloquer sans se reconnecter, et la combinaison détermine ce que vit un utilisateur pendant une panne.
Prouvez-le pendant une transition
Tester l’état stable ne prouve rien. Coupez le tunnel exprès et essayez l’application censée être protégée, puis vérifiez si elle a atteint le réseau. Comparez l’indicateur du client au résultat, car un indicateur qui affiche encore connecté est exactement le cas pour lequel la politique existe. Si l’application protégée réussit, le nom du mode importe peu ; vous avez une fuite.
Répétez depuis un démarrage à froid avant l’ouverture de session, lors d’un passage du Wi-Fi au réseau mobile et avec l’application protégée en arrière-plan. Si le blocage est appliqué par le processus client, testez aussi ce qui se passe quand ce processus est tué plutôt que fermé proprement.
Enfin, vérifiez le chemin de nettoyage. Si un client est désinstallé alors que ses règles sont actives, utilisez la procédure de suppression documentée du fournisseur au lieu de désactiver le pare-feu du système d’exploitation, qui retire une protection sans rapport sans répondre à la question de savoir à qui appartient la règle restante.