Le kill switch bloque le serveur VPN avant que le moindre trafic ne circule
Quelle étape un kill switch bloque : résolution du point de terminaison, route extérieure, chemin de retour et exceptions de pairs obsolètes — avec des compteurs plutôt que des suppositions.
Les kill switch échouent dans une direction que les gens n’attendent pas : ils sont conçus pour bloquer le trafic lorsque le tunnel est coupé, et les paquets qui construisent le tunnel sont eux-mêmes du trafic. C’est toute l’erreur. Un jeu de règles qui rejette tout ce qui ne sort pas par le tunnel rejette aussi la poignée de main qui devrait le monter, donc le client réessaie en boucle et l’erreur est attribuée à l’étape qui est vérifiée en premier. Avant d’élargir un pare-feu, déterminez laquelle des trois étapes est refusée : la résolution du nom, le paquet extérieur vers le pair ou la réponse qui revient.
Comment le tunnel et son propre transport dépendent l’un de l’autre
Lisez un client VPN comme deux états réseau qui partagent un même chemin de socket. Avant que le tunnel existe, le client ouvre un socket sur l’adaptateur physique et envoie des trames chiffrées à l’adresse et au port du pair. C’est seulement lorsque cet échange réussit qu’il crée l’interface de tunnel et installe les routes. Un kill switch est une politique sur le second état, écrite si largement qu’elle s’applique aux deux.
Les règles fondées sur l’interface sont la forme habituelle : acceptez ce qui sort par tun0 ou wg0, rejetez le reste du chemin de sortie. Cette formulation ne peut pas exempter la connexion du client au serveur, donc une implémentation correcte ajoute cette exception explicitement, et vous aussi lorsque vous écrivez des règles à la main. Les règles par application sous Windows et macOS évitent une partie de cela en faisant correspondre un processus plutôt qu’une interface, mais le processus doit tout de même sortir avant que le tunnel existe.
Trois étapes, dans l’ordre où elles se produisent
La première étape est la résolution. Lorsque le profil stocke un nom d’hôte au lieu d’une adresse littérale, le client a besoin d’une réponse DNS avant de pouvoir envoyer quoi que ce soit. Un profil qui pointe le DNS vers le résolveur du tunnel crée un blocage : le résolveur n’est joignable qu’à travers le tunnel que la recherche est censée activer. Résoudre hors du tunnel, ou épingler le point de terminaison à une adresse, supprime l’ambiguïté.
La deuxième étape est le paquet extérieur, qui doit survivre d’abord au routage puis au pare-feu, dans cet ordre. wireguard-tools s’occupe de la moitié routage de cela pour WireGuard en marquant ses propres paquets et en ajoutant une règle de politique pour qu’ils contournent la route par défaut qu’il vient d’installer ; la page de manuel de wg-quick décrit cette règle et la table qu’elle utilise. Reconstruisez ce routage à la main, ou laissez un second outil réécrire les règles, et les paquets marqués peuvent être renvoyés dans le tunnel qu’ils sont censés établir.
La troisième étape est le chemin de retour. Une poignée de main sans réponse n’est pas la preuve d’un rejet sortant ; elle est tout aussi compatible avec une règle d’entrée du serveur ou un appareil NAT qui a oublié la correspondance. Séparez cela avant de toucher au client.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Les clients journalisent le symptôme qu’ils détectent, pas l’étape qui a échoué, donc le tableau est généralement plus rapide que le journal.
Les compteurs décident plus vite que les journaux
Sous Linux, nft list ruleset ou iptables -vnL OUTPUT imprime un compteur de paquets par règle. Connectez-vous une fois, laissez-le échouer, puis relisez les compteurs. Une règle dont le compteur a bougé est une règle que la poignée de main a frappée ; si rien n’a bougé nulle part, le paquet n’a jamais atteint le pare-feu. J’ai vu un jeu de règles rejeter sa propre poignée de main, et seuls les compteurs l’ont dit.
Pour distinguer « jamais atteint le pare-feu » de « jamais quitté l’hôte », observez l’interface elle-même. ip -s link show dev wlan0 signale les paquets envoyés, et tcpdump -ni wlan0 udp port 51820 affiche les trames. S’il reste plat pendant que le client réessaie, la panne se situe au-dessus de netfilter : une route de pair manquante, une règle de politique qui pointe vers un appareil qui n’existe pas encore, ou une erreur de socket que le client avale.
Testez les exceptions avec des adresses de documentation comme 203.0.113.10, pour qu’un oubli ne puisse pas sonder l’hôte de quelqu’un d’autre.
Une exception de point de terminaison obsolète se lit comme une panne de serveur
La version la plus trompeuse apparaît après que l’adresse du pair a changé : un service d’adresses dynamiques l’a déplacée, l’hôte a été reconstruit, ou l’adresse de sortie de votre réseau diffère. L’exception nomme toujours l’ancienne adresse, donc les paquets vers la nouvelle tombent sous la règle de rejet. La même configuration fonctionnait hier, et c’est pourquoi les gens commencent par diagnostiquer le serveur.
Un nom d’hôte dans une règle de pare-feu ne vous sauve pas. Dans nftables, le nom est résolu au chargement du jeu de règles, il épingle donc l’adresse qui existait à ce moment-là et devient obsolète comme une adresse littérale. La solution durable est de mettre l’exception à jour lorsque le point de terminaison change et de la garder étroite : une adresse de pair, un port de transport. Une plage assez large pour survivre à un changement d’adresse l’est aussi pour laisser sortir du trafic sans rapport.
Quand le kill switch tourne sur l’hôte du serveur
La même dépendance existe à l’autre bout, et elle y est plus facile à manquer. Si la machine qui sert de serveur VPN exécute aussi un client de bureau avec kill switch, ou un profil de pare-feu copié d’un ordinateur portable, ses règles de rejet s’appliquent au service qui termine les tunnels. Les réponses à la poignée de main d’un client sont rejetées, donc chaque client échoue à se connecter tandis que le serveur semble sain et que son interface de tunnel reste inutilisée.
Cet hôte a besoin de trois acceptations étroites avant le rejet : le port d’écoute sur l’interface physique, l’interface de tunnel pour le trafic déchiffré, et le transfert depuis le tunnel vers ce que les clients sont censés atteindre. Lisez le jeu installé avec nft list ruleset, iptables -S, ou pfctl -sr , avant de changer quoi que ce soit, et rappelez-vous qu’un jeu de règles enregistré survit à un redémarrage, donc une erreur là-bas survit au processus qui l’a faite.
Ordre de rétablissement qui garde la machine fermée
Travaillez de l’intérieur vers l’extérieur depuis le profil. Lisez l’adresse et le port du pair qu’utilise le client, confirmez que le nom d’hôte se résout sans le tunnel, puis ajoutez une exception pour cette adresse et ce port uniquement sur l’adaptateur physique. Reconnectez-vous et surveillez le compteur d’envoi ; une poignée de main terminée est le signal que la deuxième étape est réparée.
Laissez le reste de la politique de rejet en place pendant les tests. Une vérification inoffensive consiste à tenter une connexion vers une adresse de documentation sans rapport et à confirmer qu’elle expire toujours, ce qui montre que le kill switch fonctionne plutôt qu’il n’est désactivé. Resserrez l’exception une fois le tunnel stable, et ne laissez pas une autorisation permanente de tout pour le binaire du client simplement parce que c’est pratique.
Si le tunnel monte et que l’application échoue encore, les étapes restantes ne sont pas celle-ci : le DNS divisé, le MTU et le routage par application produisent chacun un tunnel connecté avec un trafic cassé, et chacun a une première vérification différente.