La migration d’iptables vers nftables est, pour de nombreuses Linux‑infrastructures, une étape nécessaire : nftables fournit des moyens modernes pour gérer les règles de pare‑feu, des structures de données plus efficaces et des mises à jour atomiques qui minimisent les fenêtres d’indisponibilité lors du chargement des règles. Dans ce guide pratique, je décris un processus reproductible, de l’inventaire à la conversion, puis aux tests et au rollback. Le guide s’adresse aux administrateurs, ingénieurs système et opérateurs qui doivent garder à l’esprit l’exploitation, les interfaces et les interactions Docker.
Pourquoi passer d’iptables à nftables ?
iptables s’est développé historiquement ; nftables est une API noyau plus récente accompagnée d’un ensemble d’outils userspace (nft) qui gèrent les règles comme un „ruleset“ centralisé. Les avantages comprennent une charge CPU réduite pour les jeux de règles volumineux, l’utilisation de sets/maps pour des recherches performantes et des opérations de remplacement de règles atomiques. Cela est particulièrement pertinent si vous gérez de nombreux éléments dynamiques (par ex. des listes d’IP) ou des charges de travail containerisées.
Définition des termes : „ruleset“ désigne l’ensemble de toutes les tables, chains et règles. „conntrack“ est le suivi de connexion dans le noyau, qui gère les connexions établies et est essentiel pour des pare‑feu à état.
Préparation : inventaire, dépendances et prérequis
Avant de convertir, inventairez les hôtes, les services, l’utilisation de Docker, les filtres externes (load balancers, VPN) et toutes les extensions iptables. Vérifiez la version du noyau, l’installation de libnftables et le backend iptables actuellement utilisé (legacy vs nft).
Étapes concrètes
# iptables Regelwerk sichern (IPv4 und IPv6)
iptables-save > /root/iptables-save-$(date +%F).rules
ip6tables-save > /root/ip6tables-save-$(date +%F).rules
# Paket- und Kernel‑Status dokumentieren (Debian/Ubuntu Beispiel)
dpkg -l | egrep "nftables|iptables|libnft" > /root/pkg-list-$(date +%F).txt
uname -r > /root/kernel-version-$(date +%F).txt
Outils : ce qui aide et où sont les limites ?
Outils disponibles :
- iptables-translate — traduit des règles iptables individuelles en syntaxe nftables ; utile pour la retouche manuelle.
- iptables-save / iptables-RESTore — éprouvés pour sauvegarder et RESTaurer des dumps complets iptables.
- nft — outil central pour nftables (chargement, vérification, listing).
Important : la conversion automatique n’est jamais fiable à 100 %. Les matches complexes, les extensions propriétaires, NFLOG, les manipulations en raw ou les modules noyau spécifiques nécessitent une vérification manuelle.
Migration d’iptables vers nftables : procédure (étape par étape)
1. Reproduire l’environnement de staging
Répliquez la configuration des hôtes, les stacks Docker et les profils réseau dans un environnement de test. Testez avec des charges et des profils de connexion réalistes afin de rendre visibles les effets sur conntrack et sur la performance.
2. Traduction automatique et agrégation
Un schéma courant est le suivant : lire le dump iptables, traduire les règles individuellement avec iptables-translate et les transférer dans un fichier nftables structuré. Cela permet de grouper les règles et de créer des sets.
# Regeln per Script übersetzen und in Datei sammeln
iptables-save | grep -E "^-A" | while read -r rule; do
# Regel ohne Präfix -A an iptables-translate übergeben
trimmed=$(echo "$rule" | sed 's/^-A //')
echo "$trimmed" | xargs -I '{}' iptables-translate '{}'
done > /root/translated.rules
3. Structuration et utilisation des sets
Regroupez les règles similaires dans des tables/chains et utilisez des sets pour les listes d’IP, les ports ou les plages de ports — cela réduit le nombre de règles et améliore les performances de lookup.
# Beispiel: Set für IPs und Anwendung in einer Chain
nft add table inet filter
nft 'add set inet filter trusted { type ipv4_addr; flags interval; }'
nft add element inet filter trusted { 10.10.0.1, 10.10.0.0/24 }
nft 'add chain inet filter input { type filter hook input priority 0; policy drop; }'
nft add rule inet filter input ip saddr @trusted accept
4. Vérification de la syntaxe et échange atomique
Utilisez „nft -c -f“ pour les vérifications de syntaxe et „nft replace ruleset“ pour un échange atomique du ruleset actif.
# Syntaxcheck
nft -c -f /root/created-nft-rules.conf
# Atomarer Austausch
nft replace ruleset < /root/created-nft-rules.conf
# Aktuellen Stand prüfen
nft list ruleset
5. Déploiement canari
Déployez d’abord le nouveau ruleset sur quelques hôtes. Surveillez l’atteignabilité, la latence, l’utilisation CPU et conntrack. En cas de problème, les Canary‑Hosts permettent un retour ciblé sans impact sur le RESTe du cluster.
Tests : fonctionnalité, analyse de paquets et automatisation
Testez trois niveaux : fonctionnel (atteignabilité/politique), chemin des paquets (tcpdump/pcap) et suivi de connexion (conntrack). Les tests automatisés dans le CI garantissent que les modifications sont validées avant la bascule en production.
Exemples de commandes de test
# Reachability Test
curl -sS --connect-timeout 5 http://10.0.5.10:8080/health || echo "Service unreachable"
# Paketsammlung für Debug
tcpdump -i eth0 host 10.0.5.10 and port 8080 -c 200 -w /tmp/trace.pcap
# Conntrack Überblick
conntrack -L | head -n 50
Docker‑Hosts : options et pièges
Docker crée nativement des iptables‑chains (DOCKER, DOCKER‑USER) pour le NAT et le port‑forwarding. Deux approches pratiques :
- Continuer à autoriser Docker à gérer iptables et se fier à la couche de compatibilité de la distribution (iptables‑nft).
- Exécuter Docker avec „–iptables=false“ et gérer vous‑même toutes les règles NAT/filtrage — cela exige beaucoup plus de savoir‑faire.
Les deux voies ont des avantages et des inconvénients. Sur des systèmes de production, tester progressivement la couche de compatibilité est généralement moins risqué.
Tests pratiques Docker
# docker daemon konfigurieren, damit es iptables nicht verändert
cat /etc/docker/daemon.json
# optional
# {
# "iptables": false
# }
systemctl RESTart docker
# Überprüfen, ob DOCKER-USER Chain vorhanden ist
iptables -L DOCKER-USER -n
Conntrack : conservation, limites et timeouts
conntrack conserve des informations d’état sur les connexions. Lors d’une migration, les connexions existantes peuvent continuer à fonctionner tant que les entrées conntrack ne sont pas perdues. Un reload du noyau ou un ordre de redémarrage incorrect des services réseau peut cependant entraîner des coupures de connexion.
Paramètres sysctl importants
# Beispiel: conntrack Kapazität erhöhen
sysctl -w net.netfilter.nf_conntrack_max=262144
# Persistenz in /etc/sysctl.d/99-nf.conf
# net.netfilter.nf_conntrack_max=262144
Motif : en cas de fort trafic de connexions, une valeur conntrack_max trop basse peut entraîner le rejet de nouvelles connexions. Planifiez les modifications et mesurez avant/après l’ajustement.
Optimisation des performances : sets, maps et atomicité
Les sets nftables réduisent le nombre de règles de comparaison directes. Pour des tables très volumineuses, utilisez des flags comme „interval“ ou combinez-les avec des Counters pour détecter les points chauds. Des mises à jour atomiques évitent les incohérences pendant les déploiements.
Stratégie de rollback et accès d’urgence
Un plan de rollback clairement documenté et testé est indispensable. Conservez les iptables‑Saves dans un stockage révisionnable et testez la RESTauration en staging.
Exemple : retour rapide vers iptables
# 1. Aktuelle nft Regeln sichern
nft list ruleset > /root/nft-backup-$(date +%F).conf
# 2. Vorherigen iptables Dump wiederherstellen
iptables-RESTore < /root/iptables-save-2023-09-01.rules
ip6tables-RESTore < /root/ip6tables-save-2023-09-01.rules
# 3. Docker neu starten (falls nötig)
systemctl RESTart docker
Conseil supplémentaire : placez le Rollback‑Playbook sous forme de script exécutable, que les membres de l’équipe pourront utiliser après une brève instruction.
Pièges fréquents et mesures préventives
- Conflits avec firewalld/ufw : désactivez-les ou migrez-les, sinon ces services écraseront les règles au démarrage.
- Incompatibilité des familles d’adresses : des adresses IPv6 dans une table IPv4 provoquent des erreurs ; privilégiez la family « inet » pour des règles communes.
- Persistance manquante : activez le service systemd pour nftables ou assurez-vous que vos outils de gestion de configuration RESTaurent le fichier au démarrage.
- Le port‑forwarding Docker perd la connexion : testez les Port‑Mappings après chaque reload et vérifiez les chaînes DOCKER.
Quand reporter la migration ?
Reportez la migration si vous êtes juste avant des fenêtres de release majeures, si des applications tierces critiques utilisent des extensions iptables propriétaires ou si vos équipes Ops ne sont pas suffisamment entraînées au comportement de Conntrack et à la gestion des réseaux Docker. La migration est un projet d’infrastructure et nécessite du temps pour les tests et la formation.
Référence rapide : commandes utiles
# Regeln anzeigen
nft list ruleset
# Syntaxcheck
nft -c -f /path/to/file.conf
# Conntrack Übersicht
conntrack -L | wc -l
# Backup iptables
iptables-save > /root/iptables-backup.rules
# RESTore iptables
iptables-RESTore < /root/iptables-backup.rules
Validation, monitoring et exploitation courante
Après le go‑live : exportez les Counters, associez des Log‑Prefixes à votre logging centralisé et créez des tableaux de bord pour les taux de DROP et l’utilisation du conntrack. Planifiez des smoke‑tests réguliers et conservez des Canary‑Hosts comme point de référence.
Routine de maintenance
- Vérification quotidienne des compteurs DROP durant les premières semaines d’exploitation
- Validation hebdomadaire des chemins réseau des conteneurs
- Sessions de revue mensuelles avec journal des modifications
Conclusion
La migration d’iptables vers nftables est une étape rentable pour la maintenabilité à long terme, les performances et une gestion cohérente des règles IPv4/IPv6. Indispensables : un inventaire approfondi, des tests en staging, une validation automatique et manuelle des règles converties, ainsi qu’un plan de rollback testé. Sur les hôtes Docker, procédez avec prudence et examinez en détail l’interaction avec les chaînes DOCKER/DOCKER‑USER. Avec des validations CI, des déploiements Canary et du monitoring, vous obtenez une voie de migration stable et reproductible sans interruption de service.
Ce guide fournit des scripts de vérification concrets, des indications de dépannage et une stratégie de rollback opérationnelle, pouvant être intégrés directement aux processus opérationnels existants. Commencez en staging, automatisez les tests, et élargissez votre visibilité de monitoring avant de passer en production.
Pratique: Governance und CI für die Migration von iptables zu nftables
Pour une migration sécurisée d’iptables vers nftables, un seul run ne suffit pas. Établissez « Policy as Code » : les règles sont versionnées dans un dépôt, les modifications passent par une revue, des tests automatisés et un déploiement gradué. Cela est particulièrement important lorsque les contrôles d’accès sont liés de manière rapprochée à des logiciels d’entreprise personnalisés ou à des logiciels métier.
Remarques d’architecture pour environnements distribués
- Source de configuration : un dépôt Git central avec des environnements (staging, canary, prod) empêche la dérive.
- Distribution : utilisez des agents GitOps ou des outils CM afin que les hôtes récupèrent de manière déclarative la même configuration nftables.
- Clusters HA : veillez à appliquer dans un ordre déterministe (d’abord les nœuds passifs), afin d’éviter des coupures inutiles des sessions TCP existantes.
Contrôles et CI‑Gate
Les contrôles automatisés doivent au minimum couvrir les points suivants : syntaxe, idempotence, régression de politique (ouverture de nouveaux ports), smoke test de performance (nombre de règles, tailles de sets) et une simulation de vérification de paquets avec des extraits pcap.
# Beispiel: einfacher CI-Job (Pseudo-YAML) prüft ruleset
jobs:
validate-nft:
script:
- nft -c -f changed.rules.conf # Syntaxprüfung
- ./tests/check-no-open-ports.sh # Policy-Regressions-Test
- ./tests/simulate-traffic.sh # Paketpfad-Simulation
Exploitation: Persistenz, Idempotenz und Rollback‑Hooks
Assurez-vous d’une routine d’application idempotente. Un service systemd ou une tâche CM devrait vérifier si le ruleset a changé, et n’appliquer activement que dans ce cas. Cela évite les reloads inutiles et d’éventuelles interruptions de connexion.
# Beispiel systemd-Unit für idempotentes Anwenden
[Unit]
Description=Apply nftables ruleset atomically
After=network.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/nft replace ruleset < /etc/nftables/rules.conf
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Monitoring, Audit und Alerting
Collectez des métriques par chain et par compteur de règle. Pour une intégration aux stacks de monitoring, vous pouvez exporter les compteurs via cron et les fournir au Textfile Collector du node_exporter. Des alertes doivent être déclenchées en cas d’augmentation soudaine des DROP, d’une diminution de la capacité conntrack ou d’un nombre de règles anormal.
# Counters exportieren (Textfile für Prometheus node_exporter)
mkdir -p /var/lib/node_exporter/textfile_collector
nft list ruleset | grep counter -n > /var/lib/node_exporter/textfile_collector/nft_counters.prom
Conformité et gestion des changements
Documentez chaque mise en place de règle avec le responsable, l’ID du ticket et une description des impacts. Pour les solutions logicielles proches des processus, il est utile d’étiqueter les règles avec des tags d’application (p. ex. app:webshop), afin que les requêtes d’audit puissent être mappées sur les domaines métier.
En bref : la migration est à la fois une mise en œuvre technique et un processus organisationnel. Avec versionnement, CI‑gates, déploiements idempotents, monitoring ciblé et hooks de rollback clairs, vous minimisez les risques et vous assurez que les exigences de sécurité et d’exploitation sont respectées de manière reproductible après la transition.
Instructions d’exploitation pour la migration d’iptables vers nftables
Dans des environnements en production, ce n’est pas seulement la conversion qui compte, mais aussi la manière dont vous orchestrez les états, les compteurs et les déploiements répartis. Utilisez de manière ciblée des mises à jour atomiques de set („nft replace element“) pour modifier des listes d’IP ou de ports sans recharger l’ensemble du ruleset; cela minimise les interruptions de connexion et préserve les entrées conntrack. Tenez compte du fait qu’un „nft replace ruleset“ complet peut réinitialiser les compteurs — exportez les compteurs avant des modifications critiques si une continuité de la supervision est nécessaire.
Dans des clusters HA ou lors de mises à jour progressives (rolling updates) : travaillez selon un ordre déterministe (d’abord les nœuds passifs), testez le comportement avec des sessions réelles et automatisez le rollback. Annotez les règles avec des métadonnées (p. ex. app:webshop) et versionnez les rulesets dans Git, ce qui permet de reproduire et d’auditer les vérifications vis‑à‑vis de logiciels d’entreprise spécifiques ou de services métier.