Pourquoi un kill switch coupe le trafic lors d'un changement de serveur
Pourquoi un kill switch bloque le trafic pendant un changement de serveur, ce que fait le client dans cette fenêtre et comment distinguer une pause normale d'un blocage coincé.
Vous choisissez un serveur qui semble plus proche, vous cliquez sur connecter, et le navigateur cesse de charger avant que le nouveau tunnel soit monté. L'icône passe en état de connexion et y reste pendant que chaque onglet expire. Cette pause est généralement le kill switch qui fonctionne comme prévu : le trafic est bloqué tant que le client n'a pas de tunnel par lequel l'envoyer. Que la pause soit acceptable dépend de ce que fait le client pendant ces secondes, et de si le blocage est levé quand il dit qu'il l'est.
Ce que fait le client entre deux serveurs
Un changement de point de terminaison compte plusieurs étapes, pas un seul commutateur. Le client démonte le tunnel actuel, met à jour ses règles de blocage, résout et atteint le nouveau point de terminaison hors du tunnel, puis installe les nouvelles routes et lève le blocage. Le trou que vous ressentez se situe entre la première étape et la dernière.
L'ordre compte ici plus que la vitesse. Si les règles de blocage passent avant l'exception pour le nouveau point de terminaison, le client ne peut pas terminer la poignée de main et reste sur connexion jusqu'à un délai d'attente. Si l'exception est une copie de l'adresse de l'ancien serveur, la nouvelle poignée de main ressemble à n'importe quel paquet sortant et se fait jeter. Les deux cas se ressemblent depuis le navigateur, et c'est pourquoi un changement qui se rétablit au bout de six secondes et un autre qui ne se rétablit jamais peuvent partager la même cause.
Le nouveau point de terminaison a besoin d'un trou dans le blocage
Pour construire le tunnel, le client doit envoyer des paquets vers l'adresse et le port du nouveau serveur sur l'interface physique, par exemple UDP 51820 pour un profil WireGuard typique ou 1194 et 443 pour OpenVPN, quoi que spécifie votre propre profil. Ce trafic n'est pas dans le tunnel qu'il est sur le point de créer, donc un blocage de tout l'appareil l'avale, sauf s'il existe une règle d'autorisation correspondante.
Les profils basés sur un nom d'hôte ajoutent une seconde exigence : la résolution elle-même. Si le client résout le point de terminaison avant que le blocage monte, il peut utiliser une adresse en cache, mais dès que le profil fait tourner les adresses ou que l'entrée en cache devient obsolète, la poignée de main vise une adresse que la règle d'autorisation ne couvre pas. IPv6 rend cela visible, car un point de terminaison à double pile peut publier à la fois un enregistrement A et un AAAA, et une règle d'autorisation qui ne couvre que l'adresse v4 laisse le client réessayer contre une adresse v6 bloquée.
Les noms d'options et les valeurs par défaut varient selon le client et la version, alors lisez la liste documentée pour le vôtre au lieu de deviner à partir de captures d'écran. La référence des réglages d'OpenVPN Connect sur openvpn.net/connect-docs/app-settings-windows est un exemple de la façon dont un client décrit ses options de blocage et de tunnel partagé.
Fail-closed est une machine à états, pas un commutateur
La plupart des clients expriment le blocage comme une politique de pare-feu en trois états : tunnel monté, avec le trafic qui passe par le tunnel et aucun blocage ; tunnel tombé, avec le blocage actif ; et transition, avec le blocage actif plus des exceptions temporaires pour le point de terminaison. C'est dans le troisième état que vivent les bogues, car il doit changer deux fois en quelques secondes, et l'impossibilité d'en sortir ressemble exactement à un blocage permanent.
Le mécanisme diffère selon la plateforme, et l'échec aussi. Les filtres de Windows Filtering Platform portent des poids, donc un filtre de blocage qui surpasse votre autorisation continue de jeter des paquets alors même que l'autorisation existe, et les filtres laissés par un processus client tué peuvent maintenir la machine hors ligne après la disparition de l'application. Les clients macOS écrivent généralement des règles pf dans une ancre, où l'ordre des règles et les décisions rapides déterminent quelle règle s'applique. Les clients Linux gèrent généralement une chaîne nftables ou iptables avec une politique drop et des autorisations explicites pour le point de terminaison, l'interface du tunnel et la boucle locale. Le VPN toujours actif d'Android avec l'option de bloquer les connexions sans VPN est le plus strict du groupe, car le système applique le blocage à tout l'appareil et non par application.
WireGuard mérite sa propre note, car AllowedIPs est un sélecteur de routage, pas un bloqueur. Il décide quelles destinations entrent dans le tunnel ; il ne fait rien pour empêcher un paquet encore sans tunnel de sortir en Wi-Fi. Dans une configuration uniquement WireGuard sans règle de pare-feu, le kill switch est en réalité l'absence de route, et une poignée de main rejetée peut être suivie d'un vrai paquet qui sort par l'interface physique.
Mesurez le trou au lieu de regarder l'icône
Surveillez les paquets, pas le voyant d'état. Sous Linux, lancez un ping lent vers une adresse publique dans un terminal et capturez le port de transport du tunnel sur l'interface physique dans un autre :
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Changez de serveur dans le client pendant que les deux tournent. Trois choses comptent : combien de temps les ping s'arrêtent, si la capture montre la poignée de main atteignant le nouveau point de terminaison, et si le trafic reprend avant ou après que l'état du client passe à connecté. Si le trou des ping se termine en premier, soit le blocage a été levé trop tôt, soit le tunnel est monté avant que l'indicateur ne l'admette. Si le trou se termine plus tard, l'indicateur est optimiste.
Sous Windows, netsh wfp show state écrit un instantané dans lequel vous pouvez chercher des filtres de blocage encore présents alors que le client prétend être déconnecté. Sous macOS, sudo pfctl -sr liste les règles chargées et leur ordre. Associez l'un ou l'autre instantané au journal du client ; la chronologie de votre ping vous dit si le blocage s'est terminé tard ou jamais.
Coupure normale contre blocage coincé
Un peu d'interruption est le but de la fonction, alors faites un triage avant de changer le moindre réglage :
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Si vous tombez dans la deuxième ou la cinquième ligne, ne désactivez pas le kill switch pour tester, car cela transforme un bogue de routage en fuite. Redémarrez le service du client, ou redémarrez la machine là où les filtres survivent à la mort du processus, puis regardez si le blocage se dissipe. S'il se dissipe, la faute est au nettoyage pendant le changement, pas au blocage lui-même.
Avant votre prochain changement, confirmez quatre choses : l'autorisation du point de terminaison couvre chaque famille d'adresses que votre profil résout, le journal du client montre la transition terminée, votre test de ping mesure le trou plutôt que l'icône, et quitter le client rétablit la connectivité normale. Un kill switch qui tient pendant le changement et relâche ensuite fait son travail. Un qui relâche trop tôt, ou jamais, mérite d'être débogué.