Проблема продуктивності iptables Linux / conntrack


9

У мене в лабораторії є тестова установка з чотирма машинами:

  • 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 брандмауера, оскільки в останні місяці нас покусало чимало атак синхронного потоку. Всі машини працюють на 64-бітній версії Ubuntu 12.04. 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-irqs)
  • збирач сміття маршрутного кешу аж ніяк не передбачуваний, і в налаштуваннях за замовчуванням переповнюється дуже мало пакетів / с (<50 к пакетів / с)
  • Активізація правильних iptables правил змушує швидкість передачі пакетів, що надходить на t4, приблизно до 100 к пакетів / с, ефективно втрачаючи більше 75% пакетів

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

Отже, тут виникає моє запитання: чи я не помічав якусь важливу точку в налаштуваннях або в тестовій установці? Чи є альтернативи для побудови системи брандмауера, особливо на smp-системах?


Можливо, ви просто насичуєте мережу? Це пояснило б деякі втрати пакету.
Престон

Я не думаю, що так, оскільки мережа знаходиться на частоті 1 Гбіт / с, кожна з яких підключена через комутатор hp 2848, контроль над потоком та перевантаження великого навантаження та кешу маршруту на t3 вказує на те, що саме t3 є слабким місцем.
час

Відповіді:


1

Я перейшов би до ядра> = 3.6, у якого більше немає кешу маршрутизації. Це має вирішити частину ваших проблем.


0

Як відбувається налаштування вашого журналу на T3? Якщо всі скинуті пакети реєструються, причина вводу / виводу диска може бути причиною.

Оскільки це тестове середовище, ви можете спробувати тест із вимкненим журналом T3.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.