Проблема производительности iptables / conntrack в Linux

9

У меня есть тестовая установка в лаборатории с 4 машинами:

  • 2 старые машины P4 (t1, t2)
  • 1 Xeon 5420 DP 2,5 ГГц, 8 ГБ ОЗУ (t3) Intel e1000
  • 1 Xeon 5420 DP 2,5 ГГц, 8 ГБ ОЗУ (t4) Intel e1000

протестировать производительность брандмауэра linux, так как за последние месяцы нас укусила атака синодов. Все машины работают под управлением Ubuntu 12.04 64bit. t1, t2, t3 связаны через переключатель 1 ГБ / с, 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 и т. д. Я смотрю статистику пакетов в iptraf. Я настроил брандмауэр (t3) следующим образом:

  • 3.2.0-31-generic # 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

(Я много подправил, чтобы t3 работал, когда t1 + t2 отправляют как можно больше пакетов).

Результат этих усилий несколько странный:

  • t1 + t2 удается отправлять каждые около 200 тыс. пакетов / с. В лучшем случае t4 видит около 200 тыс., поэтому половина пакетов теряется.
  • t3 практически недоступен на консоли, хотя через него проходят пакеты (большое количество soft-irq)
  • сборщик мусора в кэше маршрутов далеко не предсказуем, и в настройках по умолчанию перегружено очень мало пакетов / с (<50 тыс. пакетов / с)
  • активация правил iptables с сохранением состояния приводит к тому, что скорость передачи пакетов t4 падает примерно до 100 тыс. пакетов / с, что приводит к потере более 75% пакетов.

И это - вот мое главное беспокойство - с двумя старыми машинами P4, отправляющими столько пакетов, сколько они могут - что означает, что почти каждый в сети должен быть в состоянии это сделать.

Итак, вот мой вопрос: я пропустил какой-то важный момент в конфигурации или в моей тестовой настройке? Есть ли альтернативы для построения системы брандмауэра, особенно в системах SMP?

linux firewall Тим
источник
Возможно, вы просто насыщаете сеть? Это объясняет некоторые потери пакетов.
Престон
Я так не думаю, поскольку сеть работает на скорости 1 Гбит / с, каждый из которых подключен через коммутатор hp 2848, управление потоком данных и переполнение кеша высокой нагрузки и маршрутизации на t3 указывают на то, что само t3 является слабым местом.
Тим

Ответы:

1

Я бы перешел на Kernel> = 3.6, который больше не имеет кеша маршрутизации. Это должно решить часть ваших проблем.

BatchyX
источник
0

Как настроена регистрация на T3? Если все пропущенные пакеты записаны, причиной может быть дисковый ввод-вывод.

Поскольку это среда тестирования, вы можете попробовать выполнить тестирование с отключенным ведением журнала T3.

Джон Сиу
источник