Gardez la politique nftables stable pendant que l'interface VPN arrive

Les tunnels sont jetables ; la politique ne devrait pas l'être. Sur une passerelle Linux, une règle nftables qui fait correspondre l'interface du tunnel par le nom peut être chargée une fois et continuer de s'appliquer chaque fois que cette interface apparaît. L'interface possède malgré tout un cycle de vie : elle est créée, elle disparaît, et les routes et traductions autour d'elle suivent leur propre calendrier. C'est la séparation de ces propriétaires qui garde l'accès stable pendant une reconnexion.

Une correspondance par nom survit à l'interface

nftables propose des correspondances numériques par index d'interface et les correspondances dynamiques par nom iifname et oifname. Les règles qui utilisent ces noms se chargent proprement même lorsque le périphérique du tunnel n'a pas encore été créé, ce qui est exactement ce dont un ensemble de règles a besoin au démarrage. La correspondance cesse si l'interface est renommée et reprend lorsqu'une nouvelle interface prend ce nom. Un index numérique n'a pas cette propriété, c'est pourquoi la forme nominale est le choix habituel pour un tunnel.

Le nom est une clé de correspondance, pas une preuve de qui se trouve à l'autre bout. L'authentification du pair reste le travail du VPN.

Lisez la chaîne avant d'ajouter des règles

Regardez ce que contient actuellement l'ensemble de règles et où se placerait une nouvelle règle, car l'ordre décide du résultat.

nft list ruleset
nft -c -f /etc/nftables.conf

La liste montre les chaînes, les règles et les handles, et le mode de vérification valide un fichier candidat sans le charger. Une autorisation réservée au tunnel placée après une acceptation antérieure pour le même flux ne change rien, car la première règle correspondante l'emporte. C'est pourquoi une règle tardive peut sembler correcte et n'avoir aucun effet. Lisez la chaîne dans l'ordre et confirmez que l'interdiction du trafic du client vers le lien montant précède toujours tout ce qui est plus large.

Les routes, la traduction et les flux ont d'autres propriétaires

La présence de l'interface ne crée aucune route et n'authentifie pas le pair. Cela relève du gestionnaire VPN, tandis que la traduction a un troisième cycle de vie.

conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0

La liste conntrack montre les flux existants avec leurs valeurs d'origine et traduites, et la liste des routes montre ce que le gestionnaire a installé pour l'interface. Les règles NAT établissent l'état de suivi de connexion au premier paquet, ainsi un flux établi conserve sa traduction même après le changement de règle. C'est pourquoi une règle mise à jour et un flux qui emprunte le nouveau chemin sont deux affirmations différentes. Décidez quelles sessions doivent se reconnecter et laissez les flux sans rapport tranquilles.

Acceptez le démarrage à froid, la perte et la reprise

Testez la passerelle avec le tunnel absent au démarrage, puis présent, puis après une coupure et un retour. Confirmez que le transfert interdit reste refusé tant que le tunnel manque, qu'un nouveau flux autorisé fonctionne une fois le pair authentifié et que la reprise n'exige pas de vider un état sans rapport. N'effacez pas toute la chaîne POSTROUTING ni chaque entrée conntrack comme action d'arrêt d'un profil, car d'autres services les partagent. Notez quel composant a changé l'interface, la route et la politique, plutôt que seulement qu'un hook de démarrage s'est terminé par zéro.

Une politique qui survit à une reconnexion est celle dont les propriétaires sont nommés et dont les règles ont été testées avec le tunnel à la fois coupé et actif. Un hook qui signale un succès prouve seulement que le hook s'est exécuté.