☰

Problema de desempenho do Linux iptables / conntrack

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

Tenho uma configuração de teste no laboratório com 4 máquinas:

  • 2 máquinas P4 antigas (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 testar o desempenho do firewall Linux desde que fomos atingidos por vários ataques de syn-flood nos últimos meses. Todas as máquinas rodam Ubuntu 12.04 64 bits. t1, t2, t3 são interligados através de um switch de 1GB/s, t4 é conectado a t3 através de uma interface extra. Então t3 simula o firewall, t4 é o alvo, t1,t2 joga com os invasores gerando uma tempestade de pacotes completa (192.168.4.199 é t4):

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

t4 descarta todos os pacotes recebidos para evitar confusão com gateways, problemas de desempenho do t4 etc. Eu observo as estatísticas dos pacotes no iptraf. Eu configurei o firewall (t3) da seguinte forma:

  • estoque 3.2.0-31-genérico #50-kernel SMP do Ubuntu
  • rhash_entries=33554432 como parâmetro do kernel

  • sysctl da seguinte forma:

    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

(Eu ajustei bastante para manter o t3 funcionando quando t1+t2 estão enviando tantos pacotes quanto possível).

O resultado desses esforços é um tanto estranho:

  • t1 + t2 conseguem enviar cada um cerca de 200 mil pacotes/s. Na melhor das hipóteses, t4 vê cerca de 200k no total, então metade dos pacotes são perdidos.
  • t3 é quase inutilizável no console, embora os pacotes estejam fluindo através dele (grande número de soft-irqs)
  • o coletor de lixo do cache de rota não está nem perto de ser previsível e na configuração padrão sobrecarregado por poucos pacotes/s (<50k pacotes/s)
  • ativar regras de iptables com estado faz com que a taxa de pacotes que chegam em t4 caia para cerca de 100 mil pacotes/s, perdendo efetivamente mais de 75% dos pacotes

E esta - aqui é a minha principal preocupação - com duas máquinas P4 antigas enviando tantos pacotes quanto puderem - o que significa que quase todos na rede deveriam ser capazes disso.

Então aqui vai minha pergunta: esqueci algum ponto importante na configuração ou na minha configuração de teste? Existem alternativas para construir um sistema de firewall, especialmente em sistemas SMP?

Responder1

Eu migraria para o Kernel >= 3.6, que não possui mais cache de roteamento. Isso deve resolver uma parte dos seus problemas.

Responder2

Como está sua configuração de log no T3? Se todos os pacotes descartados forem registrados, a E/S do disco pode ser a causa.

Como este é um ambiente de teste, você pode tentar o teste com o log T3 desativado.

informação relacionada