Où placer le NAT du VPN dans before.rules d’UFW et comment le tester

Une règle NAT qui fonctionne lorsqu’elle est saisie dans un shell échoue lorsqu’elle est collée dans before.rules, car ce fichier n’est pas un script. C’est un document au format de restauration avec des sections de table, des déclarations de chaîne et un marqueur COMMIT pour chaque table. Une ligne au mauvais endroit soit interrompt toute la restauration, soit supprime silencieusement des règles que vous croyiez présentes. La procédure ci-dessous place le fragment là où le cadre l’attend et prouve le résultat avant le prochain rechargement.

Une commande shell n’est pas un fichier de restauration

Une ligne commençant par iptables -t nat est une instruction destinée au binaire iptables, tandis que le fichier lu par UFW est la description d’un jeu de règles complet. La différence n’est pas cosmétique : le format de restauration doit savoir dans quelle table il se trouve, quelles chaînes existent et où la table se termine. Une commande collée dans ce document est soit une erreur de syntaxe, soit, pire, une règle rattachée à la mauvaise table. Le cadre charge ces fichiers via des outils de restauration précisément parce qu’ils sont déclaratifs et non séquentiels.

Le document est aussi chargé dans son ensemble, si bien qu’une section mal formée peut empêcher l’application du reste du fichier. Une petite erreur dans un fragment NAT entraîne donc les règles de filtrage avec elle, et c’est ainsi qu’un changement de pare-feu devient une panne.

Placez le fragment dans la section de table existante

Un fragment NAT a une forme, et la forme compte plus que le texte de la règle qu’il contient. L’en-tête de table ouvre la section, les déclarations de chaîne établissent les compteurs, les règles suivent et un COMMIT ferme la section.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Le pool et l’interface ci-dessus sont des espaces réservés pour les vôtres ; la structure est la partie qui vaut la peine d’être copiée. Si le fichier contient déjà une section *nat, ajoutez la règle à l’intérieur de cette section plutôt que d’en ouvrir une seconde, car le format attend un COMMIT par table et deux sections pour la même table sont une réparation en attente. Gardez intactes les définitions de chaîne de la distribution, y compris celles que le fournisseur a ajoutées pour sa propre intégration. Le manuel du cadre UFW documente les fichiers before, user et after ainsi que l’exigence d’un COMMIT correspondant.

Si le fichier s’avère vide, ne le remplissez pas à partir d’un tutoriel. Confirmez quel paquet le possède et quelle est réellement la politique active, car un fichier persistant vide ne prouve pas que le noyau ne détient aucune règle, et un jeu de règles chargé ne prouve pas que le prochain rechargement disposera d’un fichier complet à lire. Restaurez d’abord la base prise en charge, puis réappliquez les modifications du site par-dessus.

Testez le candidat sans l’appliquer

L’outil de restauration peut analyser et construire un jeu de règles sans l’appliquer, ce qui est le test le moins coûteux disponible. Exécutez-le sur une copie protégée plutôt que sur le fichier actif, et lisez le texte de l’erreur plutôt que seulement le code de sortie. Un échec d’analyse nomme une ligne et généralement une table, ce qui est plus qu’un rechargement raté ne vous dira.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Réussir ce contrôle prouve que le document s’analyse et rien d’autre. Il ne prouve pas que le candidat contient encore chaque chaîne dont UFW dépend, qu’il n’autorise que les sources prévues ou que l’administration à distance reste joignable. Ce sont des revues distinctes, et la dernière mérite une seconde session ouverte avant de commencer.

Choisissez l’outil correspondant au backend installé et à la famille d’adresses. Un hôte exécutant le backend nft via la couche de compatibilité a besoin de la commande correspondante, et les règles IPv6 vivent dans un fichier entièrement différent.

Gardez le transfert, le NAT et la politique d’accès séparés

La traduction de source résout un problème d’adressage et n’accorde rien. Le transfert est une autorisation distincte contrôlée par un sysctl et par la table de filtrage, et c’est celle que les gens oublient lorsqu’un tunnel route mais ne fait passer aucun trafic. La politique d’accès est une troisième décision sur les sources qui peuvent atteindre quels services, et aucune règle NAT ne l’exprime. C’est le fait de garder les trois séparées qui rend une panne diagnosticable au lieu d’un seul symptôme vague.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Lisez ces trois sorties ensemble plutôt qu’une à la fois. Une règle masquerade avec le transfert désactivé produit un client qui se connecte et n’atteint rien, ce qui, du côté du client, ressemble exactement à une panne de routage et envoie les gens vers le mauvais fichier. La table de filtrage est aussi l’endroit où se cache un accept trop large, alors vérifiez sa politique par défaut pendant que vous y êtes.

Vérifiez un rechargement, un refus et une perte de VPN

Trois observations composent un test d’acceptation complet : le rechargement réussit, une opération client autorisée fonctionne et une requête qui devrait être refusée est réellement refusée. La troisième est celle que l’on saute, et c’est la seule preuve que la politique fait quoi que ce soit.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Testez ensuite la panne pour laquelle vous avez conçu. Coupez le tunnel et observez ce que fait l’hôte, car une politique qui ne fonctionne que tant que le VPN est actif est une politique avec une dépendance non déclarée. Rechargez une fois de plus ensuite pour prouver que c’est le fichier, et non un état d’exécution résiduel, qui produit le résultat fonctionnel.

Le NAT IPv4 ne dit rien d’IPv6, alors indiquez la couverture prévue pour les deux familles dans la même note que la règle. L’objectif est une politique gérée cohérente, et un fragment qui s’est trouvé analysable n’en est pas la preuve.