Производительность Check Point Quantum 6200/6400: тест и рост правил

Что вы на самом деле измеряете: скорость или устойчивость

Оценивая производительность Check Point Quantum 6200/6400, важно разделять два понятия: «быстро на стенде» и «стабильно в реальной сети». Включенные профили безопасности (IPS, Anti-Bot, Anti-Virus, URL Filtering, Application Control) меняют картину сильнее, чем ожидают. Часть трафика уходит в глубокую проверку, растет нагрузка на CPU, память и подсистему логирования, а «пиковая пропускная способность» превращается в «нормальную при ваших настройках».

Для бизнеса обычно важнее не максимальный throughput в гигабитах, а устойчивость: чтобы в час пик не выросла задержка, не появились потери пакетов и не просели критичные приложения (телефония, видеоконференции, ERP, платежи).

Держите вместе три метрики:

• Throughput: сколько трафика проходит при конкретных профилях и конкретном типе трафика.
• Задержка (latency): как меняется время прохождения пакета под нагрузкой.
• Потери пакетов: появляются ли дропы, ретрансляции TCP и жалобы пользователей.

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

То, что на тесте «забывают», а в проде почти всегда включают: подробное логирование (особенно в SmartEvent или внешний SIEM), IPS в режиме Prevent, site-to-site VPN и TLS inspection. Простой пример: днем у вас 2 Гбит/с «видимого» HTTPS. После включения инспекции устройство начинает расшифровывать и анализировать содержимое, запас по ресурсам исчезает, хотя график трафика почти не меняется.

Какие вводные собрать до расчета и теста

Чтобы оценка производительности Quantum 6200/6400 совпала с реальностью, сначала зафиксируйте, какие задачи шлюз будет выполнять в проде. Если на стенде вы измерите только «скорость по TCP», а затем включите IPS и инспекцию, цифры не сойдутся.

Начните с перечня профилей безопасности и их режимов. Важны детали: какие блейды активны, какой профиль выбран (Recommended, Strict, Custom), какие исключения допустимы, какие категории и сигнатуры должны работать всегда.

Отдельно разберите TLS inspection. Это главный множитель нагрузки, потому что меняется сам характер обработки трафика. Достаточно зафиксировать два параметра: какая доля трафика будет расшифровываться (в процентах) и какая часть этого трафика чувствительна к задержкам (например, ВКС или банковские терминалы). Если пока нет ясности, соберите статистику по топ-доменам, приложениям и SNI хотя бы за несколько рабочих дней.

Дальше опишите профиль трафика: кто инициатор, куда ходит, какие пики. Один и тот же «1 Гбит/с» может быть легким (длинные потоки, мало сессий) или тяжелым (много коротких соединений и высокий CPS).

Вводные удобно свести в короткий список:

• Пики по трафику и по новым сессиям (в рабочие часы и в резервные окна).
• Доли потоков: офисные пользователи, серверы, филиалы, удаленные сотрудники, межсерверный трафик.
• Критичные приложения и допустимая задержка (ERP, ВКС, интернет-банк, медицинские сервисы).
• Политика логирования: что пишем, куда отправляем, срок хранения, нужны ли подробные логи для URL/App.
• Сетевые особенности: NAT, VPN, асимметрия маршрутизации, наличие DMZ.

Логирование часто недооценивают. Если включить подробные логи для URL Filtering и App Control и отправлять их в централизованное хранилище, нагрузка может сместиться с CPU на диск и очереди логов, особенно в пиковые часы.

Пример, который помогает «приземлить» тест: 800 пользователей в головном офисе, 12 филиалов через VPN и ЦОД с ERP и ВКС. Пики активности - в 11:00 и 16:00, ночью идут бэкапы. Для стенда нужны именно эти окна поведения, а не «среднее за день», иначе выбор между 6200 и 6400 получится случайным.

Сценарии нагрузки: как описать трафик без догадок

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

Опирайтесь на подтвержденные данные за 2-4 недели (лучше месяц с типичной нагрузкой): графики по интерфейсам, NetFlow/sFlow, отчеты с текущего межсетевого экрана, статистику по VPN. Важно фиксировать не только среднее, но и короткие пики: именно они часто «съедают» запас по CPU и таблицам сессий.

Минимальный набор, который стоит собрать:

• Средний и пиковый трафик по направлениям (интернет, филиалы, ЦОД, облака).
• Одновременные сессии и скорость их создания (CPS), хотя бы оценочно.
• Типичный характер потоков: много мелких запросов (веб, DNS, API) или немного крупных (бэкапы).
• Доля east-west в ЦОД и межсегментные проходы через политики.
• VPN: сколько site-to-site туннелей и сколько удаленных пользователей одновременно.

Дальше не ограничивайтесь «одним тестом». Лучше описать 3-5 сценариев, где меняется не только Mbps, но и «характер» трафика: рабочий день (короткие веб-сессии и SaaS), ночное окно (репликации и бэкапы), пик понедельника (массовые логины и рост CPS), авария канала (трафик переезжает на резерв).

Отдельно зафиксируйте отказоустойчивость. В Active-Standby часть ресурсов уходит на синхронизацию, а при failover нагрузка падает на одно устройство. В Active-Active важно понимать, как реально распределится трафик и какие потоки нельзя разделить равномерно. Если эти детали не описать заранее, результаты будут «красивыми», но бесполезными для выбора модели.

Пошаговый подход к нагрузочному тесту

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

Подготовка стенда

Перед запуском зафиксируйте условия, максимально близкие к боевым, особенно если сравниваете 6200 и 6400.

• Соберите эталонную политику: реальные сети, NAT, VPN, объекты, исключения, порядок правил.
• Включите только те профили безопасности, которые планируются в проде, и в тех же режимах.
• Подготовьте источник нагрузки: генератор трафика или стенд из реальных серверов и клиентов, чтобы были «живые» сессии и разные протоколы.
• Зафиксируйте версию ПО, параметры логирования, настройки TLS inspection.
• Определите точки контроля: где измеряете задержку и потери (до/после FW, на клиенте, на сервере).

Прогоны и замеры

Двигайтесь от простого к сложному, чтобы увидеть «цену» каждой функции.

• Прогон 1: базовый трафик без инспекций (контрольный уровень, чтобы понять потолок железа и стенда).
• Прогон 2: тот же профиль трафика, но с включенными профилями безопасности.
• На каждом прогоне снимайте throughput, latency, CPU и память, drops, заполнение таблиц сессий, ошибки интерфейсов.
• Отдельно проверьте «тяжелые» случаи: много коротких сессий (веб), долгие сессии (RDP/VDI), шифрованный трафик.
• Зафиксируйте момент деградации: при каком уровне трафика или числе сессий растет задержка или начинаются потери.

Затем повторите тест с логированием «как в жизни» и добавьте усложнение политики (например, +30-50% правил). Проверьте, что время установки сессий и задержка не выходят за SLA.

Как учесть профили безопасности и их стоимость по ресурсам

Главная ошибка в sizing - мерить «голую» пропускную способность, а потом включать профили безопасности и удивляться падению. Для реальной оценки 6200/6400 полезно считать стоимость функций по отдельности и в связке, потому что они конкурируют за CPU, память и ускорители.

Как посчитать «цену» профилей

Начните с базовой точки: трафик с теми же маршрутами и NAT, но без Threat Prevention. Затем включайте функции по одной и фиксируйте, что меняется: максимальная скорость, задержка, загрузка CPU, количество одновременных соединений и CPS.

Чаще всего больше всего «стоят»:

• IPS: Prevent почти всегда тяжелее Detect. Чем шире профиль и меньше исключений, тем выше нагрузка. После обновлений сигнатур полезно делать короткий контрольный прогон.
• Threat Prevention: проверьте, что реально включено в вашем наборе блейдов и политике. Часто часть проверок держат «на всякий случай», хотя по рискам достаточно точечного охвата критичных сегментов.
• TLS inspection: имеет смысл там, где риск выше (почта, веб-сервисы, SaaS). Для тяжелых потоков (бэкапы, большие загрузки) обычно нужны точечные исключения, иначе ресурсы уходят на расшифровку без практической пользы.
• URL Filtering и App Control: нагрузка растет, когда вы реально используете много категорий и активные правила, а не просто «держите блейд включенным».
• Логирование: подробные логи (особенно на Accept) увеличивают нагрузку и трафик до лог-сервера. Заранее решите уровень детализации, частоту событий и место хранения.

Что часто забывают

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

Расчет роста правил на 3 года: простая методика

Чтобы не промахнуться с запасом по мощности, прогнозируйте не только трафик, но и рост политики. На практике рост правил, объектов и объема логов часто «съедает» запас и бьет по производительности при включенных профилях безопасности.

Считайте рост отдельно по четырем корзинам: правила доступа, NAT, объекты (hosts, сети, сервисы) и группы. Динамика разная: объекты и группы часто растут быстрее из-за новых систем, а правила - из-за исключений и «временных» доступов, которые остаются надолго.

Шаги расчета (15-30 минут на черновик)

1. Зафиксируйте текущее состояние: число правил Access Control и NAT, количество объектов и групп, средний объем логов в день.
2. Опишите драйверы роста на 3 года: новые сегменты, филиалы, сервисы, подрядчики, миграции в ЦОД или облако, внедрение TLS inspection.
3. Задайте темп: базовый прирост в месяц и отдельные проектные «скачки» (миграции, запуск филиалов, новые системы).
4. Учтите усложнение: доля правил-исключений, рост TLS-bypass, увеличение детализации логов.
5. Привяжите каждую корзину к сценарию нагрузки: сколько новых потоков и событий появится из-за изменений.

Дальше сделайте три сценария и посчитайте итог на конец каждого года:

• Консервативный: +1-2 правила в месяц, +10% объектов в год, без крупных проектов.
• Реалистичный: +3-6 правил в месяц, 1-2 проектных скачка в год, +20-30% объектов в год.
• Пиковый: +8-12 правил в месяц, 3-4 скачка в год, резкий рост TLS inspection и логов.

Как «перевести» рост правил в нагрузку: больше правил и объектов означает больше проверок на совпадение, чаще используются группы, растет число сессий, проходящих через App Control/IPS/AV, и увеличивается объем логов. Поэтому в тест закладывайте не только Mbps, но и рост match, CPS, одновременных сессий и логирования.

Как интерпретировать результаты и выбрать 6200 или 6400

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

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

На что смотреть в отчете теста

Фиксируйте не только throughput, но и то, чем он оплачивается:

• CPU в пике (полезнее 95-99 перцентили, чем среднее).
• Latency под нагрузкой и при всплесках новых сессий.
• Одновременные сессии и скорость их установления (connection rate).
• Память и ее рост при включенных профилях.
• Подсистема логирования: очереди, просадки при повышении детализации.

Если упираетесь в CPU, чаще всего дороже всего обходятся IPS/Anti-Bot/Threat Emulation и особенно TLS inspection.

Как принять решение

Сделайте дополнительный прогон: увеличьте долю трафика с TLS inspection (например, с 20% до 50% или до целевого значения) и посмотрите, как меняются CPU и задержка. Если запас по CPU в пике становится меньше 30-40% или latency начинает заметно расти, переход на 6400 обычно оправдан.

Пример: при текущей политике 6200 держит пик, но при расширении TLS inspection CPU уходит за 85-90%, а задержка заметно растет. Это сигнал, что через год-два (рост правил, больше шифрования, обновления сигнатур и версий) устройство будет работать «на грани». В такой ситуации либо выбирайте 6400, либо снижайте «стоимость» политики: сужайте scope TLS inspection, убирайте лишние логи, делайте исключения для низкорисковых направлений.

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

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

Ошибки, которые ломают расчет

• Сравнивают максимальный throughput «в лоб», не учитывая, что IPS, Anti-Bot, URL Filtering и TLS inspection снижают пропускную способность и поднимают задержку.
• Тестируют синтетический трафик (один размер пакетов, один протокол, без шифрования), а в проде получают смесь: видеосвязь, SaaS, бэкапы, короткие сессии, тяжелый HTTPS.
• Не считают стоимость логирования: подробные логи, доставка в хранилище, ретеншн и отчеты упираются в I/O и CPU. В итоге «проседает» не фильтрация, а запись и обработка событий.
• Смешивают требования филиалов и ЦОД в один усредненный профиль. У филиала часто много коротких сессий и VPN, у ЦОД - крупные потоки и east-west. Средние значения скрывают пики.
• Планируют рост только по числу правил, но не по связанным сущностям: объекты, группы, исключения, NAT, маршруты, VPN-сообщества. Политика усложняется, и на каждый пакет растет число проверок.

Небольшой пример

Компания включает TLS inspection для части пользователей и постепенно добавляет исключения для банков, гос-порталов и внутренних сервисов. Через год правил стало на 20% больше, а объектов и исключений - в 2 раза больше. На тесте «по правилам» все выглядело нормально, а в реальности выросла нагрузка на сопоставление и на обработку логов: CPU постоянно высокий, задержка плавает.

Чтобы не попасть в эту ловушку, фиксируйте отдельно: профиль трафика (протоколы и доли), набор включенных профилей безопасности, требования к логированию и прогноз роста не только правил, но и объектов, исключений и VPN.

Быстрый чеклист перед закупкой и внедрением

Перед покупкой Quantum 6200/6400 полезно заранее договориться, какие профили будут включены в день запуска, а какие позже. Частая ошибка: тестируют «чистый» L3/L4, а в проде сразу включают IPS, App Control, Anti-Bot и TLS inspection.

Проверьте вводные по трафику и шифрованию:

• Оценен пик по Mbps и CPS, и отдельно доля TLS, которую вы реально будете инспектировать.
• Понятны типы приложений: веб, почта, VPN, бэкапы, VoIP, обновления.
• Зафиксированы «плохие дни»: квартальные закрытия, массовые обновления, атаки на периметре.

Дальше решите, как строится отказоустойчивость. Active-Standby и Active-Active ведут себя по-разному, а синхронизация и failover тоже съедают запас. Если требование - «пережить отказ без заметной деградации», включите это в приемку.

Метрики приемки лучше записать заранее и измерять одинаково на тесте и пилоте:

• Throughput и latency на типовых потоках.
• Drops, CPU/RAM, заполнение таблиц сессий.
• Стабильность под нагрузкой (не 5 минут, а 1-2 часа).

И не забывайте про горизонт планирования. Сделайте три сценария роста на 3 года для количества правил, объектов и объема логов. Если сейчас 900 правил и в среднем добавляется по 20 правил в месяц, через 3 года будет около 1620, а требования к логированию и хранению вырастут вместе с ними.

Пример сценария: организация с филиалами и ЦОД

Компания с двумя площадками: основной офис и ЦОД в другом городе. Есть 8-10 филиалов, часть сотрудников работает удаленно. Интернет разный: в офисе 1 Гбит/с, в ЦОД 2 Гбит/с, плюс межплощадочный канал 500 Мбит/с. В обычный день активны около 900-1100 пользователей, из них 200-300 могут подключаться по VPN в пиковые часы.

По политикам важна сегментация: отдельные зоны для пользователей, серверов, гостевой сети и подрядчиков. Подрядчикам дают доступ только к конкретным сервисам (например, тикет-система и один сервер администрирования), а между пользовательскими VLAN и серверной зоной включают строгие правила east-west.

Профили безопасности включены почти везде: IPS и фильтрация (URL/Anti-Virus) на всех направлениях. TLS inspection включают точечно, например только для финансовых отделов и нескольких облачных приложений, чтобы не ломать специфичные сервисы и не тратить ресурсы там, где это не нужно.

Нагрузочный тест в таком сценарии стоит строить вокруг реальных пиков:

• Утренний пик: веб, почта, обновления, SaaS, параллельно бэкапы из филиалов.
• Имитация VPN: одновременное подключение 200-300 пользователей и рост новых сессий.
• Трафик приложений: задержка и джиттер для ВКС, отклик ERP/CRM, стабильность RDP/VDI.
• Переключение каналов: отказ одного интернет-канала в ЦОД и рост нагрузки на оставшийся.
• Отдельный прогон с TLS inspection на выбранных категориях.

Рост на 3 года обычно идет не по «скорости интернета», а по сложности. Добавляются сервисы, сегменты (например, зона под IoT/СКУД), исключения под нестандартные приложения. Практичная оценка - закладывать +15-25% правил в год и рост числа объектов (группы, сети, NAT, исключения) вместе с расширением филиалов.

Если на тесте при включенных профилях CPU и CoreXL не упираются в потолок, нет потерь пакетов, а задержка для ВКС и ERP остается в пределах согласованных значений, запас на 3 года выглядит реалистично. При необходимости интегратор, например GSE.kz, может помочь собрать вводные и организовать пилот так, чтобы результат отражал вашу сеть, а не лабораторные допущения.

Следующие шаги после расчета и теста

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

Соберите результаты в короткий пакет и согласуйте его с ИБ, эксплуатацией и владельцами сервисов. Дальше помогает понятный порядок:

• Утвердить 2-3 сценария нагрузки как «эталон» (пиковые часы, резервирование, обновления).
• Провести пилот на стенде или в тестовом сегменте и зафиксировать критерии приемки.
• Описать базовую конфигурацию: какие профили включены всегда, какие - точечно.
• Ввести контроль изменений: кто добавляет правила, как проходит ревизия, когда удаляются устаревшие.
• Составить план на 3 года: лицензии, HA/кластер, лог-сервер, хранение.

Чтобы пилот не превратился в «похоже, работает», заранее определите метрики приемки. Обычно хватает 4-5 измеримых показателей:

• средняя и пиковая загрузка CPU и памяти в ваших сценариях;
• рост latency при включении ключевых профилей;
• доля отброшенных пакетов и стабильность сессий;
• скорость и полнота логирования под нагрузкой;
• время реакции на изменения политики (policy install).

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