Manuel iptables : les bases pour comprendre et configurer le pare-feu

Meta description : Comprendre iptables et apprendre à configurer un pare-feu Linux efficace : règles de filtrage, tables, chaînes, NAT et exemples concrets pour sécuriser vos serveurs.

En bref 👇

• 🧱 Iptables est le pare-feu logiciel historique intégré à Linux, basé sur le moteur netfilter.
• 🔐 Il permet un packet filtering très fin pour renforcer la sécurité réseau des serveurs et postes de travail.
• 🧬 Le fonctionnement repose sur des tables et des chaînes (INPUT, OUTPUT, FORWARD, etc.) qui évaluent chaque paquet.
• ⚙️ La bonne configuration consiste à définir des règles de filtrage claires, testées et documentées.
• 🌐 Iptables gère aussi le NAT pour partager une connexion ou masquer un réseau interne derrière une seule IP publique.
• 💾 Sans sauvegarde, les règles du firewall disparaissent au redémarrage : la persistance est indispensable en production.
• 🚀 Même si nftables progresse, maîtriser iptables reste stratégique pour tout administrateur Linux en 2026.

Sur un serveur Linux exposé à Internet, la frontière entre un système robuste et une machine compromise se joue souvent au niveau du pare-feu. Iptables, intégré au noyau via netfilter, reste l’outil incontournable pour contrôler finement chaque paquet entrant, sortant ou simplement relayé.

Pourtant, pour beaucoup d’administrateurs, cet outil impressionne par sa syntaxe dense et son vocabulaire technique. La bonne nouvelle, c’est qu’une fois les concepts de base compris, iptables devient un allié très prévisible, presque “mathématique” dans son comportement, idéal pour bâtir une sécurité réseau fiable.

Pour suivre le fil, imaginons une petite entreprise fictive, DataNova, qui héberge un site web, un VPN et quelques services internes sur Linux. L’équipe IT a besoin d’un firewall simple à auditer, capable de bloquer les attaques basiques (scans de ports, tentatives SSH par force brute) sans compliquer la vie des utilisateurs.

À travers les exemples, les commandes et les bonnes pratiques, le parcours de DataNova servira de fil conducteur : de la découverte des tables et chaînes jusqu’à la mise en place d’un filtrage adapté à un environnement réel. Chaque partie apportera une brique : compréhension de l’architecture, maîtrise des commandes essentielles, cas pratiques pour un serveur web, gestion de la persistance, puis ouverture vers les approches plus modernes.

Comprendre iptables et le rôle du pare-feu Linux dans la sécurité réseau

Avant d’écrire une seule règle, il est essentiel de saisir ce qu’est réellement iptables. Il ne s’agit pas d’un programme isolé, mais d’une interface en ligne de commande qui permet de piloter le système de filtrage de paquets du noyau Linux, appelé netfilter.

Concrètement, netfilter voit défiler tous les paquets IP, et iptables vient lui dire quoi faire : accepter, rejeter, réécrire, journaliser, rediriger.

Dans un monde où chaque serveur est potentiellement scanné en quelques minutes après sa mise en ligne, disposer d’un pare-feu configurable au niveau du noyau est un avantage considérable. Contrairement à une simple protection applicative (par exemple dans un serveur web), le filtrage de paquets intervient en amont, dès que les données touchent la pile réseau.

Ce packet filtering précoce permet de bloquer toute une classe d’attaques avant même qu’elles n’atteignent les services vulnérables.

Pourquoi iptables reste stratégique malgré les alternatives

Depuis quelques années, nftables est présenté comme le successeur officiel d’iptables. Il propose une syntaxe plus moderne, une gestion des ensembles plus flexible et une meilleure performance dans certains contextes. De nombreuses distributions l’utilisent désormais en coulisse, parfois via des couches de compatibilité.

Pourtant, dans les environnements d’entreprise, iptables reste omniprésent. De nombreuses documentations internes, scripts d’initialisation et playbooks d’outillage (Ansible, Puppet) continuent à parler en termes de tables, chaînes et règles iptables.

C’est le cas de DataNova, dont l’infrastructure historique repose sur une série de scripts iptables éprouvés. Savoir les lire, les adapter et les sécuriser est un prérequis pour garantir la continuité de service sans réécriture complète de l’architecture.

Cette persistance s’explique aussi par un argument pédagogique : iptables est une excellente porte d’entrée pour comprendre les mécanismes fondamentaux d’un firewall réseau. Une fois ces notions assimilées, passer à nftables ou à un gestionnaire de haut niveau comme firewalld devient nettement plus simple.

Le rôle concret du packet filtering dans un environnement réel

Revenons à DataNova. Son serveur principal héberge plusieurs services : un site web public sur les ports 80/443, un accès SSH sur le port 22, un serveur de base de données uniquement accessible en interne. Sans règles de filtrage, tous ces ports seraient potentiellement exposés, y compris ceux utilisés ponctuellement pour des tests ou des outils internes.

En définissant une configuration iptables claire, l’équipe peut limiter drastiquement la surface d’attaque :

• 🛡️ Bloquer tout le trafic entrant par défaut et n’ouvrir que les ports nécessaires.
• 🚫 Refuser toute connexion directe depuis Internet vers la base de données.
• 📊 Journaliser les paquets suspects pour analyser les tentatives d’intrusion.
• ⏱️ Appliquer des limites de connexion SSH pour réduire l’impact des attaques par force brute.

Le résultat est immédiat sur le plan métier : moins de risque d’indisponibilité, de fuite de données et de compromission, donc une continuité d’activité renforcée. Pour une structure comme DataNova, où chaque heure d’arrêt du site représente une perte de chiffre d’affaires, cette couche de sécurité réseau n’est pas un luxe mais une nécessité.

En filigrane, iptables agit comme un contrat entre le système et le réseau : ce qui n’est pas explicitement autorisé est refusé. C’est ce principe, la politique de sécurité par défaut, qui sera décliné dans les sections suivantes.

Architecture iptables : tables, chaînes et règles expliquées simplement

Pour configurer efficacement un firewall Linux, il faut comprendre comment iptables structure la décision de filtrage. L’outil s’appuie sur trois concepts principaux : les tables, les chaînes et les règles de filtrage. Chaque paquet traverse plusieurs étapes où des décisions peuvent être prises.

Les principales tables iptables et leur usage

Une table regroupe des règles ayant un objectif commun. Les plus courantes sont :

• 🧱 filter : table par défaut, dédiée au filtrage classique (autoriser ou bloquer).
• 🔁 nat : utilisée pour la translation d’adresses réseau (NAT), par exemple pour partager une IP publique.
• 🎛️ mangle : permet de modifier certains champs des paquets (TTL, marquage, etc.).
• 🧬 raw : intervient très tôt pour gérer des aspects comme le suivi de connexion.
• 🛡️ security : utilisée avec des mécanismes comme SELinux pour marquer les paquets.

Dans la plupart des déploiements, dont celui de DataNova, l’essentiel se joue dans les tables filter et nat. La première décide si un paquet est autorisé ou pas. La seconde s’occupe d’éventuelles réécritures d’adresses ou de ports pour publier plusieurs machines derrière une seule IP.

Table 🧩	Rôle principal 🎯	Exemple d’usage concret 💼
filter	Filtrage classique des paquets	Autoriser HTTP/HTTPS, bloquer tout le reste vers un serveur web
nat	Translation d’adresses (NAT)	Partager une IP publique pour tout un réseau interne
mangle	Modification avancée des paquets	Marquer un flux pour de la QoS sur une liaison saturée
raw	Gestion fine du suivi de connexion	Exclure certains paquets du suivi de connexion netfilter
security	Marquage de sécurité (SELinux…)	Associer des contextes de sécurité à des flux sensibles

Les chaînes : les points de décision sur le trajet du paquet

Une chaîne représente un point précis du parcours d’un paquet dans la pile réseau. Dans la table filter, les chaînes les plus importantes sont :

• 📥 INPUT : paquets destinés à la machine locale.
• 📤 OUTPUT : paquets émis par la machine locale.
• 🚚 FORWARD : paquets traversant la machine (rôle de routeur).

Pour la table nat, d’autres chaînes clés entrent en jeu :

• 🧭 PREROUTING : avant la décision de routage, pratique pour la redirection (DNAT).
• 🛣️ POSTROUTING : après le routage, idéal pour masquer les adresses (SNAT/MASQUERADE).

Chaque paquet va passer par une séquence de chaînes dépendant de son type (entrant, sortant, routé). À chaque passage, les règles sont évaluées dans l’ordre. Dès qu’une règle correspond et donne une action finale (ACCEPT, DROP, REJECT…), le traitement s’arrête pour cette chaîne.

Les règles : association de critères et d’actions

Une règle iptables combine deux éléments :

• 🎯 Un composant de correspondance : critères qui définissent le trafic visé (protocole, IP source, port, interface…).
• ⚡ Un composant cible : l’action à effectuer lorsque les critères sont remplis.

Par exemple :

Exemple : iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Cette commande ajoute une règle à la chaîne INPUT pour accepter les connexions TCP destinées au port 22 (SSH). Les correspondances (-p tcp, –dport 22) définissent ce qui est visé, la cible (-j ACCEPT) indique que ces paquets doivent être autorisés.

Dans un script pour DataNova, une série de règles comparables va façonner le comportement du pare-feu : d’abord une politique stricte (DROP par défaut), puis des ouvertures précises pour chaque service légitime. La clarté de ces règles facilite les audits de sécurité, ce qui est crucial lors de contrôles ou de certifications.

Cette vision en trois couches, tables, chaînes, règles, fournit une carte mentale solide. La suite montrera comment la transformer en commandes utilisables au quotidien.

Commandes de base iptables : syntaxe, options et premiers pas

La syntaxe générale d’iptables peut sembler intimidante, mais elle suit une logique constante. Une commande typique se présente ainsi :

iptables -t <table> <option-chaîne> <chaîne> [conditions] -j <action>

Si aucune table n’est précisée avec -t, iptables utilise par défaut la table filter. C’est le cas le plus courant lorsqu’on met simplement en place des règles de filtrage pour un pare-feu classique.

Les options de gestion des chaînes les plus utiles

Pour manipuler les règles dans une chaîne, plusieurs options reviennent tout le temps :

• ➕ -A : ajouter une règle à la fin de la chaîne (append).
• 🧩 -I : insérer une règle à une position précise (insert).
• 🧪 -C : vérifier si une règle existe déjà (check).
• 🗑️ -D : supprimer une règle (delete).
• 🧹 -F : vider toutes les règles d’une chaîne (flush).
• 📜 -L : lister les règles en vigueur.
• 📏 -P : définir la politique par défaut d’une chaîne (ACCEPT ou DROP, par exemple).

Pour DataNova, le premier réflexe de l’équipe IT consiste à lister ce qui tourne déjà sur une machine fraîchement installée :

sudo iptables -L -v

L’option -v affiche des détails supplémentaires (compteurs de paquets, octets…). C’est un excellent moyen de repérer les flux vraiment utilisés avant de durcir la politique de sécurité.

Filtres courants : protocoles, ports et adresses IP

Les “conditions” d’une règle iptables permettent d’identifier précisément le trafic :

• 📡 -p : le protocole (tcp, udp, icmp…).
• 🌍 -s : adresse IP source (ou plage).
• 🎯 -d : adresse IP de destination.
• 🔌 –sport : port source (pour TCP/UDP).
• 🔒 –dport : port de destination.
• 🔀 -i / -o : interface d’entrée ou de sortie (eth0, ens3, etc.).

Un exemple typique chez DataNova pour autoriser le HTTPS vers le serveur :

sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Pour bloquer le HTTP non sécurisé (port 80) tout en laissant le HTTPS disponible :

sudo iptables -A INPUT -p tcp --dport 80 -j REJECT

Ces deux règles traduisent une décision métier : toutes les connexions clients doivent utiliser un canal chiffré, afin de protéger les données et d’inspirer confiance aux visiteurs. L’impact marketing est réel : un site uniquement en HTTPS renforce la crédibilité de la marque et améliore souvent le référencement.

Actions possibles : que faire des paquets correspondants ?

Les cibles les plus fréquentes sont :

• ✅ ACCEPT : le paquet est autorisé à continuer son chemin.
• 🛑 DROP : le paquet est silencieusement jeté, l’émetteur ne reçoit pas de réponse.
• 🚫 REJECT : le paquet est refusé, avec une réponse explicite envoyée à la source.
• ↩️ RETURN : sort d’une chaîne utilisateur pour revenir à la chaîne appelante.

Dans certains cas, DROP est préférable (ne rien révéler), dans d’autres, REJECT évite de faire attendre inutilement une application cliente. Pour DataNova, les scans de ports non autorisés sont généralement traités par un DROP, tandis que certains services internes peuvent renvoyer un REJECT pour accélérer les diagnostics.

La maîtrise de cette syntaxe de base ouvre la porte à des configurations plus élaborées. La prochaine étape consiste à construire un jeu de règles cohérent pour un serveur web exposé à Internet.

Cette ressource vidéo peut compléter utilement la prise en main des commandes vues ici.

Mettre en place un pare-feu iptables pour un serveur web : cas pratique

Pour donner du concret, prenons le cas du serveur principal de DataNova, hébergé sous Linux. Il fournit un site web public, un accès SSH pour l’administration et rien d’autre aux visiteurs externes. L’objectif est de bâtir une configuration iptables qui reflète le principe : “tout est interdit, sauf ce qui est explicitement nécessaire”.

Définir les politiques par défaut : la base de la sécurité réseau

La première étape consiste à fixer une politique par défaut stricte sur la table filter :


sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT


Ici, toutes les connexions entrantes et transitantes (FORWARD) sont refusées si aucune règle spécifique ne les autorise. Le trafic sortant reste libre, ce qui est acceptable pour un serveur d’applications classique. Cette approche réduit fortement la surface d’attaque et clarifie le fonctionnement : ce qui n’est pas listé est bloqué.

Autoriser les ports indispensables : SSH, HTTP, HTTPS

Le serveur doit rester administrable à distance et accessible en HTTP/HTTPS. L’équipe ajoute donc quelques règles ciblées :


sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT


La première règle autorise les connexions déjà établies, ce qui évite de bloquer les réponses aux requêtes que le serveur a lui-même initiées. Les règles suivantes ouvrent les ports 22, 80 et 443. DataNova pourra ensuite décider de progressivement rediriger tout le trafic HTTP vers HTTPS côté application, tout en conservant la flexibilité de laisser le port 80 ouvert pour des redirections propres.

Contrôler l’accès SSH pour limiter les risques

Les attaques par force brute sur SSH sont devenues monnaie courante. Même un simple VPS reçoit chaque jour des centaines de tentatives de connexion. Pour atténuer ce risque, DataNova décide de limiter les connexions SSH en nombre et, si possible, à une plage d’adresses de confiance.

Une première mesure simple consiste à accepter uniquement une IP d’administration fixe :

sudo iptables -A INPUT -p tcp --dport 22 -s 203.0.113.10 -j ACCEPT

En complément, un module comme recent ou un outil comme Fail2ban peut être combiné pour bannir automatiquement les IP qui tentent trop de connexions. L’impact métier est significatif : réduction du risque de compromission des comptes administrateurs, moins de temps passé à surveiller les logs, et une sérénité accrue pour l’équipe technique.

Journaliser les paquets rejetés sans saturer les logs

Pour améliorer la visibilité, DataNova active la journalisation sur certaines catégories de paquets rejetés :


sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables-input-drop: " --log-level 4
sudo iptables -A INPUT -j DROP


La combinaison du module limit et de l’action LOG permet de ne pas saturer les fichiers journaux tout en gardant un aperçu des tentatives d’accès non autorisées. Ces informations alimentent ensuite les rapports de sécurité et les revues d’incidents.

Avec ce cas pratique, la logique générale est claire : partir d’une politique de blocage, ouvrir seulement ce qui est nécessaire, renforcer les services sensibles et instrumenter la visibilité. La suite va explorer la dimension NAT et routage, indispensable pour les passerelles et pare-feux d’entreprise.

Une vidéo ciblée sur NAT et FORWARD peut aider à compléter cette mise en œuvre pratique.

NAT, routage et iptables : utiliser les tables nat et mangle

Au-delà du simple filtrage d’un serveur isolé, iptables prend tout son sens lorsqu’une machine joue le rôle de routeur ou de passerelle. C’est le cas lorsque DataNova décide de faire passer tout le trafic de ses bureaux à travers un unique serveur Linux connecté à Internet. La table nat devient alors centrale pour mettre en œuvre la translation d’adresses réseau.

Comprendre le NAT (Network Address Translation) avec iptables

Le NAT permet à plusieurs machines internes, utilisant des adresses privées (par exemple 192.168.10.0/24), d’accéder à Internet via une seule IP publique. Iptables offre plusieurs cibles dédiées dans la table nat :

• 🎭 MASQUERADE : adaptation dynamique de l’adresse source à l’IP de sortie (idéal pour les IP publiques dynamiques).
• 🔄 SNAT : translation source avec IP ou plage précises (pratique pour des IP publiques fixes).
• 🎯 DNAT : translation de l’adresse de destination, pour rediriger un service vers une autre machine interne.

Chez DataNova, le serveur passerelle utilise une adresse dynamique fournie par un FAI. L’équipe met donc en place un MASQUERADE :


sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE


Cette règle indique qu’à chaque fois qu’un paquet sort vers Internet via l’interface eth0, son adresse source doit être remplacée par l’IP publique de cette interface. En complément, la table filter doit autoriser le transit :


sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT


Ici, eth1 représente l’interface interne (LAN). Le résultat : toutes les machines du réseau local naviguent sur Internet sans exposer directement leurs adresses privées.

Redirections de ports avec DNAT : publier un service interne

Supposons que DataNova héberge un serveur web interne sur 192.168.10.50 et souhaite le rendre accessible depuis Internet sur le port 443. Plutôt que d’attribuer à cette machine une IP publique, la passerelle iptables peut utiliser le DNAT :


sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 192.168.10.50:443


En parallèle, la table filter doit autoriser le trafic :


sudo iptables -A FORWARD -p tcp -d 192.168.10.50 --dport 443 -j ACCEPT


Ce mécanisme est fréquemment utilisé dans les PME pour publier quelques services internes (web, VPN, messagerie) avec une seule IP publique. L’impact business est double : réduction des coûts d’adressage et simplification de l’architecture, tout en gardant un contrôle fin sur ce qui est exposé.

Utiliser la table mangle pour des besoins avancés

La table mangle offre un contrôle supplémentaire sur le traitement des paquets. Elle permet par exemple :

• 📌 De marquer les paquets (MARK) pour que le système les route via des règles spéciales.
• ⏳ D’ajuster le TTL (Time To Live), c’est-à-dire le nombre de sauts maximum.
• 📊 De préparer une politique de QoS (qualité de service) en classant certains flux.

Dans l’univers de DataNova, la table mangle peut servir à prioriser le trafic VPN par rapport au téléchargement de mises à jour, garantissant ainsi une meilleure expérience aux collaborateurs distants. Même si ces usages sont plus avancés, comprendre leur existence évite de penser qu’iptables se limite au simple “autoriser/bloquer”.

Au final, NAT et mangle prolongent iptables au-delà du pare-feu de base pour en faire une véritable boîte à outils réseau. Reste à s’assurer que tout ce travail ne soit pas perdu au prochain redémarrage.

Persistance, bonnes pratiques et transition vers les outils modernes

Une caractéristique parfois déroutante pour les débutants : les règles iptables appliquées en ligne de commande sont volatiles. Au redémarrage du système, elles disparaissent, sauf si un mécanisme de sauvegarde et de restauration est utilisé. Dans un contexte professionnel, oublier cette étape peut laisser un serveur en production sans pare-feu, avec toutes les conséquences possibles.

Rendre les règles persistantes selon la distribution

Les méthodes de persistance varient selon les familles de distributions :

• 🐧 Debian/Ubuntu : utilisation de iptables-save et iptables-restore, ou de paquets dédiés comme iptables-persistent.
• 🎩 RHEL/CentOS/Rocky : service iptables hérité, ou intégration dans les scripts système.

Exemple sur une base Debian/Ubuntu :


sudo iptables-save | sudo tee /etc/iptables.rules


Puis, dans un script exécuté au démarrage (par exemple via systemd ou /etc/network/if-pre-up.d/) :

iptables-restore < /etc/iptables.rules

Chez DataNova, cette étape est systématisée : toute machine en production possède un fichier de règles versionné, ainsi qu’un mécanisme de restauration automatique au boot. Cela évite qu’une mise à jour ou un incident matériel n’annule silencieusement la protection du firewall.

Bonnes pratiques pour une configuration iptables saine

Au-delà de la persistance, plusieurs réflexes renforcent la robustesse des déploiements :

• 📝 Documenter les règles complexes avec le module -m comment --comment "explication".
• 🔄 Tester sur une machine de préproduction avant de déployer sur un serveur critique.
• 🧪 Construire les règles par couches (base, services, journalisation) plutôt qu’en vrac.
• 🧯 Prévoir un accès de secours (console, IPMI, KVM) au cas où le SSH serait coupé accidentellement.
• 📦 Automatiser via des scripts ou des outils de configuration pour garantir la reproductibilité.

Chez DataNova, chaque modification du pare-feu passe par un fichier de règles stocké dans un dépôt Git, revu par un autre membre de l’équipe. Cette discipline réduit les risques d’erreurs humaines, améliore la traçabilité et facilite le retour arrière, ce qui est déterminant lors d’incidents en pleine journée ouvrée.

iptables, firewalld et nftables : quelle place pour chacun ?

Dans de nombreuses distributions récentes, l’outil firewalld propose une abstraction plus simple, avec des “zones” et des services pré-définis. En dessous, il peut utiliser iptables ou nftables comme moteur. De même, certains systèmes migrent progressivement vers nftables en tant que couche unique de filtrage.

Plutôt que d’opposer ces solutions, il est plus utile de les voir comme des niveaux :

• 🧰 iptables : contrôle fin et direct, très adapté aux scripts et à l’apprentissage des concepts.
• 🔥 firewalld : gestion dynamique, intégration avec des environnements de bureau ou serveurs, plus convivial.
• 🧬 nftables : moteur moderne, plus flexible, pensé pour remplacer progressivement le couple iptables+netfilter classique.

La compréhension profonde d’iptables reste un atout, même lorsqu’on utilise ensuite des couches plus haut niveau. En cas de problème complexe ou de comportement inattendu, la capacité à raisonner en termes de paquets, de tables et de chaînes reste déterminante.

Pour DataNova, le compromis consiste aujourd’hui à conserver iptables pour les passerelles réseau critiques, où chaque règle est maîtrisée, tout en s’autorisant l’usage de firewalld sur certaines machines moins sensibles. Cette approche graduée reflète une réalité fréquente dans les infrastructures modernes.

À quoi sert exactement iptables sur un serveur Linux ?

Iptables sert à contrôler le trafic réseau qui entre, sort ou traverse une machine Linux. Il s’appuie sur le moteur netfilter du noyau pour appliquer des règles de filtrage (packet filtering), de NAT et de marquage.

Concrètement, il permet de construire un pare-feu logiciel capable de bloquer des attaques, de limiter l’exposition des services et d’organiser la circulation des paquets selon des règles précises.

Quelle est la différence entre iptables et firewalld ?

Iptables est une interface bas niveau qui manipule directement les tables et chaînes du noyau Linux. Firewalld est une couche plus haut niveau qui propose des zones, des services préconfigurés et une gestion dynamique.

Sur certaines distributions, firewalld utilise iptables ou nftables comme moteur sous-jacent. Maîtriser iptables reste utile pour comprendre et diagnostiquer ce que fait réellement firewalld.

Comment sauvegarder mes règles iptables pour qu’elles survivent au redémarrage ?

Sur Debian/Ubuntu, il est possible d’utiliser iptables-save pour exporter la configuration dans un fichier, puis iptables-restore au démarrage pour la réappliquer. Des paquets comme iptables-persistent automatisent cette tâche.

Sur RHEL/CentOS, un service iptables ou des scripts systemd peuvent jouer le même rôle. Sans ce mécanisme de persistance, toutes les règles définies en ligne de commande disparaissent après un reboot.

Iptables est-il toujours pertinent à l’ère de nftables ?

Oui, iptables reste très présent en production et dans de nombreuses documentations. Même si nftables est appelé à le remplacer progressivement, comprendre iptables facilite la transition vers les nouveaux outils, permet de maintenir les anciens scripts et offre une grille de lecture claire du comportement du pare-feu.

Dans beaucoup d’entreprises, les deux coexistent encore, avec des usages complémentaires.