Si vous administrez des serveurs Linux depuis un moment, vous avez probablement eu cette petite angoisse, un jour, en lisant une doc ou un changelog.
« iptables est legacy ».
« Utilisez nftables ».
« Le backend est maintenant nft ».
Et là, réflexe humain : vous pensez à ce firewall en prod, celui qui tourne depuis des années, avec ses règles un peu… artisanales. Personne n’a envie de « moderniser » un pare-feu et de découvrir après coup que SSH ne répond plus.
Du coup, posons la question clairement : iptables est-il mort ? Non. Mais il a changé de statut. Et surtout, migrer vers nftables est devenu la trajectoire normale sur la plupart des distributions récentes.
Dans cet article, on va faire un truc simple : comprendre où on en est, comment éviter de casser l’existant, et comment migrer proprement. Sans dogme. Sans coupure.
pourquoi on dit que iptables est « mort »… alors qu’il tourne encore partout
iptables, historiquement, c’est l’interface utilisateur pour piloter Netfilter dans le noyau Linux. Ça a dominé le monde SysAdmin pendant longtemps.
Puis nftables est arrivé. Et ce n’est pas juste « un nouvel iptables ». C’est une refonte :
- un langage plus cohérent
- des structures de données plus efficaces (sets, maps, concatenations)
- moins de duplication entre iptables, ip6tables, arptables, ebtables
- une meilleure évolutivité (performance et lisibilité)
Le point important : sur beaucoup de systèmes, quand vous tapez iptables, vous n’utilisez déjà plus le vieux moteur.
Cependant, la transition vers nftables peut sembler intimidante. Il est donc essentiel de bien diagnostiquer votre système actuel avant d'effectuer des changements majeurs. Pour cela, je vous recommande de consulter cet article sur diagnostiquer un système avec systemd, qui pourrait vous fournir des informations précieuses pour rendre cette migration aussi fluide que possible.
iptables-legacy vs iptables-nft, la vraie source de confusion
Aujourd’hui, iptables existe souvent en deux variantes :
- iptables-legacy : l’ancien backend « xtables »
- iptables-nft : une couche de compatibilité qui traduit vos règles iptables en règles nftables
Vous pouvez vérifier ce que votre machine utilise :
bash iptables --version update-alternatives --display iptables 2>/dev/null || true
Sur Debian/Ubuntu, vous verrez souvent un truc du style : iptables v1.8.x (nf_tables).
Traduction : vous écrivez encore du iptables, mais c’est nftables qui exécute.
Donc non, iptables n’est pas mort. Mais dans l’écosystème Linux moderne, il est clairement en mode « compat ».
nftables, en deux minutes, pour ceux qui n’ont jamais accroché
nftables, c’est :
- un outil en ligne de commande :
nft - un fichier de configuration principal souvent :
/etc/nftables.conf - des concepts simples : tables, chains, rules, avec des hooks (
input,forward,output), et des priorités
Exemple minimaliste, juste pour visualiser :
nft table inet filter { chain input { type filter hook input priority 0; policy drop;
iif lo accept
ct state established,related accept
tcp dport 22 accept
} }
Déjà, vous voyez le truc : c’est plus « langage » que « commandes à la chaîne ».
la question qui compte : dois-je migrer maintenant
Dans la vraie vie, il y a trois cas.
cas 1 : votre distribution est récente et iptables utilise déjà nf_tables
Vous êtes probablement déjà « semi migré ». Le risque : accumuler des règles et des scripts iptables qui deviennent difficiles à comprendre quand on commence à toucher à nftables.
cas 2 : vous êtes encore en iptables-legacy (ou vous ne savez pas)
Là, oui, vous allez être confronté à une migration tôt ou tard, surtout si vous maintenez des images, des playbooks, des guides internes.
cas 3 : vous avez un firewall simple, stable, et personne n’y touche
Vous pouvez temporiser. Mais je dirais quand même : documentez, testez, préparez. Le jour où vous devrez faire un changement en urgence, vous serez content d’avoir un plan.
avant de migrer : la checklist anti casse (vraiment utile)
On évite 90 % des drames avec 7 actions très basiques.
- avoir une console hors bande si possible (IPMI, iDRAC, console cloud).
- avoir une session root persistante (
tmux,screen) avant de toucher au firewall. - sauvegarder l’état actuel des règles iptables.
- connaître l’init système (systemd, scripts maison, Docker, kube, etc.).
- identifier qui gère le firewall : vous, UFW, firewalld, un agent, un playbook, un panel.
- prévoir un rollback simple.
- tester sur une VM ou un serveur clone si possible.
Sauvegarde iptables :
bash iptables-save > /root/iptables-save.backup ip6tables-save > /root/ip6tables-save.backup
Inventaire nftables actuel (même si vous ne l’utilisez pas officiellement) :
bash nft list ruleset > /root/nft-ruleset.before
attention aux outils qui « cachent » le firewall
Petit rappel, parce que c’est là que beaucoup de migrations partent en vrille :
- UFW (Ubuntu) pilote iptables (souvent via iptables-nft).
- firewalld (Fedora, RHEL) utilise nftables en backend sur pas mal de versions récentes.
- Docker ajoute des règles (NAT, FORWARD) automatiquement.
- Kubernetes et certains CNI manipulent iptables.
- Fail2ban peut écrire en iptables ou nftables selon configuration.
Donc, avant de migrer, posez-vous une question simple : qui écrit des règles, à part vous ?
stratégie de migration : la voie la plus sûre en production
Il y a plusieurs approches. Celle que je recommande pour « sans casser » : migrer progressivement en gardant un filet.
étape 1 : vérifier si iptables est déjà traduit en nft
Si vous voyez (nf_tables) dans iptables --version, vous pouvez déjà inspecter le résultat côté nft :
bash nft list ruleset | less
Vous verrez des tables/chaînes qui ressemblent à de l’auto généré. C’est normal.
L’idée ici, ce n’est pas de tout réécrire tout de suite. C’est juste de constater : votre trafic passe déjà par nftables, via compat.
étape 2 : écrire une configuration nftables « propre » en parallèle
Créez un fichier de travail, par exemple :
/root/nftables.new.conf
Puis construisez les règles essentielles :
- loopback
- established, related
- SSH
- éventuellement HTTP/HTTPS
- ICMP (au moins un minimum)
- règles de log raisonnables
Exemple « serveur web classique » :
nft flush ruleset
table inet filter { chain input { type filter hook input priority 0; policy drop;
iif lo accept
ct state established,related accept
ip protocol icmp accept
ip6 nexthdr icmpv6 accept
tcp dport 22 accept
tcp dport { 80, 443 } accept
counter log prefix "nft drop input: " flags all drop
}
chain forward { type filter hook forward priority 0; policy drop; }
chain output { type filter hook output priority 0; policy accept; } }
Oui, c’est volontairement simple. En prod, on affine. Mais c’est une base sûre.
étape 3 : tester la conf nftables sans l’appliquer définitivement
Test syntaxique :
bash nft -c -f /root/nftables.new.conf
Application temporaire (attention, ça remplace tout si vous faites flush ruleset) :
Je conseille de faire ça seulement si vous avez une console de secours. Sinon, utilisez une fenêtre de rollback.
la technique « rollback automatique » (très pratique)
Dans une session, vous planifiez un retour arrière dans 60 secondes :
bash ( sleep 60; nft -f /root/nftables.old.conf ) &
Dans l’autre session, vous appliquez la nouvelle conf. Si tout va bien, vous tuez le job de rollback.
Ça sauve des vies. Vraiment.
étape 4 : activer nftables au boot, proprement
Sur Debian/Ubuntu, souvent :
bash apt install nftables systemctl enable --now nftables
Et mettre votre conf dans :
/etc/nftables.conf
Puis :
bash nft -f /etc/nftables.conf nft list ruleset
convertir automatiquement iptables vers nftables : utile, mais pas magique
Il existe iptables-translate et iptables-restore-translate.
Exemple :
bash iptables-save | iptables-restore-translate > /root/translated.nft
Ça peut vous donner une base. Mais vous allez souvent obtenir :
- des noms de chaînes peu lisibles
- des règles très verbeuses
- des choses difficiles à maintenir
Mon avis : oui pour s’aider, non pour considérer ça comme une migration « finie ».
points qui cassent souvent quand on migre
le NAT et les redirections de ports
En nftables, le NAT se fait via une table ip nat ou inet selon choix, avec chaînes prerouting, postrouting, etc.
Exemple DNAT (rediriger 80 vers 8080 en local) :
nft table ip nat { chain prerouting { type nat hook prerouting priority -100; tcp dport 80 redirect to :8080 } }
Exemple masquerade (sortie WAN) :
nft table ip nat { chain postrouting { type nat hook postrouting priority 100; oifname "eth0" masquerade } }
le comportement de FORWARD avec Docker
Docker adore iptables. Si vous passez en nftables natif, il faut vérifier la compatibilité sur votre version, et surtout vérifier ce que Docker installe comme règles.
Dans les environnements sensibles, le plus simple est parfois de :
- laisser Docker gérer ses règles via compat
- gérer votre filtrage principal dans nftables, mais en comprenant le chemin réseau
Oui, ça demande un peu de lecture de nft list ruleset. Pas le choix.
iptables et nftables en même temps, le piège
Vous pouvez vous retrouver avec :
- des règles nftables que vous écrivez
- des règles « iptables-nft » générées par compat
- des services qui ajoutent des règles « en douce »
Résultat : vous pensez avoir ouvert un port, mais il est toujours bloqué, parce qu’une policy drop ailleurs s’applique avant, ou parce que ce n’est pas le bon hook.
Règle d’or : un responsable principal. Si vous migrez, choisissez qui est maître.
une migration « douce » typique pour un serveur SSH + web
Je vous donne un scénario réaliste, simple.
- Vous exportez vos règles iptables.
- Vous installez nftables et vous écrivez une conf minimaliste.
- Vous testez en console.
- Vous activez au boot.
- Vous laissez iptables installé, mais vous évitez de l’utiliser ensuite.
Et surtout, vous mettez en place une petite routine :
bash nft list ruleset > /root/nft-ruleset.$(date +%F).txt
Ça aide énormément quand vous devez comprendre « qu’est-ce qui a changé ».
images utiles pour visualiser et se rassurer
Quelques ressources visuelles à garder sous la main.
Ces schémas aident surtout à replacer où se joue input vs forward, et où s’accroche le NAT.
mini guide de commandes nftables (celles qu’on utilise vraiment)
Lister :
bash nft list ruleset
Lister une table :
bash nft list table inet filter
Appliquer un fichier :
bash nft -f /etc/nftables.conf
Tester la syntaxe :
bash nft -c -f /etc/nftables.conf
Voir les compteurs (si vous avez counter) :
bash nft list ruleset -a
ok, alors iptables est-il mort
Non. Mais si on parle « trajectoire » Linux :
- nftables est le présent et le futur
- iptables est encore là, souvent comme compat, parfois comme habitude, parfois parce que tout un écosystème d’outils l’utilise encore
Le bon move, ce n’est pas de supprimer iptables en mode héroïque. Le bon move, c’est de migrer quand vous pouvez le faire proprement, avec tests, et une config lisible.
Si vous aimez ce genre d’articles SysAdmin un peu concrets (et pas juste des copier coller), vous pouvez jeter un oeil au reste de mes contenus sur Le Blog Tech Pro de Samyn-Antoy ABASSE : https://monblog-sa-abasse.blogspot.com
J’y mélange volontairement Linux, productivité, et business en ligne. Parce qu’en vrai, c’est la même vie. On admin, on optimise, on évite la casse.
checklist finale (à copier dans votre doc interne)
iptables-saveetnft list rulesetsauvegardés- console de secours disponible
- conf nftables minimale prête (SSH, established, loopback)
- test
nft -c -f …ok - fenêtre rollback planifiée
- activation au boot vérifiée
- outils tiers identifiés (Docker, fail2ban, firewalld, UFW)
C’est tout. Enfin non, ce n’est pas tout, mais si vous faites ça, vous êtes déjà dans le top 10 % des migrations firewall qui se passent bien.
Questions fréquemment posées
Pourquoi dit-on que iptables est "mort" alors qu'il fonctionne encore sur de nombreux systèmes ?
iptables est considéré comme "legacy" car il a été remplacé progressivement par nftables, une refonte plus moderne et efficace. Cependant, iptables continue de fonctionner, souvent via un backend nftables qui interprète les règles iptables. Ainsi, iptables n'est pas mort, mais son rôle a changé vers une compatibilité avec nftables.
Quelle est la différence entre iptables-legacy et iptables-nft ?
iptables-legacy est l'ancien moteur basé sur xtables, tandis qu'iptables-nft est une couche de compatibilité qui traduit les commandes iptables en règles nftables. Sur les distributions récentes, iptables utilise souvent le backend nft (iptables-nft), permettant d'écrire en syntaxe iptables tout en profitant des avantages de nftables.
Qu'est-ce que nftables et quels sont ses avantages par rapport à iptables ?
nftables est un outil moderne pour gérer le firewall Linux via Netfilter. Il propose un langage plus cohérent, des structures de données efficaces (sets, maps), réduit la duplication entre différents types de règles (ip4, ip6, arp), et offre une meilleure performance et lisibilité. Il s'utilise avec la commande 'nft' et un fichier de configuration principal souvent situé à /etc/nftables.conf.
Dois-je migrer immédiatement mes règles iptables vers nftables ?
Cela dépend : si votre distribution utilise déjà le backend nft pour iptables, vous êtes partiellement migré. Si vous utilisez encore iptables-legacy ou ne savez pas, une migration sera nécessaire tôt ou tard. Si votre firewall est simple et stable sans modifications fréquentes, vous pouvez temporiser mais il est conseillé de documenter et préparer la migration pour éviter des problèmes futurs.
Comment éviter de casser mon firewall lors d'une migration vers nftables ?
Avant toute migration, il est crucial d'avoir une console hors bande pour récupérer l'accès en cas de problème. Il faut également diagnostiquer son système actuel, sauvegarder les configurations existantes, tester les nouvelles règles dans un environnement contrôlé et progresser sans dogme ni coupure brutale afin d'assurer une transition fluide.
Comment vérifier quelle version d'iptables utilise ma machine ?
Vous pouvez exécuter la commande 'iptables --version' pour voir si elle indique '(nf_tables)' ce qui signifie que le backend nft est utilisé. Sur Debian/Ubuntu, 'update-alternatives --display iptables' peut aussi indiquer si c'est la version legacy ou nft qui est active.
0 Commentaires