---
title: "Тестирование NGFW: fast path, поддельный AppMix и ловушки PCAP-реплея"
description: "Fast path, вендорские тестовые режимы, дрейф AppMix, PCAP-реплей: почему обычные тесты NGFW дают числа, которые не доживают до прода."
---

[Блог TEST4NET — тестирование сетей и безопасности](https://test4net.com/ru/blog)

# [Тестирование NGFW: fast path, поддельный AppMix и ловушки PCAP-реплея](https://test4net.com/ru/blog/ngfw-testing-fast-path-appmix-pcap)

 Written by [Alexander Zemskov](https://test4net.com/ru/blog/author/az) | 6 сент. 2026 г., 14:05:53

*Это вторая часть из шести о том, как оценивать продукты сетевой безопасности. [Часть 1](https://test4net.com/ru/blog/the-security-datasheet-lie-and-why-it-is-structural?hsLang=ru) разобрала структурный разрыв в даташитах, общий для всей отрасли.*

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

## Fast path: функция, которая становится ловушкой в тесте

В большинстве корпоративных NGFW есть свои ASIC или выделенные процессоры безопасности. Эти чипы уводят часть трафика на аппаратный fast path в обход программного стека. Это законная и полезная архитектурная особенность. В правильных условиях она дает реальный прирост производительности с настоящей инспекцией.

### Вся соль в словах «в правильных условиях».

Fast path работает лучше всего, когда трафик однородный, предсказуемый и простой: долгие сессии с крупными payload, ровный темп новых соединений, открытые или легко классифицируемые протоколы. В таких условиях ASIC берет основную работу, программный стек почти простаивает, throughput приближается к теоретическому пределу железа.

Реальный корпоративный трафик устроен иначе: короткие сессии, много мелких объектов, TLS 1.3 с шифрованным SNI и ESNI, нестандартные порты, проприетарные протоколы приложений, всплески установки новых соединений. На таком трафике покрытие fast path резко падает, и основную нагрузку несет программный стек.

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

## Вендорские тестовые режимы: оптимизация, о которой не объявляют

Кроме честного поведения fast path есть более намеренная категория оптимизаций.

Вендоры знают, какими генераторами трафика обычно тестируют продукты безопасности. Знают профили, паттерны, типовые PCAP-файлы для оценок. Некоторые платформы реализуют оптимизации, которые срабатывают именно на этих известных профилях: кеширование результата DPI для сессий, побайтово совпадающих с уже виденными; сокращенный разбор для точных паттернов payload из распространенных тестовых наборов; правила fast path, привязанные к особенностям конкретных генераторов.

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

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

## Проблема AppMix: заданное вами распределение – не то, что прошло через устройство

Это самая тонкая техническая проблема в тестировании NGFW и самая часто упускаемая.

Вы задаете тест с целевым миксом приложений – скажем, 25% HTTPS, 20% HTTP, 15% DNS, 15% SMTP, 10% видео, 10% БД, 5% кастом – и ждете, что именно это распределение пойдет через устройство. Оно не идет.

Бесплатные и open-source генераторы планируют новые сессии по заданным весам. Они не учитывают, сколько времени каждый тип протокола обрабатывается на DUT. Обработка средствами безопасности по протоколам неравномерна.

Тяжелые протоколы – TLS со взаимной аутентификацией, SMTP с крупными вложениями, протоколы с долгой классификацией DPI – тратят больше времени на сессию на DUT. Они встают в очередь. Замедляются. Генератор об этом не знает и продолжает запускать новые сессии с заданной частотой. Легкие протоколы – обычный HTTP, DNS-запросы, мелкий UDP – обрабатываются быстро и проходят через устройство на полной скорости.

Итог: за время теста реальный микс на DUT смещается в сторону самых легких, быстрых протоколов. Устройство будто держит 10 Gbps с полной инспекцией. Оно правда держит 10 Gbps, но 60% из них это обычный HTTP и DNS, потому что заданные вами сессии SMTP и TLS стоят в очередях или отбрасываются.

Число throughput настоящее. Профиль трафика, на котором его сняли, не тот, что вы задумывали.

**Почему без контроля AppMix сравнение вендоров бессмысленно.** Устройство A обрабатывает тяжелые протоколы эффективно: TLS и сложный DPI идут с умеренным overhead. В вашем тесте реальный AppMix устройства A близок к заданному. Устройство B отбрасывает тяжелые сессии быстрее: overhead слишком высок, соединения отваливаются по таймауту. Реальный AppMix устройства B состоит в основном из легкого трафика. Устройство B показывает более высокий throughput.

Вы делаете вывод, что устройство B производительнее устройства A. Вы меряете их разными линейками и не знаете об этом.

## PCAP-реплей: инструмент, который сообщает вендору, что придет

TRex и многие тестовые инструменты из Китая используют режим PCAP-реплея – воспроизводят заранее записанный трафик. Каждая сессия на L7 побайтово совпадает с любой другой сессией того же типа. Те же заголовки. Те же payload. Те же номера последовательностей, тот же SNI, те же паттерны URI – повторяются бесконечно.

Вендор, который тестирует ваш продукт, знает, какими инструментами пользуются покупатели. Знает PCAP-файлы. Знает паттерны payload. Оптимизировать под них ничего не стоит.

Что конкретно работает против детерминированного PCAP-реплея:

- Кеширование результата DPI. Если у двух TCP-сессий одинаковый payload, вторую классифицируют мгновенно из кеша вместо полного DPI. На реплее throughput резко выше, на реальных разнообразных сессиях выигрыша почти ноль.
- Правила fast path под известные паттерны. Сессию, совпавшую с известным точным паттерном из тестового PCAP, отправляют на fast path после минимальной инспекции. К сессиям с меняющимся payload это не применимо.
- Сокращенный разбор. Некоторые движки DPI используют сокращения для паттернов payload, которые часто встречаются в тестовом трафике. На новых данных приложений эти сокращения не работают.

Аргумент за бесплатные инструменты – цена. Честный подсчет включает: инженерное время на сборку стенда, время на обход ограничений по масштабированию, время на проектирование методики – и стоимость многолетнего решения о закупке по результатам, к которым вендор подготовился. Это не дешевый тест.

## Как выглядит хороший тест NGFW

Разница между хорошим и плохим тестом сводится к трем управляемым переменным.

**Динамическая генерация трафика.** Каждая сессия генерируется на ходу – уникальные заголовки, токены, payload на L7. Две сессии одного типа не должны совпадать побайтово. Это отключает оптимизации на кеше и заставляет устройство классифицировать каждый поток с нуля, как оно будет делать в проде.

**Контроль AppMix по замкнутому циклу.** Генератор измеряет реальный микс приложений на DUT и возвращает это в планирование сессий. Если измеренный микс уходит от целевого, веса подстраиваются на ходу. Без этого вы отчитываетесь о заданном миксе, а не об измеренном, и это разные числа.

**Эффективность защиты под нагрузкой.** Атаки подаются внутри фонового потока трафика, на реалистичном уровне нагрузки – не отдельно, с устройством на холостом ходу. Устройство, которое блокирует 99% атак при 5% загрузки и 70% при 80% загрузки, дает совсем другой уровень защиты, чем говорит заголовочная цифра детекта.

Это не экзотические требования. Это стандартная практика квалификации инфраструктуры у крупных операторов и в финансовых организациях. Все это достижимо при правильных инструментах и методике.

*Дальше в серии – Пост 3: WAF, IPS и DLP. Почему тестировать инспекцию контента труднее, чем кажется, и как покрытие обхода отделяет продукты, которые вас защищают, от продуктов, которые защищают вас в демо.*

*TEST4NET LLC – независимая лаборатория тестирования сетей и безопасности, без коммерческих связей с вендорами безопасности. Напишите нам, чтобы обсудить оценку вашего NGFW.*

[View full post](https://test4net.com/ru/blog/ngfw-testing-fast-path-appmix-pcap)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Alexander Zemskov"
  },
  "dateModified" : "2026-10-21T20:55:55.576Z",
  "datePublished" : "2026-09-06T14:05:53Z",
  "headline" : "Тестирование NGFW: fast path, поддельный AppMix и ловушки PCAP-реплея",
  "image" : {
    "@type" : "ImageObject",
    "height" : 941,
    "url" : "https://148823364.fs1.hubspotusercontent-eu1.net/hubfs/148823364/AI-Generated%20Media/Images/Hardware%20Firewall%20with%20Shadow%20Overlay%20and%20Abstract%20Flow%20Lines.png",
    "width" : 1672
  },
  "mainEntityOfPage" : "https://test4net.com/ru/blog/ngfw-testing-fast-path-appmix-pcap",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60.0,
      "url" : "https://148823364.fs1.hubspotusercontent-eu1.net/hubfs/148823364/test4net-logo-fixed-2.svg",
      "width" : 195.45763
    },
    "name" : "Тестирование сетей и безопасности: экспертный блог"
  }
}
```