Выдержит ли 50,000 новых соединений в секунду? Как проверить реальную производительность NGFW

В техническом паспорте вашего нового межсетевого экрана (NGFW) красуется цифра: «Производительность Threat Prevention — 10 Гбит/с». Вы уверены, что 5-гигабитный канал будет работать без проблем. Устанавливаете железо, запускаете рабочий трафик и... сеть «встает колом». Пользователи не могут открыть почту, кассовые терминалы зависают, видеоконференции рассыпаются. Что пошло не так?

Почему даташиты обманывают

Проблема в том, что пропускная способность — это маркетинговая метрика. Вендоры измеряют ее в идеальных лабораторных условиях: на крупных UDP-пакетах (1518 байт), без шифрования, с минимальным набором правил безопасности. Это как замерять скорость автомобиля на идеально ровной трассе без пассажиров и груза.​

В реальной корпоративной сети «убийцами» производительности являются совсем другие параметры: количество одновременных сессий, скорость установки новых подключений и нагрузка на процессор при дешифровке HTTPS-трафика.​

Исследования показывают, что включение SSL-инспекции может снизить пропускную способность на 50-80%, а скорость установки новых соединений падает на 92% (ссылка: https://www.corsa.com/wp-content/uploads/PDFs/Corsa_UC-Close_the_SSL_Inspection_Gap.pdf). Это означает, что ваш «10-гигабитный» фаервол в реальности может обрабатывать менее 2 Гбит/с зашифрованного трафика.​

История из практики: ритейлер перед «черной пятницей»

Представьте крупного ритейлера, который переходит на новое отечественное NGFW-решение в рамках импортозамещения. ИТ директор перед финальным утверждением хочет быть уверен: выдержит ли оборудование пиковую нагрузку во время распродажи?

При профессиональном тестировании создается реалистичный микс трафика, который регулярно «кладет» оборудование, номинально подходившее по характеристикам:​

Первый удар: 100% зашифрованный трафик. Современный интернет-трафик более чем на 90% состоит из HTTPS. При включении полной SSL-инспекции с современными шифрами (TLS 1.3, ECDHE) процессоры фаервола начинают задыхаться от криптографических операций. Каждое новое соединение требует расшифровки, проверки и повторного шифрования — это сотни тысяч операций в секунду.​

Второй удар: «слоны» и «мыши». В реальной сети одновременно идут разнородные потоки. С одной стороны, огромные «слоны»: резервное копирование баз данных, синхронизация хранилищ, передача видеофайлов. С другой — мелкие «мыши»: платежные транзакции, VoIP-звонки, запросы к API. Когда несколько «слонов» забивают буферы сетевых интерфейсов, возникает эффект bufferbloat — критически важные мелкие пакеты начинают отбрасываться, хотя канал загружен лишь частично.​

Третий удар: лавина новых сессий. Вендоры любят хвастаться максимальным количеством одновременных сессий. Но реальная проблема в скорости открытия новых соединений (Connections Per Second). Когда начинается распродажа и тысячи покупателей одновременно заходят на сайт, фаервол должен обработать волну новых TLS-хендшейков. Если CPU не справляется, сайт просто не открывается для новых пользователей.

Как правильно тестировать

Не доверяйте цифрам из презентаций. Единственный способ узнать правду — стресс-тест в контролируемой среде с реалистичным профилем трафика:​

· Смешивайте «слонов» и «мышей» в одном потоке

· Включайте SSL-дешифровку на максимум

· Генерируйте лавину новых сессий

· Используйте актуальные базы угроз и сигнатуры атак

Только такой подход покажет реальный запас прочности вашей инфраструктуры. Час тестирования в лаборатории сэкономит дни простоя в реальных условиях и репутационные потери перед клиентами.

—-

Подписывайтесь на наш канал в ТГ, где мы регулярно публикуем материалы про нагрузочное и функциональное тестирование ИТ/ИБ решений и инфраструктуры.