☰

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

tag-icon • tag-icon linux firewall
Проблема производительности Linux iptables / conntrack

У меня в лаборатории имеется тестовая установка с 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, поскольку за последние месяцы мы подверглись нескольким атакам syn-flood. Все машины работают под управлением 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?

решение1

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

решение2

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

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

Связанный контент