nftables : insérer la règle d’autorisation VPN avant le handle de rejet

Placez une règle d’autorisation au mauvais endroit et elle se comporte comme si aucune règle n’existait. Dans nftables, le choix entre insert et add décide du côté d’une règle référencée où atterrit la nouvelle instruction, et un handle nomme la règle dans le jeu de règles actif plutôt que son numéro de ligne. Si le placement est faux, le paquet atteint d’abord le rejet.

La comparaison ci-dessous utilise un pair fixe et un échange d’écouteur externe. Elle est volontairement étroite ; remplacer une chaîne entière est un autre changement, avec un autre profil de risque.

Deux placements, deux résultats différents

insert place une règle avant la règle référencée. add la place après. Si la règle référencée est le rejet terminal du flux, ces deux commandes produisent des résultats opposés même quand le texte de la règle est identique.

Omettre un emplacement a son propre comportement par défaut, ce qui est une raison de plus de ne pas copier une commande d’un forum sans lire ce à quoi elle est ancrée. L’ancre est toute la décision. Notez le côté voulu avant de taper la commande. insert et add ne diffèrent que d’un mot dans le fichier.

Le placement est relatif à une règle dans une chaîne donnée. Déplacer la même instruction vers une autre chaîne ou une autre priorité de hook change les paquets qu’elle voit, même lorsque la syntaxe de la règle paraît correcte.

Un handle identifie une règle, pas un numéro de ligne

Un handle comme 42 est un identifiant dans l’état actuel du jeu de règles. Ce n’est pas la quarante-deuxième règle, et il n’est pas stable d’un hôte à l’autre, d’une reconstruction à l’autre ou face à un gestionnaire qui recharge sa configuration.

Localisez la chaîne et le rejet terminal réel avant de choisir l’ancre. Confirmez ensuite le handle sur cette règle dans la même liste qui montre le rejet, afin que le numéro et la règle se lisent ensemble. Un handle lu dans une ancienne liste peut déjà appartenir à une autre règle. Relisez-le dans la session qui appliquera le changement.

iptables --version
nft -a list ruleset

La version d’iptables indique quel backend est utilisé. Un jeu de règles iptables-nft et une table native gérée indépendamment peuvent coexister, donc une liste issue d’un seul frontal n’est pas automatiquement l’image complète du filtrage. Vérifiez les deux vues avant de choisir une chaîne.

Trouvez la chaîne et la règle qui rejette réellement

Lisez le hook d’entrée, la priorité de la chaîne et la règle qui refuse ce flux d’écouteur. Une table inet peut porter les deux familles d’adresses, mais une règle individuelle peut encore ne correspondre qu’à IPv4.

Prenez un pair approuvé, en utilisant 198.51.100.25 de la plage de documentation comme exemple. Un fichier natif relu pourrait placer une autorisation externe avant le handle 42 :

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

Remplacez la famille, la table, la chaîne, le handle, l’interface d’entrée et le pair après inspection. L’exemple utilise la forme de placement par handle documentée pour nft 1.0.9, et elle appartient à un fichier d’entrée ; le guillemet des accolades est une question distincte lorsque la commande est tapée en interactif.

Gardez le propriétaire de la configuration clair. Un gestionnaire qui reconstruit ses règles peut écraser une modification à chaud, et un script de démarrage qui code en dur un handle obsolète échouera ou s’accrochera à la mauvaise règle.

L’acceptation est délimitée, le rejet est terminal

Un verdict d’acceptation termine l’évaluation sur son chemin actuel, mais une chaîne de base applicable plus tard peut encore rejeter le paquet. Un verdict de rejet est terminal. C’est pourquoi un compteur d’acceptations croissant ne prouve pas que le flux a réussi.

Inspectez toutes les priorités de hook pertinentes plutôt qu’une chaîne isolée. Un paquet peut passer un filtre d’entrée et être malgré tout refusé par le hook d’une autre table à une priorité différente. Listez chaque chaîne de base qui peut voir le flux.

Cette règle ne couvre que l’échange d’écouteur externe. L’ESP encapsulé en transport, l’ESP natif, les pairs IPv6 et le trafic déchiffré à l’intérieur du tunnel ont tous besoin de leurs propres politiques. Ce n’est pas un pare-feu VPN de site complet.

Vérifiez le fichier, puis validez le résultat en direct

Lancez une vérification de syntaxe et de transaction sur le fichier relu avant de l’appliquer. Le mode vérification indique si nft peut analyser et préparer le changement ; il ne l’applique pas et ne prouve pas qu’un autre hook autorisera le paquet. Le fichier reste une proposition tant que le propriétaire ne l’a pas appliqué :

nft -c -f reviewed-vpn-rule.nft

Appliquez via le processus contrôlé du propriétaire et préservez l’accès de secours. Si la règle est fausse, le rejet que vous cherchiez à précéder peut aussi couper le chemin que vous utilisez pour la corriger.

Après le changement, observez une nouvelle tentative de pair autorisé et vérifiez que les sources hors du pair approuvé sont toujours refusées. Déplacez la règle durable vers le gestionnaire qui possède le jeu de règles, car les handles à chaud localisent les objets courants au lieu de les identifier d’un démarrage à l’autre.