Сравнение межсетевых экранов в закупке обычно выглядит как таблица: пропускная способность, число одновременных сессий, новые сессии в секунду. Числа берут из спецификаций вендоров или из отчётов тестовых лабораторий, ставят рядом и выбирают большее.
Так делать нельзя, и вот почему.
Главное: строки спецификации — это разные тесты
Из отдельных паспортных максимумов не следует, что устройство достигнет их одновременно. Десять миллионов сессий в таблице, полтораста тысяч новых в секунду и двадцать восемь гигабит с включённой защитой — это три разных замера, а не портрет одного режима работы.
Каждая строка получена в отдельном испытании, на отдельном профиле трафика, с отдельным набором включённых функций. Максимум по одной строке достигается ценой остальных. Это не обман: так устроено измерение. Но условия замера выносят в сноски, а читают их редко — поэтому читайте: включённые функции, размеры объектов, профиль трафика, режим TLS.
Практический вывод для закупки: сравнивать надо не строки, а условия, при которых они получены. Если условий не приведено, строка бесполезна.
Схема: одна спецификация, три разных испытания
Какой параметр главный и что проверять рядом
Главный — производительность с включённой защитой, то, что в спецификациях называется threat prevention throughput или аналогично. Пропускная способность на пакетном уровне без разбора содержимого описывает маршрутизатор, а вы покупаете средство защиты.
Но одним числом дело не закрывается. Упереться можно и в новые сессии в секунду, и в ёмкость таблицы сессий, и в скорость рукопожатий TLS, и в задержку — RFC 9411 разбирает эти показатели как отдельные. Правило простое: главный показатель определяет выбор, остальные проверяются под вашу реальную нагрузку, чтобы не оказалось, что устройство держит гигабиты, но захлёбывается на числе соединений.
Что показывает тест на UDP и чего не показывает
Производительность, измеренная на потоке UDP-пакетов фиксированного размера, встречается в спецификациях регулярно. Сам по себе такой замер осмыслен: он изолированно измеряет пересылку, и под это есть методика — RFC 2544. Однородные потоки в жизни тоже встречаются, например в видеотранспорте.
Ошибка не в тесте, а в выводе из него. Один замер на однородном UDP не показывает, как устройство разбирает смешанный прикладной трафик с включёнными проверками. Это как измерять пропускную способность поликлиники по людям, которые вошли и сразу вышли: число получится, лечение в него не входит.
Спрашивайте, на каком профиле трафика сделан замер, и просите показать состав потока.
Пять вопросов к любому отчёту о тестировании
Отчёты независимых лабораторий полезнее спецификаций, но читать их нужно так же внимательно.
1. Что именно фильтровалось? Если экранирование шло по адресам и портам, а разбор приложений не включался, то испытывали не NGFW. Большинство приложений сегодня работает по 443-му порту, и правило по номеру порта означает только «разрешить всё» или «запретить всё».
2. Сколько было правил и каких? Размер политики в испытании стоит сравнить с вашим: тысяча правил и десять тысяч — разные сценарии, а в крупных сетях я встречал и шестизначные политики. Важен не только размер, но и состав: как устроен поиск правила, есть ли аппаратное ускорение. Универсального коэффициента падения нет — сравнивайте работу на своей политике и на её планируемом размере.
3. Проверялось ли, что защита работает под нагрузкой? Подать на систему обнаружения вторжений максимальный поток и записать гигабиты — половина замера. Нужно одновременно подавать атаки и считать, сколько из них заблокировано. Под предельной нагрузкой возможны разные исходы, и это разные вещи: потеря пакетов, отказ в новых сессиях, обход проверки. Записывайте, что именно произошло и как настроено поведение при перегрузке — пропускать или блокировать.
4. Какая доля трафика была зашифрована и расшифровывалась ли она? Если в потоке две трети TLS, а расшифрование выключено, то содержимое этих сессий в тесте не проверялось вовсе. Число получится большим и к вашей эксплуатации отношения иметь не будет.
5. Не упёрся ли стенд сам в себя? Генераторы трафика, пакетные брокеры, коммутаторы и система управления журналами имеют собственный потолок. В испытаниях на сотни гигабит в потолок упирается то генератор в режиме приложений, то брокер, то система управления, которая не успевает писать журналы. Отчёт, где это честно описано, ценнее отчёта с круглыми цифрами.
И шестой вопрос, уже к архитектуре: сколько устройств в стенде. Конструкция из полутора десятков экранов с балансировщиками и коммутаторами показывает суммарное число, но в эксплуатации это другая жизнь — отладка через такой стенд тяжела, синхронизация состояний сессий между узлами может отсутствовать вовсе, а отказ одного элемента проверяется отдельным испытанием.
Что с этим делать на своём пилоте
Замеры вендора и лаборатории — вход в разговор, а не основание для решения. Собственные испытания отвечают на вопрос, который в чужих отчётах не задан: что будет на вашем трафике, с вашей политикой и вашими включёнными функциями.
Порядок проверок и приёмка — в программе пилота NGFW. Критерии выбора и вопросы поставщику — на странице как выбрать NGFW. Чем архитектура NGFW отличается от UTM — в отдельной статье.