Marques nftables et routage VPN : quelle règle gagne vraiment

Une marque posée dans nftables est censée envoyer une classe de trafic par le tunnel, et le trafic continue de sortir par l’interface physique. Le jeu de règles paraît correct isolément. Ce qui s’est généralement produit, c’est que autre chose a écrit la même marque, ou que la règle de routage correspond à un masque que la nouvelle valeur ne satisfait plus.

Vérification 1 : lisez la règle à laquelle le noyau correspond

Commencez par la règle de politique plutôt que par le pare-feu. Le noyau consulte les règles par ordre de priorité et la première correspondance décide de la table. Lisez la valeur fwmark et le masque dans la règle elle-même, puis confirmez qu’un paquet portant la marque que vous avez posée y correspond réellement. Une règle qui attend une valeur complète sur 32 bits ne correspondra pas à un paquet qui ne porte qu’un seul bit.

Confirmez ensuite quelle table cette règle sélectionne et ce que contient la table. Une règle pointant vers une table vide produit un échec de recherche, ce qui, sur beaucoup de systèmes, signifie que le paquet retombe sur la règle suivante et sort par l’interface physique.

Deux commandes tranchent la question : la liste des règles et la recherche de route pour la destination dans cette table.

Vérification 2 : marque de paquet ou marque de connexion

nftables peut poser une marque sur le paquet et une marque sur l’entrée de suivi des connexions, et ce sont des objets différents. La marque de paquet vit le temps de la passe de traitement du paquet, tandis que la marque de connexion persiste pour le flux et doit être copiée délibérément. Poser l’une et attendre l’autre est un demi-correctif courant.

Si la règle de routage s’appuie sur la marque de paquet, restaurer la marque de connexion plus loin dans le chemin ne change rien à cette décision, car la décision a déjà été prise.

Décidez quel objet détient le signal de routage, puis posez-le au point où la décision de routage est prise.

Vérification 3 : qui d’autre écrit cette marque

Les propres outils de WireGuard marquent leurs paquets UDP pour que le transport chiffré ne soit pas routé vers le tunnel auquel il appartient. Si votre jeu de règles attribue une valeur sans rapport au même champ, cette exclusion disparaît et le trafic extérieur du tunnel tente d’entrer en lui-même. Le symptôme est un tunnel qui s’établit puis cesse de faire passer du trafic.

Les marques servent aussi à d’autres outils de pare-feu, au réseau de conteneurs et au routage par politique à d’autres fins, donc deux sous-systèmes qui écrivent tout le champ sont en conflit même lorsque chacun est correct isolément.

Listez les écrivains avant d’en ajouter un autre.

Vérification 4 : le masque décide de ce que vous gardez

Une marque est un champ de 32 bits, et les masques sont la façon dont plusieurs propriétaires le partagent. Poser une valeur avec un masque préserve les bits qui ne vous appartiennent pas ; poser tout le champ détruit ceux de tous les autres. Lisez le masque dans chaque règle qui touche le champ, y compris celles que vous n’avez pas écrites.

Documentez l’allocation des bits à côté du jeu de règles.

Sinon, la personne suivante réutilisera une valeur qui a déjà un propriétaire, et un conflit ici ressemble à un bug de routage alors qu’il s’agit d’un bug d’adressage. La documentation nftables sur les métadonnées de paquet décrit les opérations de marque elles-mêmes.

Vérification 5 : vérifiez avec un flux réel, pas avec une recherche

Une simple recherche de route ne porte pas de marque, elle peut donc montrer un chemin différent du paquet réel. Générez le trafic qui vous intéresse et observez les compteurs, l’entrée de suivi des connexions et l’interface par laquelle il sort réellement. Testez à la fois la classe incluse et la classe exclue, car une marque trop large casse l’exclusion tout en paraissant réussie. Si la classe incluse fonctionne et que la classe exclue entre aussi dans le tunnel, la marque est trop large et non trop étroite.

Évitez de vider l’état des connexions pour forcer un rafraîchissement pendant une session active, car les flux nouveaux et existants peuvent légitimement emprunter des chemins différents.

Consignez la marque, le masque et la table au même endroit, et la prochaine modification devient vérifiable.