Когда сетевому или DevOps-инженеру нужно проверить новый сетевой интерфейс, коммутатор или облачный канал, рука машинально тянется к проверенной утилите iperf3. Ты поднимаешь сервер, запускаешь клиент в несколько потоков и радуешься красивым цифрам: 10, 25 или 40 Гбит/с. Канал чист, тест пройден.
Но иллюзия рассеивается, как только между серверами встаёт межсетевой экран с контролем состояний (Stateful Firewall), транслятор адресов (NAT) или программный маршрутизатор. Приходит реальный трафик — сотни микросервисов, лавина коротких HTTP-запросов или всплеск нагрузки, — и сеть захлёбывается, теряя пакеты при загрузке канала едва на 5%.
Почему пропускная способность не равна устойчивости
Утилита iperf3 решает одну задачу: прокачивает объём данных через считанные долгоживущие TCP-сессии. Для простого свитча это показатель. Но для stateful-файрвола передача гигабайта по готовому сокету почти бесплатна.
Реальные узкие места шлюзов безопасности кроются в других метриках:
- Частота новых соединений (Connections Per Second, CPS): на каждый пакет TCP SYN фаервол выполняет рукопожатие, сверяет правила ACL и создаёт запись в таблице состояний.
- Лимит таблицы состояний ядра (
netfilter conntrack): память ядра под сессии ограничена. При переполнении таблицы сетевой стек начинает молча отбрасывать новые пакеты (drop). - Сброс неактивных сессий (Idle Connection Drop): ради экономии памяти фаерволы принудительно вычищают «уснувшие» сессии, из-за чего зависают SSH-подключения и рвутся пулы к базам данных.
Утилита iperf3 здесь бессильна: она не открывает тысячи соединений в секунду, монополизирует порт под одного клиента и падает при любой ошибке без внятного отчёта.
Архитектура zero-copy на io_uring и сценарии аудита
Инженеры дистрибутива безопасности IPFire создали специализированный инструмент — fireperf. Он написан на C с нуля под современное ядро Linux:
- Сетевой цикл построен на
io_uring(с откатом наepoll). - Данные передаются в режиме zero-copy через системный вызов
splice, не гоняя пакеты между ядром и памятью пользователя. - Для передачи 1 ГиБ данных fireperf тратит всего 0.071 секунды CPU, тогда как
iperf3 -Zтребует 0.153 с, а обычныйiperf3— 0.505 с (в 7 раз больше!). Тест нагружает именно файрвол, а не процессор генератора нагрузки. - Сервер fireperf принимает параллельные тесты сотен клиентов на одном порту, удерживая темп свыше 230 000 открытий и закрытий сессий в секунду.
Установка на Debian/Ubuntu выполняется из официального репозитория:
# Добавляем репозиторий fireperf
sudo curl -o /usr/share/keyrings/fireperf.asc https://repo.ipfire.org/debian/fireperf/master/fireperf.asc
echo "deb [signed-by=/usr/share/keyrings/fireperf.asc] https://repo.ipfire.org/debian/fireperf/master $(. /etc/os-release && echo $VERSION_CODENAME) main" | sudo tee /etc/apt/sources.list.d/fireperf.list
sudo apt update && sudo apt install -y fireperf
Стресс-тестирование фаервола запускается гибкими сценариями:
# 1. Запуск тестового сервера для параллельных клиентов
fireperf --server
# 2. Проверка предельного CPS (10 000 соединений/сек с немедленным закрытием)
fireperf --client 192.0.2.1 --rate 10000 --close
# 3. Имитация веб-трафика (запрос 100 байт, ответ 10 КБ, 5000 транзакций/сек)
fireperf --client 192.0.2.1 --exchange 100:10000 --rate 5000
# 4. Проверка удержания 100 000 неактивных сессий на устойчивость conntrack
fireperf --client 192.0.2.1 --parallel 100000 --keepalive
При сбоях fireperf чётко разделяет активный сброс RST сервером, тихий тайм-аут из-за переполнения conntrack и локальную нехватку портов, экономя часы ночного дебага.