Sizing FortiGate 100F/200F по трафику: IPS, SSL, VPN и тесты

Задача: подобрать 100F или 200F под реальный периметр

Цифры в даташите полезны, но они отвечают на вопрос «сколько максимум в идеальных условиях». На реальном периметре трафик неровный: много коротких сессий, встречаются «тяжелые» приложения, а еще включаются IPS, фильтрация, инспекция TLS и VPN. Поэтому sizing FortiGate 100F/200F логично делать от измеренного трафика и конкретных функций. Иначе легко купить модель «по паспорту» и получить проблемы на пиках.

Важно понимать, почему в характеристиках разные значения: Firewall throughput, IPS, Threat Protection, SSL inspection. Это не четыре способа измерить одно и то же, а разные режимы работы. Простая маршрутизация и фильтрация по правилам почти не требуют глубокой обработки. IPS и Threat Protection добавляют анализ пакетов и сессий. SSL inspection дополнительно расшифровывает и шифрует трафик и часто становится главным потребителем ресурсов. VPN добавляет криптографию и может упереться в шифрование раньше, чем в «общий» гигабит.

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

Бизнес видит недосайзинг не как «не хватает Mbps», а как вполне понятные симптомы:

• заметные задержки в веб-сервисах и корпоративных приложениях в часы пик
• периодические обрывы VPN и жалобы на «плавающую» скорость
• рост времени открытия страниц при включенной инспекции
• ошибки соединений из-за переполнения таблиц сессий
• вынужденные компромиссы в политиках безопасности (проверки отключают ради скорости)

Цель выбора между 100F и 200F простая: обеспечить нужные функции с запасом на пик и рост, не снижая уровень защиты ради производительности.

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

Точный sizing FortiGate 100F/200F начинается не с паспортных цифр, а с измерений того, что реально проходит через периметр. Важно понять не только сколько гигабит, но и какой это трафик, когда он возникает и какие функции безопасности вы включите.

Сначала определите источники данных. Самый простой вариант - статистика на текущем межсетевом экране или маршрутизаторе (WAN-интерфейсы, VPN, основные политики). Если такого устройства нет или данные неполные, пригодится зеркалирование порта (SPAN) на коммутаторе для короткого замера. Для длительного периода лучше NetFlow/sFlow на маршрутизаторе или L3-коммутаторе. Идеально, когда источников два: один дает общую картину, второй подтверждает пики.

Собирать нужно не одну цифру, а несколько интервалов. Среднее значение полезно для понимания фона, но для выбора модели важнее 95-й перцентиль и короткие пики в рабочие часы. Отдельно отметьте ночные окна: бэкапы, обновления, синхронизации и репликации.

Дальше разделите потоки по назначению. Одинаковый по объему трафик может нагружать устройство по-разному, если это веб с SSL inspection или межфилиальные туннели. Для первичной картины обычно хватает групп: интернет (web/SaaS/почта/мессенджеры/видеосвязь), межфилиальный обмен (site-to-site VPN), облака (IaaS/PaaS, резервные площадки, удаленные рабочие столы), технические окна (обновления и бэкапы), входящие публикации и удаленный доступ.

Чтобы sizing FortiGate 100F/200F не устарел через полгода, зафиксируйте планы на 12-18 месяцев: рост числа пользователей, новые филиалы, переход в облако, запуск VDI, внедрение EDR/NDR, увеличение доли шифрованного трафика.

И составьте список критичных приложений и их чувствительность к задержке и потерям. Бухгалтерия и ERP часто переживают небольшой рост задержки, а голос, видеоконференции и виртуальные рабочие столы проблемы показывают сразу. Эти приложения потом станут основой для сценариев нагрузочных тестов и критериев приемки.

Быстрая оценка: функции, порты и запас по росту

Перед тем как углубляться в цифры, полезно сделать черновой sizing FortiGate 100F/200F. Он быстро отсекает заведомо неподходящую модель по трем вещам: роль устройства, набор функций и физическое подключение.

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

Затем соберите матрицу функций и отметьте, что будет включено всегда, а что - только для части потоков. Это принципиально, потому что SSL inspection и IPS обычно «съедают» производительность сильнее, чем базовый firewall и NAT.

Для первого приближения достаточно зафиксировать: IPS (и строгость профиля), антивирус/антибот для веба и почты, web filter (всем или выборочно), SSL inspection (полная проверка или выборочно), VPN (site-to-site и удаленные пользователи).

Дальше прикиньте пиковую скорость в обе стороны. Не «канал по договору», а реальный пик (например, 600 Мбит/с download и 200 Мбит/с upload). Добавьте запас 20-30% на рост и на «неприятные дни» (обновления, бэкапы, инциденты). Если часть функций включается выборочно, оцените долю трафика, которая реально попадет под проверку.

Отдельно проверьте порты и схему подключения: нужен ли 10G аплинк, потребуется ли LACP, сколько физических линий в резервировании, будет ли HA-пара. Иногда модель подходит по вычислительной части, но упирается в интерфейсы и топологию.

Пример: у организации 1G интернет, пиковая нагрузка 700 Мбит/с, но полное SSL inspection нужно только для веб-трафика сотрудников (скажем, 40% потока), а VPN используется для пары филиалов и 100 удаленных пользователей. Предварительная оценка должна учитывать не один «общий» мегабит, а несколько потоков с разными функциями и разной постоянностью включения.

Пошаговая методика sizing по измеренному трафику

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

Дальше снимите базу без инспекции, чтобы понимать «чистую» нагрузку сети и сессий. Зафиксируйте минимум:

• пиковую скорость и 95-й перцентиль (вход и выход отдельно)
• PPS (пакеты в секунду) в пике
• новые сессии в секунду
• одновременные сессии
• распределение по размерам пакетов (если доступно)

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

Теперь оцените долю трафика, которая реально пройдет через SSL inspection. Не весь HTTPS имеет смысл расшифровывать: часть сайтов исключают по политике, часть приложений ломается без точной настройки. Если, например, 40% веб-трафика вы планируете инспектировать, именно этот кусок станет главным кандидатом на нагрузку CPU/crypto.

Затем прикиньте, какая доля потоков будет под IPS и другими профилями (AV, web filter, application control). Частая практика: включать полный набор на «пользовательский» интернет, а для резервного копирования, обновлений и больших загрузок оставлять более легкие политики.

На выходе выберите кандидата в паре 100F/200F и сформулируйте гипотезы для тестов. Например: выдержит ли модель пиковый PPS, сколько даст SSL inspection на вашем наборе сайтов, и не упрется ли в новые сессии при утреннем старте рабочих мест.

IPS: как оценить нагрузку и не ошибиться с профилем

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

Для sizing FortiGate 100F/200F важнее не «гигабиты», а то, как трафик выглядит по нагрузке на пакеты и сессии. Два канала по 500 Мбит/с могут вести себя совершенно по-разному: один состоит из длинных потоков (видео, бэкапы), второй - из коротких запросов (веб, API). IPS «почувствует» это сильнее.

Смотрите на метрики, которые обычно первыми упираются в ресурсы:

• PPS (packets per second), особенно на пиках
• New sessions/sec (скорость создания новых сессий)
• одновременные сессии (concurrent sessions)
• доля мелких пакетов и коротких соединений
• распределение трафика по политикам (где включен IPS)

Отдельно оцените East-West, если планируете сегментацию через FW. Как только межсетевой экран становится «перекрестком» между VLAN/сегментами (офис, серверы, VDI, медоборудование), внутренний трафик часто начинает доминировать над интернет-периметром. Это добавляет PPS и new sessions/sec, даже если внешний канал не меняется.

Профили лучше проверять тестом на одном и том же трафике: базовый (минимум сигнатур), рекомендованный (balanced), строгий (максимум проверок). Например, на пилоте в филиале: днем включили базовый, вечером рекомендованный, в окно работ строгий - и сравнили задержку, CPU, PPS и число отклоненных пакетов.

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

SSL inspection: где теряется производительность и как это учесть

SSL inspection - это не просто «посмотреть HTTPS». Устройство становится посредником: подменяет сертификат, расшифровывает поток, прогоняет его через проверки (AV/IPS/DLP/URL), затем снова шифрует и отправляет дальше. Самые дорогие места по ресурсам - операции шифрования и обработка большого числа коротких сессий (типично для веба и облаков). Поэтому в sizing FortiGate 100F/200F эта функция часто становится главным ограничителем, даже если без расшифровки канал «летает».

Выберите режим и правила, а не «включить везде»

Практично разделять как минимум три подхода: certificate inspection (проверка сертификата без расшифровки), full inspection (полная расшифровка и проверки) и исключения по категориям/доменам и по направлениям трафика. Certificate inspection дает видимость и почти не съедает производительность. Full inspection дает максимум контроля, но требует аккуратной политики исключений.

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

Как оценить долю TLS и понять, где будет узкое место

Сначала измерьте, какая часть исходящего трафика реально идет по TLS, и сколько там новых сессий в пике. Отдельно разберите типы клиентов: браузеры сотрудников, агентские приложения (EDR, почта, бэкапы), мобильные устройства и гостевой Wi-Fi. У них разная чувствительность к подмене сертификата и разная «сессионность».

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

VPN: расчет по пользователям, туннелям и шифрованию

VPN часто «съедает» производительность неожиданно: важны не учетные записи, а одновременность, шифрование и профиль пакетов. Для sizing FortiGate 100F/200F сразу разделите сценарии: site-to-site (филиалы, облака, партнеры), remote access (сотрудники, подрядчики) и смешанный режим, когда оба типа работают параллельно в часы пик.

Считать нужно от реальности: сколько туннелей одновременно поднято и сколько людей действительно передают данные одновременно, а не «всего в списке». Например, 300 пользователей в VPN не равны 300 активным. В пике часто активно 60-120, и именно их трафик задает планку.

Что закладывать в расчет

Начните с пяти входных цифр, которые проще всего подтвердить замерами и логами:

• пиковый суммарный VPN throughput (в обе стороны), отдельно для remote access и site-to-site
• число одновременных подключений пользователей и одновременно поднятых туннелей
• типы трафика внутри VPN (RDP, VoIP, файлы, VDI): мелкие пакеты «тяжелее»
• набор шифров и режим (например, AES-256 vs AES-128, IKEv2), нужны ли строгие политики
• запас на рост: новые филиалы, подрядчики, сезонные пики

Шифры и политики напрямую влияют на нагрузку CPU/ASIC. Если планируются более тяжелые наборы шифрования и частые переподключения (нестабильные каналы, мобильные сети), закладывайте запас не только по Mbps, но и по числу сессий и скорости установления туннеля.

Что измерять на тестах

Перед вводом проверьте не «максимум на бумаге», а поведение под нагрузкой:

• реальный VPN throughput в пике и на мелких пакетах
• время установления туннеля и процент успешных реконнектов
• стабильность: нет ли обрывов при длительной нагрузке (1-2 часа)
• задержка и джиттер для критичных сервисов (голос, VDI)
• нагрузка по CPU/памяти и рост таблиц сессий

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

План тестов производительности перед вводом

План нагрузочных тестов нужен не для «рекордных цифр», а чтобы подтвердить, что выбранная модель выдержит ваш профиль трафика. Это особенно важно, если вы делаете sizing FortiGate 100F/200F по замерам и хотите заранее понять, где появится узкое место: IPS, SSL inspection или VPN.

Минимальный стенд и правила сравнимости

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

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

Набор сценариев и нагрузки

Сценарии лучше прогонять от простого к сложному, чтобы видеть вклад каждой функции:

• базовый firewall без IPS и без расшифровки SSL
• firewall + IPS (профиль, который реально планируется)
• firewall + SSL inspection (с теми исключениями, которые будут в проде)
• VPN (IPsec/SSL) с количеством пользователей/туннелей, близким к боевому
• «все вместе» в одной конфигурации

Меряйте не только среднюю пропускную способность, но и поведение на пиках. Дайте короткие всплески (например, старт резервного копирования), смешанный трафик (web, файловые, DNS, обновления), а также длинные сессии (удаленный рабочий стол, большие загрузки). Частая ошибка - тестировать одним потоком и радоваться цифрам, которые потом проседают при реальной смеси.

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

Пример: если в офисе 250 пользователей и по утрам идут обновления, прогоните 15-минутный тест со всплеском до 2-3x от среднего, одновременно с 30-50 активными VPN-пользователями и включенным IPS. Так видно, держится ли задержка и не растут ли отказы по новым соединениям.

Метрики и критерии приемки: как понять, что хватает

Чтобы sizing FortiGate 100F/200F не оказался «на глаз», заранее договоритесь, какие цифры считаются нормой. Тогда тесты дадут ответ, хватает ли запаса, а не просто покажут «работает или нет».

Что снимать во время теста

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

• CPU по устройству и по процессам (включая IPS и SSL)
• память и динамика (нет ли постепенного роста)
• сессии: текущие и пиковые значения, скорость создания новых сессий
• потери и сбросы: dropped packets, retransmits, ошибки интерфейсов
• задержка: средняя и 95-й перцентиль для ключевых направлений

Отдельно измеряйте скорость и задержку для критичных приложений. Общий throughput может быть «красивым», но пользователи будут недовольны из-за роста задержки на VoIP или из-за долгой загрузки страниц при SSL inspection.

Критерии приемки: простые и проверяемые

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

• CPU на пике не выше 70-80% в целевом профиле (IPS + SSL + VPN), без «пилы» в 100%
• потерь пакетов нет (или заранее зафиксирован допустимый максимум, например до 0,1% под пиком)
• задержка стабильна: нет резких скачков при росте сессий и переподключениях VPN
• VPN работает без обрывов: переподключения, DPD, смена сети у клиента не ломают туннель
• результаты повторяемы: два прогона дают близкие цифры

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

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

Частые ошибки при sizing и нагрузочных тестах

Самая частая ловушка в sizing FortiGate 100F/200F - выбрать модель по одной цифре из даташита. «Firewall throughput» почти ничего не говорит, если у вас много мелких пакетов, коротких сессий, включены IPS и проверка TLS.

Ошибки, которые дают ложное ощущение «все выдержит»

Проблемы обычно появляются не на «гигабитах», а на количестве сессий, PPS и на включенных функциях безопасности. Что чаще всего ломает расчет:

• сравнивают только Gbps и игнорируют PPS, CPS и одновременные сессии
• включают SSL inspection «для всего», не определив, что реально нужно расшифровывать, и не измерив долю TLS в трафике
• делают один большой тест «все включили сразу» и потом не понимают, что именно уронило производительность
• не учитывают фон: обновления, бэкапы, сканирование EDR, репликации и синхронизации
• планируют «впритык» без запаса на рост пользователей и новые сервисы после запуска

Ошибки в нагрузочных тестах

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

Чтобы тест был полезным, держите простые правила: сначала снимите базовую линию без IPS и SSL, затем включайте функции по одной и фиксируйте разницу. Повторяйте реальный профиль (доля TLS, размер пакетов, число клиентов, число правил, логирование). И заранее задайте критерии: допустимая задержка, потери, загрузка CPU, рост сессий без ошибок.

Если вы внедряете периметр в госструктуре или крупной компании, часто помогает участие опытного интегратора, который умеет собрать реальную статистику и воспроизвести ее на стенде, как это обычно делают системные интеграторы уровня GSE.kz.

Чеклист и следующие шаги после выбора модели

Когда расчеты готовы, стоит быстро проверить, что ничего не забыто. Даже аккуратный sizing FortiGate 100F/200F может «поехать», если упустить долю SSL, реальную политику IPS или будущий рост.

Перед закупкой полезно пройти короткий чеклист и зафиксировать ответы письменно (это очень помогает на приемке):

• пиковый трафик в рабочие часы и «тяжелые» направления (интернет, межфилиалка, облака)
• включаемые функции на периметре: IPS, AV, WebFilter, AppControl, логирование
• доля HTTPS и сценарий SSL inspection (полный, выборочный, исключения)
• VPN: тип (IPsec/SSL), количество пользователей/туннелей, ожидаемые пики
• запас по росту на 12-24 месяца и планируемые изменения (VDOM, сегментация, новые сервисы)

Если есть признаки, что модель получается «впритык», чаще разумнее смотреть в сторону 200F. Типичные сигналы: высокий процент трафика под SSL inspection, регулярные пики близко к расчетному пределу, рост числа VPN-пользователей, планы включить более строгие IPS-профили и подробное логирование.

Перед вводом решает не паспорт, а дисциплина тестов и критерии приемки. На стенде заранее согласуйте сценарии (чистый FW, затем по одному добавлять IPS, SSL inspection, VPN, логирование), реалистичный профиль трафика, метрики приемки (throughput, задержка, потери, CPU/RAM, session count, время установления туннелей), пороги деградации и план отката.

Для эксплуатации подготовьте мониторинг ключевых счетчиков (CPU, sessions, drops, крипто-нагрузка), график обновлений FortiOS и сигнатур, регулярные резервные копии конфигураций и понятный порядок изменений правил.

Следующие шаги обычно такие: короткий пилот на реальном трафике, фиксация итоговой конфигурации и документации, затем ввод по плану. Если нужно, команда GSE.kz (gse.kz) может помочь с измерениями трафика, стендовыми тестами, внедрением и дальнейшей поддержкой 24/7.