Configuración paso a paso con nftables para minimizar latencia

El primer paso consiste en cargar el conjunto de reglas en la tabla raw para descartar tráfico no deseado lo antes posible. De esta forma se evita que paquetes maliciosos o de escaneo lleguen a conntrack.

1. Crea una tabla llamada firewall con el tipo filter y el hook prerouting con prioridad -300 para que se ejecute antes que conntrack.
2. Define un conjunto de direcciones IP de origen bloqueadas que se actualice mediante un script externo cada hora.
3. Coloca una regla de salto al primer conjunto de direcciones permitidas antes de cualquier otra comprobación.
4. Evita usar el módulo conntrack en flujos UDP de alta tasa como streaming o telemetría de sensores.

Reglas concretas para entornos con tráfico mixto

En un servidor que atiende tanto tráfico web como consultas a bases de datos PostgreSQL, la siguiente estructura ha demostrado mantener la latencia por debajo de 35 µs en el percentil 99:

• Primero se evalúa un mapa de puertos de destino con las direcciones IP permitidas para el puerto 5432.
• El tráfico HTTPS se marca con un valor en el campo ctmark para que más adelante pueda ser procesado por un conjunto separado.
• Todo el tráfico que no coincide con los puertos definidos se envía directamente a la cadena de drop sin pasar por conntrack.

Integración con XDP y eBPF para cargas de trabajo exigentes

Cuando se necesita latencia inferior a 15 µs, la única opción realista es mover parte de la lógica de filtrado al driver de la tarjeta de red mediante XDP. Proyectos como xdp-filter permiten compilar reglas simples directamente en el driver mlx5 o i40e.

La ventaja principal es que los paquetes que deben ser descartados nunca llegan al stack del kernel. En un clúster de Kubernetes con CNI Cilium, activar el modo XDP en los nodos worker redujo la latencia media de las llamadas entre pods de 42 µs a 19 µs según mediciones con bpftrace.

Limitaciones prácticas del enfoque XDP

No todas las operaciones son posibles dentro de un programa XDP. No se puede hacer NAT completo ni mantener estados complejos de conexión. Por eso la estrategia habitual consiste en combinar XDP para el filtrado inicial y nftables para las decisiones que requieren estado.

• Los programas XDP deben caber dentro de los 4096 bytes que permite el verificador de eBPF en kernels 5.15 y superiores.
• Actualizar las reglas de XDP requiere recompilar y volver a cargar el programa, por lo que se suele usar un mapa de eBPF actualizado desde userspace.
• Algunas tarjetas Mellanox permiten combinar XDP con hardware offload de reglas de flujo, aunque esta característica sigue siendo experimental en la mayoría de distribuciones.

Ejemplos reales de configuraciones en producción

En una plataforma de videojuegos con picos de 180 000 paquetes por segundo por servidor, se implementó nftables con conjuntos de direcciones dinámicos actualizados cada 30 segundos desde un servicio de reputación de IP. La latencia del percentil 99 se mantuvo en 31 µs después de la migración desde iptables.

Otro caso corresponde a un proveedor de hosting que ejecuta Proxmox con más de 200 máquinas virtuales por nodo. Utilizaron una combinación de reglas en la tabla raw para bloquear puertos de gestión y un mapa nftables para permitir únicamente el tráfico entre las redes de almacenamiento y las redes de producción. Las pruebas con iperf3 mostraron que el jitter se redujo de 180 µs a 45 µs tras eliminar las reglas de conntrack en el tráfico de almacenamiento.

Un tercer ejemplo proviene de un equipo de investigación que ejecuta simulaciones de dinámica de fluidos en un clúster con interconnect Infiniband. Configuraron XDP para filtrar tráfico de gestión SSH y permitieron que solo los nodos con direcciones MAC registradas pudieran enviar paquetes al puerto 22. La latencia de las operaciones MPI se mantuvo prácticamente idéntica a la de la red sin firewall.

Pruebas y validación del impacto real

Antes de aplicar cualquier cambio en producción conviene medir con herramientas que no introduzcan ruido adicional. cyclictest combinado con pktgen del kernel permite generar tráfico controlado y medir la latencia de respuesta del sistema.

Una prueba típica consiste en enviar 10 millones de paquetes UDP de 64 bytes desde una máquina generadora hacia el servidor protegido por el firewall y registrar los tiempos de respuesta. Se repite la prueba con el firewall desactivado, con reglas básicas y con la configuración completa para obtener deltas reales.

Métricas que realmente importan

• Latencia del percentil 99,9 en lugar de la media, porque los picos son los que afectan a las aplicaciones.
• Número de paquetes procesados por segundo antes de que empiece a aparecer pérdida de paquetes.
• Consumo de CPU por núcleo cuando se activa el modo XDP versus el modo tradicional de Netfilter.

Después de cada cambio de configuración es recomendable esperar al menos cinco minutos antes de tomar medidas para que el sistema se estabilice y los mapas de eBPF se calienten en caché.

La configuración de firewalls con bajo impacto en latencia requiere entender el camino exacto que sigue cada paquete dentro del kernel y colocar las decisiones más probables al principio de cada cadena. nftables y XDP ofrecen actualmente las mejores herramientas para lograrlo sin sacrificar la seguridad necesaria en entornos reales.