Выбор NGFW под реальный трафик: оценка производительности

Почему «гигабиты в брошюре» часто не про вашу сеть

В спецификациях NGFW (межсетевых экранов нового поколения) обычно выделяют три цифры: throughput (скорость), число одновременных сессий и CPS (новые соединения в секунду). Проблема в том, что эти значения часто получены в условиях, далеких от реальной сети: крупные пакеты, простые правила, минимум проверок, без шифрования и без «тяжелых» профилей безопасности.

Как только вы включаете IPS, антивирус, контроль приложений или SSL/TLS-инспекцию, устройство перестает быть просто «быстрым маршрутизатором». Оно начинает разбирать трафик, собирать потоки, сравнивать их с сигнатурами, применять политики, писать логи, а иногда еще и расшифровывать TLS, чтобы проверить содержимое, а затем шифровать обратно. На практике это означает, что «гигабиты в брошюре» легко превращаются в совсем другие цифры.

Проблемы с производительностью редко выглядят как «все упало». Чаще это набор симптомов: растет задержка, появляются микропотери, VoIP и видеосвязь начинают заикаться, VPN становится нестабильным, пользователи жалуются на «медленный интернет». Тревожный признак - когда администратор вынужден временно отключать инспекцию или упрощать политики, чтобы «вернуть скорость».

Из-за веры в паспортные гигабиты часто принимают решения, которые потом дорого исправлять. Например, берут модель «впритык» без запаса на рост трафика и правил, планируют включить SSL-инспекцию «позже», но железо уже не тянет, ориентируются на среднюю загрузку канала и пропускают пики и CPS. Еще одна типовая ошибка - тестировать «легкий» трафик на пилоте, а затем удивляться в проде.

Если вам важен выбор NGFW под реальный трафик, относитесь к цифрам из даташита как к отправной точке, а не к гарантии. Реальная оценка начинается там, где вы повторяете свои условия: свои приложения, свои пики, свои политики безопасности и, особенно, свою долю TLS-трафика.

Что именно «съедает» производительность в NGFW

Паспортные цифры часто показывают скорость «голой» фильтрации по IP и портам. Но в реальной сети NGFW обычно работает с набором функций: контроль приложений, IDS/IPS, антивирус, URL-фильтрация и иногда песочница. Каждый модуль добавляет вычисления и очереди обработки, поэтому «10 Гбит/с firewall throughput» легко превращаются в 1-3 Гбит/с при полном наборе функций. Именно поэтому выбирать устройство по одной строке в брошюре опасно.

Где уходит CPU и почему дело не только в «сигнатурах»

Самые тяжелые операции связаны с тем, что устройство должно понять, что именно перед ним, а не просто пропустить пакеты.

Обычно ресурсы тратятся на:

• сборку сессий и реассемблирование потоков (особенно при большом числе коротких соединений);
• распаковку и разбор содержимого (архивы, Office/PDF, вложения);
• проверки IPS: сопоставление с сигнатурами и дополнительные контекстные проверки;
• классификацию приложений и URL, когда нужно заглянуть глубже заголовков.

Нагрузка растет не только от «ширины канала», но и от структуры трафика. 500 Мбит/с из крупных скачиваний и 500 Мбит/с из тысяч коротких HTTPS-сессий нагружают NGFW по-разному.

Почему важны задержка и потери, а не только «скорость»

Даже если NGFW показывает нужные мегабиты в тесте, пользователи могут жаловаться на «подвисания». Причина часто в росте задержки и микропотерях: очереди переполняются в пике, даже если средняя загрузка выглядит нормальной.

Пример: одновременно стартуют видеозвонки, синхронизация облака и обновления. Канал может быть загружен лишь на 60-70%, но NGFW упирается в число сессий и глубину проверок. В результате критичные приложения первыми ощущают задержку.

Есть еще одна ловушка - рост правил и объектов. Чем больше политик, групп, исключений, профилей безопасности и маршрутов, тем больше проверок выполняется на каждую новую сессию. Поэтому на пилоте важно тестировать не «одну красивую политику», а конфигурацию, близкую к будущей боевой.

SSL-инспекция: самый частый источник сюрпризов

SSL/TLS-инспекция (часто говорят «расшифровка HTTPS») превращает NGFW из фильтра по заголовкам в систему, которая должна расшифровать поток, прогнать его через правила (IPS, антивирус, URL-фильтр, DLP - что включено), а затем снова зашифровать. Это тяжелее обычной фильтрации: добавляются криптографические операции, обработка сессий и хранение состояния для большого числа соединений.

Важно различать два режима. Outbound-инспекция (трафик пользователей в интернет) чаще дает самый большой объем работы: много сайтов, много коротких соединений, постоянно новые TLS-сессии. Inbound-инспекция (входящий трафик к вашим сервисам) обычно стабильнее по профилю запросов, но требования к задержкам и отказоустойчивости выше, а ошибка настройки больнее бьет по доступности.

На производительность влияют детали, которых «гигабиты в брошюре» не показывают:

• доля HTTPS и число новых соединений в секунду (CPS);
• версии TLS и наборы шифров, а также логика исключений;
• размер и сложность цепочек сертификатов, кэширование и частота проверок;
• какие проверки включены после расшифровки (IPS и антивирус обычно тяжелее простого контроля приложений).

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

Чтобы пилот был честным, заранее решите, что вы действительно будете расшифровывать, а что - осознанно обходить. Например, можно включить инспекцию для веб-серфинга и загрузок, но сделать исключения для банковских кабинетов и некоторых корпоративных SaaS по требованиям комплаенса. Затем измеряйте не только Mbps, но и задержку, CPS, долю разрывов TLS-сессий и загрузку CPU в пиковые часы.

Какие параметры трафика важнее, чем ширина канала

Фраза «у нас канал 1 Гбит/с» звучит понятно, но для NGFW это почти ничего не говорит. Межсетевой экран считает не только мегабиты, но и то, сколько соединений у вас одновременно, как часто они создаются, какие приложения внутри, и нужно ли их глубоко проверять (IPS, антивирус, контроль приложений, SSL-инспекция).

Смешанный трафик всегда тяжелее «ровного». В одном и том же офисе одновременно идут видеозвонки, доступ в облака, VPN в филиалы, веб-серфинг, удаленный доступ и синхронизация файлов. По сумме мегабитов это может быть «всего» 300-400 Мбит/с, а по сложности обработки для NGFW - как полноценный гигабит и больше.

Что в трафике реально нагружает NGFW

Короткие и частые сессии обычно опаснее для производительности, чем один длинный поток. Веб-страницы, мобильные приложения и многие облачные сервисы создают много небольших запросов. А бэкапы и обновления чаще дают длинные потоки, которые проще «вести», даже если они тяжелые по полосе.

Для оценки нагрузки полезно смотреть на метрики, которые лучше описывают реальность:

• CPS (connections per second) - сколько новых соединений в секунду;
• concurrent sessions - сколько соединений одновременно «в работе»;
• средний размер пакета (маленькие пакеты дают больше накладных расходов);
• доля трафика, проходящего через «тяжелые» профили (IPS/SSL/антивирус);
• баланс направлений: «север-юг» (интернет) и «восток-запад» (между сегментами, филиалами, VPN).

Пики важнее среднего

Средняя загрузка за день часто успокаивает и вводит в ошибку. NGFW должен выдерживать пики: утро (вход сотрудников, почта, мессенджеры), закрытие дня (выгрузки, отчеты), массовые рассылки, плановые апдейты, а иногда и всплески из-за инцидентов.

Пример: в 9:30 одновременно открывают почту и CRM, идет видеосвязь с филиалами по VPN, а в фоне стартуют обновления рабочих станций. Полоса может вырасти не драматично, но CPS и число одновременных сессий подскакивают кратно. Если на пилоте вы проверяете только «прокачку» гигабита iperf, вы тестируете не то, что будет болеть в реальной сети.

Подготовка к пилоту: что собрать до включения оборудования

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

Сначала зафиксируйте сценарии, которые реально живут в сети. Частая ошибка - проверить только выход в интернет и забыть про межсегментный трафик, доступ в дата-центр и VPN. Если есть филиалы, удаленные пользователи, отдельные зоны (офис, серверная, Wi-Fi, гостевая сеть), для каждой зоны нужны свои ожидания по задержке и доступности.

Дальше составьте список функций, которые точно планируете включить в бою. Если на пилоте вы тестируете «чистый фаервол», а потом добавляете IPS и SSL-инспекцию, пилот теряет смысл. Выберите конкретный набор политик: какие категории веб-фильтра включаем, какие профили IPS, будет ли проверка вложений, нужен ли анализ неизвестных файлов (если вендор его предлагает).

Перед запуском определите критерии успеха. Они должны быть измеримыми, а не «чтобы не тормозило»: допустимая дополнительная задержка на ключевых приложениях, отсутствие заметных разрывов VPN, стабильная работа без роста очередей и ошибок, приемлемая доля потерь (drop rate) в пике.

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

• NetFlow/sFlow за типичную неделю (пики, средние, топ приложений и направлений);
• статистика текущего шлюза (CPU/память, сессии, CPS, объемы по интерфейсам);
• логи по инцидентам и блокировкам (что ловится, какие ложные срабатывания уже известны);
• карта маршрутов и зон (NAT, межсегмент, критичные сервисы);
• «золотой список» приложений для проверки (5-10 самых важных для бизнеса).

Заранее договоритесь о правилах пилота: он идет на реальном трафике (или на зеркале, но с теми же профилями безопасности), замеры делаются в одинаковые периоды времени, а любые «облегчения» (выключить SSL, упростить IPS) фиксируются как отдельный сценарий, а не как финальный результат.

Пошагово: как провести корректный пилот NGFW

Пилот нужен не для того, чтобы увидеть максимальные цифры, а чтобы понять, что будет в вашей сети после включения IPS и SSL-инспекции.

1) Соберите пилот так, как будет в эксплуатации

Сначала решите, как включать устройство. Зеркалирование удобно и безопасно, но не показывает реальной задержки и поведения при сбоях. Включение в разрыв дает честную картину, а параллельная схема помогает сравнить маршруты и политики.

Перенесите ключевые правила и маршрутизацию без «косметики». Частая ошибка - упростить политики на время теста или исключить часть подсетей. В итоге пилот получается слишком легким и вводит в заблуждение.

2) Включайте функции поэтапно и фиксируйте, что изменилось

Практичный порядок:

• базовая фильтрация и NAT (чтобы трафик пошел);
• контроль приложений и базовые пользовательские политики;
• IPS на ключевых направлениях (интернет, межсегмент);
• SSL-инспекция сначала точечно (1-2 группы), затем шире;
• дополнительные проверки (антивирус, sandbox, DNS-фильтр), если они планируются.

Между этапами держите одинаковое окно наблюдения (например, 1-2 рабочих часа), чтобы сравнение было честным. Параллельно прогоняйте типичные нагрузки: видеоконференции, CRM/ERP, файлообмен, почта, резервные копии, массовые обновления ОС. Лучше запускать их в привычное время (утро, обед, конец дня), когда профиль трафика отличается.

Чтобы результат можно было защитить цифрами, заранее договоритесь, какие метрики снимаете и где. Обычно фиксируют задержку и потери, CPU и память, число активных сессий, CPS, скорость установления VPN и время открытия типовых сайтов.

На выходе должна получиться таблица «было/стало» по каждому этапу и вывод по сайзингу: какой режим проходит без деградации, где появляются пики, и какой запас остается на рост трафика.

Типовые ошибки и ловушки при оценке производительности

Самая частая причина провала пилота проста: измеряют не то, что будет работать в проде. В итоге NGFW «держит гигабиты» в тесте, а после включения IPS и SSL-инспекции начинает терять пакеты и увеличивает задержку.

Чаще всего это выглядит так:

• гоняют только «чистый» throughput (например, iperf) и игнорируют реальные проверки и логирование;
• делают «красивые» упрощенные политики с широкими разрешениями и исключениями;
• тестируют в спокойное время и не ловят тяжелые периоды (апдейты, видеозвонки, бэкапы);
• забывают про VPN и стоимость шифрования/расшифровки;
• смотрят только на «скорость», игнорируя задержку, потери и стабильность под нагрузкой.

Есть и тихая ловушка: «сайзинг впритык». Сегодня все работает, а через полгода добавили новые сервисы, выросла доля TLS, появились дополнительные правила IPS - и запас исчез.

Минимальный набор для контроля обычно такой: средняя и 95-й процентиль задержки на ключевых направлениях, доля drops/ошибок и признаки перегруза (очереди, рост CPU, исчерпание сессий), скорость установления сессий и максимум одновременных сессий в пиковые часы.

Короткий чеклист: достаточно ли мощности именно вам

Быстрый тест «качать файл на максимальной скорости» почти ничего не говорит о работе с IPS, SSL-инспекцией и реальными сессиями пользователей.

Если по двум-трем пунктам ниже нет уверенных цифр, риск недосайзинга высокий:

• зафиксированы пики по concurrent sessions и CPS, а не только средняя загрузка канала;
• проверена работа при включенных «тяжелых» профилях именно в той комбинации, которая будет постоянной;
• SSL-инспекция прогнана на реальных сценариях (браузинг, порталы, обновления, мессенджеры, видеосвязь), а не на одном тестовом сайте;
• измерены задержка и потери до и после включения политик безопасности (latency, packet loss, jitter);
• понятен запас на 12-24 месяца по CPU, памяти и таблицам сессий.

Отдельно проверьте то, что чаще ломается из-за инспекции и фильтрации: интернет-банк, госресурсы, медицинские системы, EDI, порталы с клиентскими сертификатами. Важно не только «открывается/не открывается», а насколько стабильно работает в течение дня.

Мощности «достаточно», если в пиковые часы сохраняется запас по ресурсам, критичные сервисы работают без сюрпризов, а задержка не ухудшает пользовательский опыт.

Пример из практики: пилот в офисе с филиалами и VPN

Компания на 400 сотрудников: головной офис, 6 филиалов, общий интернет-канал и постоянные VPN-туннели между площадками. В рабочее время идут видеозвонки, облачные сервисы, почта, обновления, плюс бухгалтерия и CRM. «Канала хватает», но безопасность хотят усилить: включить IPS везде и SSL-инспекцию для части категорий (например, неизвестные сайты и файлообменники), не трогая банки и госресурсы.

На старте пилота NGFW ставят в разрыв в головном офисе и зеркалят трафик филиалов через VPN, чтобы тест был ближе к реальности. На первом этапе включают только базовые функции, чтобы получить «чистую» точку отсчета, а затем добавляют нагрузки по одной.

Пару дней замеряют профиль трафика без тяжелых проверок, затем включают IPS на ключевых правилах, и только после этого добавляют SSL-инспекцию по выбранным категориям. Замеры делают в пиковые часы (обычно 10:30-12:00 и 15:00-17:00), а не ночью.

Команда фиксирует не только мегабиты, но и симптомы узкого места: CPS на вебе и при массовых обновлениях, рост очередей и drops на интерфейсах, увеличение задержки (особенно заметно на видеосвязи), загрузку CPU по IPS и SSL, поведение при всплесках (провалы по throughput и время восстановления).

В этом кейсе «сюрприз» пришел не от общего трафика, а от всплесков CPS и от SSL: после включения расшифровки на части пользователей задержка выросла, а CPU упирался в пик, хотя средняя загрузка выглядела терпимо. На графиках это видно как короткие провалы скорости и рост времени ответа, когда начинается массовая загрузка вложений и обновлений.

Итог - закладывают запас по мощности, а функции распределяют по политикам, а не «включают все всем»: SSL-инспекцию оставляют там, где она дает максимум пользы, IPS делают строже для входящего и межсегментного трафика, мягче для доверенных направлений, а для филиалов вводят отдельные правила и лимиты, чтобы один офис не «съедал» ресурсы.

Если пилот сопровождает интегратор, полезно заранее согласовать, какие метрики считаются «красной зоной», чтобы решение принималось по цифрам. В Казахстане с такими задачами работает GSE.kz как системный интегратор: от методики пилота и замеров до внедрения и дальнейшей поддержки.

Следующие шаги: как зафиксировать сайзинг и перейти к внедрению

После пилота важно не просто сказать «работает», а закрепить результат в цифрах и условиях, при которых вы их получили.

Переведите ожидания в измеримые требования. Опишите ключевые сценарии (офисный интернет, VPN, доступ в облака, межсегментный трафик), включенные функции (IPS, SSL-инспекция, антивирус, контроль приложений) и 3-5 KPI, чтобы не утонуть в деталях: минимальная стабильная пропускная способность в час пик при включенных профилях защиты, верхняя граница задержки для критичных приложений, допустимая доля отброшенных сессий и разрывов туннелей, а также запас по CPU и памяти в пике.

Зафиксируйте методику. Отчет должен быть устроен так, чтобы любой участник мог повторить измерения и получить сопоставимые цифры: какие политики включены, какие исключения сделаны (например, часть доменов без расшифровки), какой набор тестов прогнали, где сняты метрики (на NGFW и на клиентах), и что считалось «нормой». Если два решения тестировались по разным правилам, сравнение будет нечестным.

Заложите запас и путь масштабирования. Не ориентируйтесь на нагрузку «сегодня в среднем». Оцените рост пользователей, удаленки, долю шифрованного трафика и появление новых сервисов. Часто разумнее выбрать модель с запасом 20-30% и заранее решить, как будете расширяться: кластер, HA, разделение ролей (например, отдельный узел под SSL-инспекцию или под VPN).

Перед внедрением полезно оформить короткий пакет артефактов: итоговый сайзинг с допущениями (пиковый трафик, доля TLS, набор функций), матрица политик и исключений для SSL-инспекции, план по HA и тест отказа, план внедрения по этапам и критерии приемки.

Если внутри команды не хватает времени или опыта, подключайте интегратора. Задача не в том, чтобы «померить гигабиты», а в том, чтобы получить воспроизводимую методику и финальный сайзинг, который выдержит реальную нагрузку.