La migración de iptables a nftables es para muchas Linux‑infraestructuras un paso necesario: nftables ofrece medios modernos para la gestión de reglas de firewall, estructuras de datos más eficientes y actualizaciones atómicas que minimizan las ventanas de indisponibilidad al cargar reglas. En esta guía orientada a la práctica describo un procedimiento reproducible desde la inventariación, pasando por la conversión, hasta las pruebas y el rollback. La guía está dirigida a administradores, ingenieros de sistemas y operadores que deben tener en cuenta la operación, las interfaces y las interacciones con Docker.
¿Por qué cambiar de iptables a nftables?
iptables se ha desarrollado históricamente; nftables es una API de kernel más reciente con un conjunto de herramientas en espacio de usuario (nft) que gestiona las reglas como un único „ruleset“. Las ventajas son una menor sobrecarga de CPU en conjuntos de reglas grandes, sets/maps para búsquedas de alto rendimiento y operaciones atómicas de reemplazo de reglas. Esto es especialmente relevante si usted gestiona muchas entradas dinámicas (p. ej., listas de IP) o cargas de trabajo containerizadas.
Definición de términos: „ruleset“ designa la totalidad de tablas, cadenas y reglas. „conntrack“ es el connection tracking en el kernel, que gestiona las conexiones existentes y es esencial para firewalls con estado.
Preparación: Inventario, dependencias y requisitos previos
Antes de convertir, inventaríe hosts, servicios, uso de Docker, filtros externos (Load Balancer, VPN) y todas las extensiones de iptables. Compruebe la versión del kernel, la instalación de libnftables y el backend de iptables actualmente en uso (legacy vs nft).
Pasos concretos
# 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
Herramientas: qué ayuda y dónde están los límites
Herramientas disponibles:
- iptables-translate — traduce reglas individuales de iptables a la sintaxis de nftables; útil para trabajo manual posterior.
- iptables-save / iptables-RESTore — probadas para respaldar y RESTaurar volcados completos de iptables.
- nft — herramienta central para nftables (cargar, verificar, listar).
Importante: la conversión automática nunca es 100% infalible. Matches complejos, extensiones propietarias, NFLOG, manipulaciones raw o módulos de kernel especiales requieren control manual.
Migración de iptables a nftables: Procedimiento (paso a paso)
1. Replicar el entorno de staging
Replique la configuración de hosts, los stacks de Docker y los perfiles de red en un entorno de prueba. Pruebe con perfiles de carga y de conexión realistas para que las repercusiones sobre conntrack y el rendimiento sean visibles.
2. Traducción automática y agregación
Un patrón habitual es: leer el volcado de iptables, convertir las reglas individualmente con iptables-translate y trasladarlas a un archivo nftables estructurado. Así es posible agrupar reglas y crear 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. Estructuración y uso de sets
Agrupe reglas similares en tablas/cadenas y use sets para listas de IP, puertos o rangos de puertos: eso reduce el número de reglas y mejora el rendimiento 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. Comprobación de sintaxis y reemplazo atómico
Utilice „nft -c -f“ para comprobaciones de sintaxis y „nft replace ruleset“ para el intercambio atómico del ruleset activo.
# 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. Despliegue canario
Implemente el nuevo ruleset primero en pocos hosts. Supervise la alcanzabilidad (reachability), la latencia, la CPU y conntrack. En caso de problemas, los hosts canario permiten revertir de forma localizada sin afectar al RESTo del clúster.
Pruebas: funcionalidad, análisis de paquetes y automatización
Pruebe en tres niveles: funcional (alcanzabilidad/política), ruta de paquete (tcpdump/pcap) y seguimiento de conexiones (conntrack). Las pruebas automatizadas en CI garantizan que los cambios se validen antes del despliegue a producción.
Ejemplos de comandos de prueba
# 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
Hosts Docker: opciones y riesgos
Docker crea de forma nativa cadenas iptables (DOCKER, DOCKER‑USER) para NAT y reenvío de puertos. Dos enfoques prácticos:
- Permitir que Docker siga gestionando iptables y confiar en la capa de compatibilidad de la distribución (iptables‑nft).
- Ejecutar Docker con „–iptables=false“ y gestionar todas las reglas NAT/Filter manualmente — requiere conocimientos avanzados.
Ambas vías tienen ventajas y desventajas. En sistemas productivos, probar de forma incremental la capa de compatibilidad suele ser menos arriesgado.
Pruebas prácticas con 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: persistencia, límites y timeouts
conntrack mantiene información de estado sobre las conexiones. Durante una migración, las conexiones existentes pueden continuar mientras las entradas de conntrack no se pierdan. Sin embargo, un reload del kernel o un orden incorrecto al reiniciar servicios de red puede provocar interrupciones de conexión.
Parámetros sysctl importantes
# 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
Justificación: con una alta concurrencia de conexiones, un conntrack_max demasiado bajo puede provocar que se descarten nuevas conexiones. Planifique los cambios y mida antes/después de la modificación.
Optimización de rendimiento: Sets, Maps y atomicidad
Los sets de nftables reducen el número de reglas de comparación directas. Para tablas muy grandes, utilice flags como „interval“ o combínelos con counters para detectar puntos calientes. Las actualizaciones atómicas evitan inconsistencias durante los despliegues.
Estrategia de rollback y acceso de emergencia
Un plan de rollback claramente documentado y probado es imprescindible. Conserve las iptables‑saves con control de versiones y pruebe la RESTauración en staging.
Ejemplo: Reversión rápida a 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
Consejo adicional: guarde el playbook de rollback como un script ejecutable que los miembros del equipo puedan manejar tras una breve instrucción.
Puntos críticos frecuentes y medidas preventivas
- Conflictos con firewalld/ufw: desactive o migre estos servicios; de lo contrario sobrescribirán las reglas al arrancar.
- Address Family Mismatch: direcciones IPv6 en una tabla IPv4 provocan errores; prefiera la familia „inet“ para reglas compartidas.
- Falta de persistencia: active el servicio systemd para nftables o asegúrese de que sus herramientas de gestión de configuración RESTauren el archivo al arrancar.
- El reenvío de puertos de Docker pierde conexiones: pruebe los mapeos de puertos después de cada recarga y verifique las cadenas DOCKER.
¿Cuándo posponer la migración?
Posponga la migración si está a punto de ventanas de lanzamiento importantes, si aplicaciones de terceros críticas usan extensiones propietarias de iptables o si sus equipos de operaciones no están lo suficientemente familiarizados con el comportamiento de conntrack y la gestión de red de Docker. La migración es un proyecto de infraestructura y requiere tiempo para pruebas y formación.
Referencia rápida: comandos útiles
# 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
Aceptación, monitorización y operación continua
Tras el go‑live: exporte los counters, enlace los Log‑Prefixes a su registro central y cree dashboards para las tasas de DROP y la carga de conntrack. Programe pruebas de humo periódicas y mantenga Canary‑Hosts como referencia.
Rutina de mantenimiento
- Revisión diaria de los contadores DROP durante las primeras semanas de operación
- Validación semanal de las rutas de red de los contenedores
- Sesiones de revisión mensuales con registro de cambios
Conclusión
La migración de iptables a nftables es una medida rentable para la mantenibilidad a largo plazo, el rendimiento y la gestión coherente de reglas IPv4/IPv6. Es fundamental realizar un inventario exhaustivo, pruebas en staging, validación automática y manual de las reglas convertidas, así como disponer de un plan de rollback probado. En hosts Docker conviene actuar con cautela y comprobar detalladamente la interacción con las cadenas DOCKER/DOCKER‑USER. Con pruebas soportadas por CI, Canary‑Rollouts y monitorización, conseguirá una ruta de migración estable y reproducible sin interrupciones de servicio.
Esta guía ofrece scripts de comprobación concretos, indicaciones de troubleshooting y una estrategia práctica de rollback que puede integrarse directamente en procesos operativos existentes. Comience en el entorno de Staging, automatice las pruebas y amplíe su visibilidad de monitorización antes de pasar a producción.
Práctica: Gobernanza y CI para la migración de iptables a nftables
Para una migración segura de iptables a nftables no basta con una ejecución única. Establezca «Policy as Code»: las reglas se mantienen versionadas en un repositorio, los cambios pasan por revisión, pruebas automatizadas y un despliegue por fases. Esto es especialmente importante cuando los controles de acceso están vinculados de forma cercana a software empresarial individual o a software de negocio.
Indicaciones de arquitectura para entornos distribuidos
- Konfigurationsquelle: Ein zentrales Git-Repo mit environments (staging, canary, prod) verhindert Drift.
- Verteilung: Nutzen Sie GitOps-Agents oder CM‑Tools, damit Hosts zustandsorientiert dieselbe nftables-Konfiguration beziehen.
- HA-Cluster: Achten Sie auf deterministische Reihenfolge beim Anwenden (zuerst passive Knoten), damit bestehende TCP‑Sessions nicht unnötig abreißen.
Prüfungen und CI‑Gate
Las comprobaciones automatizadas deben cubrir al menos los siguientes puntos: sintaxis, idempotencia, regresión de políticas (apertura de nuevos puertos), prueba de humo de rendimiento (número de reglas, tamaños de conjuntos) y una comprobación simulada de paquetes con pcap‑snippets.
# 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
Betrieb: Persistenz, Idempotenz und Rollback‑Hooks
Asegure una rutina de aplicación idempotente. Un servicio systemd o una tarea CM debería comprobar si el ruleset cambia y solo entonces aplicarlo activamente. Así evita recargas innecesarias y posibles interrupciones de conexión.
# 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
Recoja métricas por Chain y por Rule-Counter. Para integraciones en monitoring‑stacks puede exportar los contadores mediante un cron y ofrecerlos al Textfile-Collector del node_exporter. Las alertas deben dispararse ante aumentos bruscos de DROP, una caída de la capacidad de conntrack o una discrepancia en el número de reglas.
# 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
Compliance und Change Management
Documente cada establecimiento de regla con responsable, Ticket‑ID y descripción del impacto. En soluciones de software cercanas a los procesos es útil etiquetar las reglas con application‑tags (p. ej. app:webshop) para que las consultas de auditoría puedan mapearse a áreas de negocio.
En resumen: la migración es a la vez implementación técnica y proceso organizativo. Con versionado, CI‑Gates, despliegues idempotentes, monitorización dirigida y hooks de rollback claros, minimice los riesgos y asegure que los requisitos de seguridad y operativos se cumplan de forma reproducible también después del cambio.
Indicaciones operativas para la migración de iptables a nftables
En entornos en producción no solo importa la conversión, sino también cómo orquesta estados, contadores y despliegues distribuidos. Utilice actualizaciones atómicas de conjuntos („nft replace element“) para modificar listas de IP o de puertos sin recargar completamente el ruleset; esto minimiza las interrupciones de conexión y preserva las entradas de conntrack. Tenga en cuenta que un „nft replace ruleset“ completo puede restablecer los contadores: exporte los contadores antes de cambios críticos si necesita continuidad en la monitorización.
En clústeres HA o durante despliegues por fases: opere con un orden determinista (primero los nodos pasivos), pruebe el comportamiento con sesiones reales y automatice la reversión. Añada metadatos a las reglas (p. ej. app:webshop) y gestione la versión de los rulesets en Git; de este modo las comprobaciones frente al software empresarial personalizado o a los servicios de negocio pueden rastrearse y auditarse.