☰

Problema de rendimiento de iptables/conntrack de Linux

tag-icon • tag-icon linux firewall
Problema de rendimiento de iptables/conntrack de Linux

Tengo una configuración de prueba en el laboratorio con 4 máquinas:

  • 2 máquinas P4 antiguas (t1, t2)
  • 1 Xeon 5420 DP 2,5 GHz 8 GB de RAM (t3) Intel e1000
  • 1 Xeon 5420 DP 2,5 GHz 8 GB de RAM (t4) Intel e1000

para probar el rendimiento del firewall de Linux desde que sufrimos varios ataques de inundación de sincronización en los últimos meses. Todas las máquinas ejecutan Ubuntu 12.04 de 64 bits. t1, t2, t3 están interconectados a través de un conmutador de 1 GB/s, t4 está conectado a t3 a través de una interfaz adicional. Entonces, t3 simula el firewall, t4 es el objetivo, t1,t2 interpreta a los atacantes generando una tormenta de paquetes (192.168.4.199 es t4):

hping3 -I eth1 --rand-source --syn --flood 192.168.4.199 -p 80

t4 descarta todos los paquetes entrantes para evitar confusiones con puertas de enlace, problemas de rendimiento de t4, etc. Miro las estadísticas de paquetes en iptraf. He configurado el firewall (t3) de la siguiente manera:

  • stock 3.2.0-31-genérico #50-núcleo SMP de Ubuntu
  • rhash_entries=33554432 como parámetro del núcleo

  • sistema de la siguiente manera:

    net.ipv4.ip_forward = 1
net.ipv4.route.gc_elasticity = 2
net.ipv4.route.gc_timeout = 1
net.ipv4.route.gc_interval = 5
net.ipv4.route.gc_min_interval_ms = 500
net.ipv4.route.gc_thresh = 2000000
net.ipv4.route.max_size = 20000000

(He modificado mucho para mantener t3 ejecutándose cuando t1+t2 envían tantos paquetes como sea posible).

El resultado de estos esfuerzos es algo extraño:

  • t1+t2 logran enviar cada uno unos 200.000 paquetes/s. t4 en el mejor de los casos ve alrededor de 200k en total, por lo que la mitad de los paquetes se pierden.
  • t3 es casi inutilizable en la consola, aunque los paquetes fluyen a través de él (un gran número de soft-irqs)
  • el recolector de basura de caché de ruta no es ni mucho menos predecible y, en la configuración predeterminada, está abrumado por muy pocos paquetes/s (<50k paquetes/s)
  • La activación de reglas de iptables con estado hace que la velocidad de los paquetes que llegan a t4 caiga a alrededor de 100.000 paquetes/s, perdiendo efectivamente más del 75% de los paquetes.

Y esto - aquí está mi principal preocupación - con dos viejas máquinas P4 enviando tantos paquetes como pueden - lo que significa que casi todos en la red deberían ser capaces de hacer esto.

Así que aquí va mi pregunta: ¿Pasé por alto algún punto importante en la configuración o en mi configuración de prueba? ¿Existen alternativas para construir un sistema de firewall, especialmente en sistemas smp?

Respuesta1

Migraría a Kernel >= 3.6 que ya no tiene caché de enrutamiento. Eso debería resolver una parte de tus problemas.

Respuesta2

¿Cómo está su configuración de registro en T3? Si se registran todos los paquetes descartados, la E/S del disco puede ser la causa.

Dado que este es un entorno de prueba, puede realizar la prueba con el registro T3 desactivado.

información relacionada