☰

Linux iptables/conntrack 성능 문제

tag-icon • tag-icon linux firewall
Linux iptables/conntrack 성능 문제

실험실에서 4대의 컴퓨터로 테스트 설정을 했습니다.

  • 기존 P4 머신 2개(t1, t2)
  • Xeon 5420 DP 2.5GHz 8GB RAM(t3) Intel e1000 1개
  • Xeon 5420 DP 2.5GHz 8GB RAM(t4) Intel e1000 1개

지난 몇 달 동안 수많은 syn-flood 공격에 물렸기 때문에 Linux 방화벽 성능을 테스트했습니다. 모든 머신은 Ubuntu 12.04 64비트를 실행합니다. t1, t2, t3은 1GB/s 스위치를 통해 상호 연결되고, t4는 추가 인터페이스를 통해 t3에 연결됩니다. 따라서 t3은 방화벽을 시뮬레이션하고, t4는 대상이고, t1,t2는 패킷 폭풍을 생성하는 공격자를 재생합니다(192.168.4.199는 t4입니다).

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

t4는 게이트웨이와의 혼동, t4의 성능 문제 등을 피하기 위해 들어오는 모든 패킷을 삭제합니다. itraf에서 패킷 통계를 봅니다. 방화벽(t3)을 다음과 같이 구성했습니다.

  • 재고 3.2.0-31-일반 #50-Ubuntu SMP 커널
  • 커널 매개변수로 rhash_entries=33554432

  • sysctl은 다음과 같습니다:

    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

(t1+t2가 가능한 한 많은 패킷을 보낼 때 t3가 계속 실행되도록 많은 조정을 했습니다).

이러한 노력의 결과는 다소 이상합니다.

  • t1+t2는 각각 약 200,000개의 패킷/초를 전송합니다. 가장 좋은 경우 t4는 총 200k 정도를 확인하므로 패킷의 절반이 손실됩니다.
  • t3은 패킷이 콘솔을 통해 흐르고 있지만 콘솔에서 거의 사용할 수 없습니다(soft-irq 수가 많음).
  • 경로 캐시 가비지 수집기는 예측할 수 없으며 기본 설정에서 매우 적은 패킷/초(<50,000패킷/초)로 인해 압도됩니다.
  • 상태 저장 iptables 규칙을 활성화하면 t4에 도착하는 패킷 속도가 약 100,000패킷/초로 떨어지고 사실상 패킷의 75% 이상이 손실됩니다.

그리고 이것은 – 여기에 나의 주요 관심사가 있습니다 – 두 대의 오래된 P4 머신이 가능한 한 많은 패킷을 보내는 것과 관련하여 – 이는 인터넷상의 거의 모든 사람이 이것을 할 수 있어야 한다는 것을 의미합니다.

내 질문은 다음과 같습니다. 구성이나 테스트 설정에서 몇 가지 중요한 사항을 간과했나요? 특히 smp 시스템에 방화벽 시스템을 구축하기 위한 대안이 있습니까?

답변1

더 이상 라우팅 캐시가 없는 커널 >= 3.6으로 마이그레이션하겠습니다. 그러면 문제의 일부가 해결될 것입니다.

답변2

T3의 로깅 설정은 어떻게 되나요? 삭제된 패킷이 모두 기록되면 디스크 I/O가 원인일 수 있습니다.

테스트 환경이므로 T3 로깅을 끈 상태에서 테스트를 해볼 수 있습니다.

관련 정보