Kill switch sur le routeur qui couvre FORWARD, OUTPUT et IPv6

Vous vous connectez au routeur, collez un jeu de règles de kill switch tiré d’un message de forum, et le LAN cesse de naviguer à l’instant où le tunnel tombe. Deux jours plus tard, le routeur met encore à jour son enregistrement DNS dynamique par le WAN ordinaire, et le portable des invités atteint encore des sites IPv6. Les deux comportements sont normaux, car les règles collées couvraient une chaîne et une famille d’adresses, et ni l’une ni l’autre n’est le routeur entier. Parcourir les chemins des paquets dans l’ordre montre exactement ce qui a été oublié.

Partez du routeur, pas du portable

Une politique au niveau du routeur séduit un petit bureau parce que chaque appareil derrière hérite du même comportement et que personne ne peut oublier d’activer un commutateur côté client. Elle vous donne aussi un seul endroit à tester après chaque mise à jour du firmware. Ce qu’elle ne donne pas, c’est une couverture automatique du trafic propre au routeur ou d’une seconde famille d’adresses, et ce sont les deux lacunes derrière la plupart des déploiements ratés.

Avant de modifier quoi que ce soit, notez trois éléments sur papier : le nom de l’interface WAN, le nom du pont LAN, ainsi que l’adresse et le port du point de terminaison VPN. Vous aurez besoin des trois dans les règles, et deviner les noms d’interface est la raison la plus fréquente pour laquelle un jeu de règles d’apparence correcte ne fait rien.

Parcourez les trois chemins d’un paquet

Le trafic d’un portable vers internet est transféré, il traverse donc la chaîne FORWARD. Le trafic que le routeur génère lui-même, comme le transfert DNS, les requêtes NTP, les mises à jour DDNS et le canal de contrôle du VPN, traverse OUTPUT. Le trafic de gestion adressé au routeur arrive par INPUT.

Un kill switch construit uniquement dans FORWARD protège donc les clients et rien d’autre. Le tableau montre pourquoi la fuite de la scène d’ouverture est prévisible plutôt que mystérieuse.

Dans la plupart des conceptions, vous n’avez pas besoin de kill switch sur INPUT, mais vous devez garder l’accès de gestion fonctionnel pendant que le tunnel est coupé. Sinon, la première fois que le VPN échoue, vous partez au bureau avec un câble console.

Ordonnez les règles pour que le tunnel puisse encore monter

Un kill switch qui fonctionne est une liste d’autorisations qui se termine par un rejet, et c’est l’ordre qui en fait un kill switch plutôt qu’une brique. Autorisez d’abord la boucle locale, le point de terminaison VPN, les réponses des flux établis et l’interface du tunnel ; rejetez le reste en dernier.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

Le point de terminaison doit être une adresse à ce stade, pas un nom d’hôte. Une fois que le rejet final bloque le DNS, une règle qui nomme le nom d’hôte du fournisseur ne peut plus être résolue, et le tunnel ne redémarre plus jamais après un redémarrage. Si le fournisseur fait tourner ses points de terminaison, résolvez le nom avant que la politique soit appliquée et rafraîchissez cette règle depuis le même script.

Reproduisez la même forme dans FORWARD pour le trafic des clients, et placez une règle de gestion explicite au-dessus du rejet. Gardez cette règle de gestion étroite mais joignable, et confirmez-la en ouvrant une seconde session SSH avant de fermer la première. S’enfermer dehors pendant un changement de kill switch est assez courant pour être anticipé. Sur un routeur qui fait tourner WireGuard, les allowed-ips du pair décident de ce qui entre dans le tunnel, tandis que ces règles décident de ce qui peut sortir sans lui.

IPv6 a besoin de sa propre porte

Tout ce qui précède est de l’IPv4. Si votre LAN dispose d’IPv6 fonctionnel et que le tunnel ne transporte que de l’IPv4, chaque appareil couvert garde une route directe vers internet que vos nouvelles règles ne voient jamais. Un portable double pile la préférera volontiers, et le kill switch ne semblera cassé qu’à la personne qui teste en IPv4.

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Ici aussi, l’ordre compte : l’autorisation de la boucle locale doit précéder le rejet du WAN, sinon les services locaux du routeur commencent à échouer étrangement. Si le réseau n’utilise pas du tout IPv6, le désactiver sur le WAN et le LAN est plus simple et ne laisse rien à oublier.

Certains clients VPN n’installent une route par défaut que pour IPv4 et laissent la route par défaut IPv6 existante intacte. Vérifiez la table de routage après la connexion du tunnel au lieu de supposer que le client s’en est chargé.

Prouvez-le tunnel coupé

Arrêtez le tunnel depuis le routeur et testez depuis trois endroits dans cet ordre :

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

La recherche de route vous dit où irait un paquet, et les compteurs vous disent si vos règles ont un jour correspondu. Une règle à zéro paquet après un test raté ne protège rien, et la cause habituelle est un nom d’interface différent de celui que vous avez saisi. Testez explicitement le trafic généré par le routeur, car un test côté LAN ne peut pas exercer OUTPUT.

Décidez du mode de défaillance avant d’en avoir besoin. Fail-closed garde les clients hors ligne jusqu’au retour du tunnel ; fail-open rétablit l’accès WAN ordinaire et ruine l’objectif pour le trafic qui vous importait. Une route blackhole vers le pool VPN avec une métrique élevée est une seconde couche utile pour les conceptions fail-closed, puisqu’elle survit quand la route du tunnel disparaît au lieu de retomber sur la route par défaut.

N’acceptez la configuration que lorsqu’un client du LAN, une requête générée par le routeur et une requête IPv6 échouent toutes tunnel coupé, et que les trois refonctionnent une fois le tunnel monté.