Bloquer IPv6 pour verrouiller WireGuard casse l’hôte

L’objectif est raisonnable : seuls les utilisateurs du tunnel devraient atteindre les services de cette machine. La mise en œuvre vers laquelle on se tourne est une chaîne d’entrée IPv6 qui rejette tout sauf WireGuard, et qui rejette donc aussi le trafic qui maintient l’hôte attaché à son propre lien. La découverte de voisins et les messages d’entretien du chemin ne sont pas un accès aux services, et les supprimer produit une machine injoignable pour des raisons sans rapport avec votre politique. Le tunnel monte, les services sont correctement délimités, et rien d’autre sur le lien ne fonctionne.

Trois responsabilités, un jeu de règles

La première responsabilité est l’exploitation du réseau extérieur : l’hôte doit rester attaché à son lien, résoudre les voisins et connaître les limites de chemin de ce lien. La deuxième est l’écouteur chiffré, qui accepte UDP sur l’adresse et le port que vous avez choisis. La troisième est l’ensemble des services déchiffrés que les utilisateurs du tunnel doivent atteindre.

Ce sont trois politiques différentes, et seules la deuxième et la troisième concernent le VPN. Un jeu de règles qui les traite comme une seule hérite d’un mode de défaillance où resserrer la frontière applicative casse silencieusement l’attachement de l’hôte.

Gardez-les dans des chaînes séparées ou au moins des commentaires séparés, afin que la personne suivante voie quelle ligne existe pour quelle raison.

Ce que fait ICMPv6 pour l’hôte

IPv6 s’appuie sur ICMPv6 bien au-delà de l’écho. La sollicitation et l’annonce de voisin remplacent ARP et sont nécessaires à la livraison locale. Packet Too Big transporte l’information de MTU du chemin, et l’ignorer produit des transferts qui calent sur les gros paquets. Les annonces de routeur portent la route par défaut et l’information de préfixe lorsque le lien utilise la configuration automatique.

RFC 4890 sépare les messages qu’un filtre d’hôte doit autoriser de ceux qui relèvent d’un choix administratif, et le fait dans une section hôte distincte des règles d’un routeur qui transfère entre réseaux. Lire seulement la section transfert produit une politique d’entrée trop stricte pour l’hôte qu’elle protège.

La règle pratique est d’autoriser les messages d’erreur et de configuration essentiels sur l’interface qui en a besoin, limités par type et source là où la plateforme le permet, et de prendre une décision explicite pour le reste.

Remplacer tout cela par une autorisation générale d’ICMPv6 résout le problème de disponibilité et abandonne le filtrage. Le remplacer par un rejet général résout le problème de filtrage et abandonne l’hôte.

Admettez le tunnel, puis le service

Acceptez le transport WireGuard sur l’adresse extérieure prévue et le port UDP, et acceptez le trafic de retour via le suivi de connexion. Autorisez ensuite les services applicatifs à travers l’interface du tunnel, depuis les sources que vous autorisez réellement.

Une autorisation pour le port UDP extérieur n’autorise pas les requêtes déchiffrées à l’intérieur. Cette distinction est toute la raison pour laquelle l’interface du tunnel apparaît dans les règles de service.

Lisez le jeu de règles tel qu’il est, pas tel que le fichier le décrit:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

Un écouteur sur une adresse physique est une exposition distincte du même service sur l’adresse du tunnel. Si la machine transfère aussi du trafic vers une autre, c’est une décision de chaîne de transfert et non cette politique d’entrée, et elle demande son propre raisonnement.

Testez le lien, pas seulement le tunnel

Un tunnel qui fonctionne après le changement prouve moins qu’il n’y paraît, car une entrée de voisin existante et une connexion établie peuvent masquer un message de contrôle que la politique rejette désormais.

Vérifiez l’attachement directement, puis vérifiez que le chemin exclu échoue toujours :

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

Une table de voisins qui reste complète après un redémarrage est le signe que la découverte fonctionne encore. Une table qui se vide et ne se remplit jamais est le signe que vous l’avez filtrée. La troisième commande valide la syntaxe du jeu de règles sans l’appliquer, ce qui vaut la peine tant que vous avez encore une session.

Récupérez un hôte dont vous vous êtes exclu

Avant de modifier des règles de pare-feu qui portent votre propre session d’administration, gardez un second canal : une console, une connexion série ou un retour en arrière planifié qui retire les nouvelles règles si vous ne l’annulez pas.

Si un changement vous exclut vraiment, la récupération passe par ce canal et non par le réseau que vous venez de retirer. Restaurez le jeu de règles précédent depuis une copie sauvegardée, confirmez que l’hôte est de nouveau joignable, et seulement alors réappliquez la politique prévue par petits morceaux.

La politique finale n’est pas universelle. L’adressage, le routage et l’implémentation du pare-feu sont des entrées de déploiement, mais la frontière est la même partout : refusez l’accès applicatif non voulu tout en conservant le trafic de contrôle qui porte le tunnel autorisé.