Почему построить межсетевой экран на 200 Гбит/с — это ад инженерии: честный разбор Mirada

Материал согласован с Codemaster в части технических данных и цифр. Оценки и выводы — мои.

---

С 1998 года по 2026 год я эксплуатировал и настраивал разные IPS и межсетевые экраны: PIX, ASA, Check Point, IPFW, IPtables, ISA/TMG, WatchGuard, Sophos, Optenet, Palo Alto Networks, Fortinet. Пару межсетевых экранов я даже помогал делать уже в российских компаниях.

За эти годы у меня сложилось простое правило сравнения: в реальной эксплуатации межсетевые экраны различаются не только скоростью и наборами настроек, а журналами. Настроить политику мы почти всегда сможем. А вот расследовать, почему перестал ходить трафик или отработало правило безопасности, приходится именно в наших логах. Именно в журналах инженеры проводят 90% времени.

Когда мне показали журналы «Мирады» — флагманского программно-аппаратного комплекса компании Codemaster, — первая реакция была скептической. Я прямо сказал Андрею Калинину, главному инженеру проекта: лить сырой Syslog во внешнюю SIEM на скоростях 100 Гбит/с — сомнительная затея, поскольку любой лог-коллектор под такой нагрузкой быстро упрётся в физические пределы скоростей жёсткого диска и сетевых интерфейсов. Также я заметил, что текущий ручной ввод IP-адресов в правилах вместо создания адресных объектов усложняет жизнь администратору.

Андрей ответил без обид: «Мы понимаем эти ограничения. Приезжай в лабораторию, посмотрим устройство под нагрузкой, разберём как работает Dataplane, покажем, чем гордимся и что уже стоит в роадмапе». Так из тестов оборудования и разговора с главным инженером родился этот обзор.

<cut/>

Глава 1. Разгон до 200 Гбит/с и что показали приборы

В сетевой безопасности словам не верят на слово, поэтому начали с тяжёлого профиля на генераторе трафика. Здесь важная оговорка: TRex — не IXIA. Я по-прежнему предпочитаю аппаратные системы Keysight/IXIA, где генерация трафика меньше зависит от операционной системы, шины PCIe и стандартного процессора Intel. TRex на DPDK полезен, но требует осторожности: при тестировании программного межсетевого экрана программным же генератором легко получить влияние самого тестового стенда на результат устройства под нагрузкой. IXIA в лаборатории не было, поэтому смотрели на TRex.

Стенд собран на сервере с TRex с DPDK; для генерации 100 Гбит/с использовались три карты Mellanox ConnectX-6 для 100 Гбит/с портов и карты на чипе Intel X710 для 10 Гбит/с. Mellanox ConnectX-6 — карта с аппаратным offload, однако в роли генератора трафика под DPDK она остаётся частью серверной платформы, что подтверждает мою любовь к IXIA: при тестировании программного МСЭ программным же генератором важно контролировать влияние стенда на результат.

Перед стартом я задал Андрею самый очевидный вопрос: «Правила в рабочий конфиг залиты или гоняем красивую цифру на пустой таблице?» Он показал активную политику: 88 695 статических правил фильтрации (ACL). Это уже не демонстрация на чистом листе, а проверка классификации почти по десяткам тысяч правил.

На UDP-пакетах 1518 бай устройство показало пропускную способность около 193,6 Гбит/с, с пиками до 198 Гбит/с, без потерь пакетов. Важнее самой цифры было состояние Control Plane: на дашборде Mirada 900 загрузка CPU оставалась около 19%, без пилы и провалов. Данное устройство сохраняет управляемость под максимальной нагрузкой. Андрей объяснил как это сделано: Dataplane изолирован от Control Plane, обработка пакетов идёт через оптимизированный драйвер и не задействует ресурсы, отвечающие за управление устройством. И производительность такая благодаря высокопроизводительным ASIC в устройстве.

Дальше мы перешли к нагрузке приложениями: я попросил запустить типовой HTTP-профиль с размером ответа 64 КБ, который идёт внутри TCP-сессии и поток новых соединений. Именно такой профиль тестирования я люблю смотреть в datasheet у мировых вендоров: Fortinet и Palo Alto Networks. В этом сценарии Mirada держала около 188,6 Гбит/с при 19,6 Mpps и примерно 66K CPS, всего 24,6 миллиона соединений, снова без потерь.

У тут я задумался. Если CPU всегда 19%, значит мы проверяем прежде всего как работает dataplane без детального журналирования каждого дропа. На 12 миллионах пакетов в секунду попытка писать текстовый лог на каждый пакет убьёт любой Control Plane (200 байт × 12 млн событий ≥ 19,2 Гбит полосы). Андрей согласился: «Физику не обманешь. Dataplane должен пропускать и отбрасывать пакеты без задержек, а детальная аналитика на 200 Гбит/с требует отдельной архитектуры журналирования и внешней агрегации». Это честное признание важнее рекламной цифры Throughput.

В отдельном сценарии для коротких UDP-пакетов по 64 байта устройство удержало 30,72 Mpps при 1,28 млн CPS. В гигабитах это выглядит скромнее — около 16,93 Гбит/с, но для 64-байтового кадра показатель PPS важнее.

В другом тесте мы запустили EMIX без NAT и он также прошёл без дропов. EMIX — это не один тип трафика, а целый зоопарк протоколов внутри одного потока. Профиль собирает HTTPS, HTTP, видео по RTP, почту, Citrix, DNS и SIP в пропорциях, близких к трафику обычного офиса, а не к синтетическому UDP-потоку на одной длине пакета. На TRex Андрей поднял именно такую смесь, без NAT, с распределением по протоколам, которое я попросил показать отдельно.

На самом деле, я уже после написания статьи понял что забыл узнать. В EMIX важно показывать длину транзакции. А я забыл это запросить. Потому что именно длина транзакции влияет на то как будет нагружен мозг устройства. Ведь на скорость 100 Гбит/с сложнее обработать море коротких чем небольшое число длинных. Но тесты все равно были без контроля приложений и а длина транзакции реально важна для теста произфодительности движка анализа приложений. Поэтому в нашем случае тест скорее проходил как тест на миксе фреймов разной длины. Payload фреймов устройство в данных тестах не изучало. Вообще это тема для отдельного разговора про то как измеряют производительностью детекторов приложений в DPI или NGFW.

NAT добавляет свою нагрузку: нужно пересчитывать контрольные суммы IP и TCP/UDP, подменять адреса и порты, синхронизировать таблицу трансляции с состояниями межсетевого экрана. В Mirada NAT в версии 1.2.0 ориентирован на TCP/UDP; ICMP-трансляции в документации нет, ALG-хелперы для SIP, FTP и H.323 также не описаны. Для телефонии, active-FTP и legacy-протоколов это ограничение, которое придётся учитывать при проектировании.

При этом базовая производительность NAT выглядит сильной: при тестировании с HTTP 64 Кб + NAT загрузка CPU поднялась до 44%, а оперативная память держалась около 310,42 ГБ без лавинообразного роста объектов.

Результаты нагрузочного тестирования ПАК Mirada 900 на TRex

Насыщенный полный день в офисе компании подходил к концу. Я бы еще протестировал производительность IDS, TLS инспекции и тут мне уже потребется IXIA c ее наборами атак Strike и умением формировать и балансировать полноценные TLS транзакции. Так что это отдельная тема для другой статьи. Продолжу рассказом про функциональность устройства, о которых мы достаточно долго говорили на встрече с коллегами.

Глава 2. Парадокс интерфейса: отсутствие объектной модели

После тестов производительности мы перешли к функциональности. GUI выглядит аккуратно: разделы «Инфографика», «Межсетевое экранирование», «Сетевые функции» читаются быстро. В разделе «Правила фильтрации → Статические правила» ещё нет объектной модели уровня Palo Alto Networks или Check Point. IP-адреса и подсети вводятся числовыми значениями CIDR: x.x.x.x, x.x.x.x/xx, диапазоном x.x.x.x-y.y.y.y или списком через запятую.

Андрей называет это осознанным компромиссом ранней версии: фокус разработки был отдан dataplane на 100 Гбит/с, а полноценный объектный движок — сетевые объекты, группы, переиспользование в ACL, NAT и TLS-инспекции — должен появиться в следующих релизах. Для небольших политик такой подход терпим. Для миграции тысяч серверов и сложных политик он заметно увеличивает операционную стоимость.

Интересно, что в IDS логика объектов уже есть, но в специфическом виде: «Шаблоны активов» связывают подсети источников, получателей и доменных пользователей из Active Directory. СОВ (система обнаружения вторжений) использует эти контексты для анализа и, при срабатывании сигнатур БРП, может формировать динамические правила в режиме IPS. Но эта логика живёт отдельно от статической таблицы межсетевого экранирования.

Я отдельно спросил, почему во время испытаний мы фактически обсуждаем IDS, то есть мониторинг, а не полноценный IPS. Ответ Андрея был прагматичным: в текущей версии под капотом используется Suricata, а перенос глубокого сигнатурного анализа на 100-гигабитные линейки без жёсткой оптимизации и аппаратной разгрузки — серьёзная инженерная задача. Здесь же возникает вопрос разработки сигнатур: собственная лаборатория требует многих лет инвестиций, партнёрские базы становятся менее доступными, поэтому для Mirada критичны собственный независимый отдел экспертов для написания сигнатур, оптимизация Suricata под DPDK-стек и горизонтальное масштабирование.

Архитектура Control Plane у Mirada использует современную микросервисную модель, а вот пользовательская объектная модель пока отстаёт от ожиданий типового администратора межсетевого экрана. Хорошая новость в том, что это не скрывается и прямо вынесено в технологический план развития.

Глава 3. Весовая категория: отказ от First Match и приоритеты правил

И тут выяснилось, что в Mirada 900 нумерации правил в привычном смысле нет. Вместо перетаскивания строк вверх-вниз используется вес правила. Сначала обрабатывается правило с максимальным весом и затем все нижележащие. Андрей объяснил это так: dataplane строит классификационное дерево в памяти и учитывает вес как прямой атрибут приоритета, а не визуальную позицию строки в GUI.

Пример понятен: более широкое разрешающее правило с весом 1 будет обработано ниже запрета для конкретного хоста с весом 1000. Для специалистов, привыкших к нумерации правил, логика потребует переучивания и аккуратного подхода к выставлению весов у политик. Я даже вспомнил свои первые курсы программирования на Фокале на БК-0010. Там тоже вес был у каждой команды.

У таблицы правил есть полезное информационное поле — счётчик. Под нагрузкой видно, какие правила реально срабатывают.

В версии 1.2.0 активные сессии в памяти можно посмотреть. На 200 Гбит/с это хороший результат. А вот заблокированные сессии никак не журналируются локально — это точка роста для разработчиков.

Глава 4. User-ID на полставки: Active Directory есть, правил по пользователям — нет

В руководстве Mirada есть раздел Active Directory. Механика узнаваемая: создаётся технологическая учётная запись, права Manage Auditing and Security Log на контроллере домена, чтение Security Event Log и создаётся таблица сопоставления IP-адресов с доменными пользователями. Для инженера, привыкшего к User-ID в NGFW, это выглядит как начало полноценной политики по пользователям.

Но в статических правилах фильтрации учётные записи и доменные группы пока не используются. На мой вопрос «почему нельзя запретить группе «Бухгалтерия» все внешние ресурсы, кроме 1С?» Андрей ответил прямо: статический файрвол версии 1.2.0 работает с IP, подсетями и портами. Динамическая трансляция тысяч доменных сущностей в правила без объектного движка рискует разрушить производительность, ради которой строился dataplane.

Иными словами, User-ID сейчас работает в первую очередь как контекст для СОВ и шаблонов активов. При инциденте в логах можно увидеть не только внутренний IP, но и доменного пользователя. Для расследования это полезно, однако решение позиционируется производителем как DCFW/DCNGFW для использования в сегментах, где User-ID не применяется повсеместно. Полноценная интеграция с серверами каталогов запланирована в следующих релизах.

Глава 5. Скрытые козыри: «FRR Эксперт», контейнеры и ФСТЭК-сертификация

Дальше в документации обнаружились решения, которые явно делались с пониманием реальной пусконаладки. Например «FRR Эксперт». Настройка BGP, OSPF, route-maps и prefix-lists через свежесозданный GUI часто превращается в длинную цепочку кликов. В Mirada базовые задачи оставлены в веб-интерфейсе, и для сложной маршрутизации можно загрузить чистый текстовый файл frr.running.conf.

Для миграции с Cisco это практично: инженер адаптирует имена интерфейсов, загружает рабочий текстовый конфиг и экономит часы ручного переноса. Синтаксис FRRouting (который вырос из проекта Quagga) исторически проектировался как клон классической командной строки Cisco IOS.

Второй важный факт — программный вариант Mirada устанавливается на Astra Linux 1.8 и работает в контейнеризированной среде. Для сертификации это нетривиальная архитектура: веб-интерфейс, локальные базы, коллектор логов и управляющие сервисы изолированы, а dataplane обходит накладные расходы виртуальных мостов Docker и взаимодействует с сетевыми картами напрямую.

В системных настройках видна карта контейнеров: logstash и elasticsearch выделены в стек аналитики, redis отвечает за кэширование, FRRouting разделён на службы по протоколам маршрутизации. На контейнеры наложены лимиты CPU: логгер не может забрать все ядра и задушить Control Plane. Dataplane при этом работает на зарезервированных физических ядрах вне обычной конкуренции пользовательских сервисов.

С регуляторной точки зрения важна утилита «Самотестирование»: система считает контрольные суммы исполняемых файлов и конфигураций, а при несоответствии переводит устройство в аварийный режим. Из интересного — встроенная утилита Arpwatch, которая фиксирует изменения пары IP-MAC и помогает заметить ARP-spoofing. Также есть сканирование подсетей с построением визуальной картины логической топологии без отдельного инструмента.

Глава 6. Режим «Нулевого доверия» во внутренней сети

Классическая IDS по умолчанию здесь включена на периметре: внешние интерфейсы проверяются, а внутренний сегмент считается относительно доверенным. В современных атаках это опасно: компрометация одного рабочего места через фишинг часто становится началом горизонтального перемещения внутри сети.

В Mirada для этого есть переключатель «Режим нулевого доверия» в настройках IDS. При его активации трафик внутренних подсетей сканируется сигнатурными и эвристическими методами так же внимательно, как трафик недоверенного внешнего периметра.

Zero Trust внутри сети требует точной настройки. Проверять каждый байт между серверами базы данных дорого по задержкам, а вот трафик от рабочих станций разработчиков или бухгалтерии к ядру ЦОД — разумная зона контроля. Здесь Mirada даёт инструмент, но результат зависит от реальной сегментации и подходов к эксплуатации устройства.

И да, это именно IDS, функции блокировки не реализованы в текущем релизе.

Глава 7. Изоляция Control Plane, IPMI и честный Enterprise Out-of-Band

Когда вендор говорит «100 Гбит/с», я всегда спрашиваю: что произойдёт с МСЭ и управлением им при DDoS или резком всплеске легитимного трафика? У многих программных шлюзов CPU забивается, веб-интерфейс виснет, SSH не отвечает, а устройство превращается в чёрный ящик.

Андрей пояснил, что mgmt-интерфейс имеет независимую таблицу маршрутизации и коммутации, а под Management / Control Plane зарезервированы ресурсы процессора и памяти. Dataplane не должен «отъесть» эти мощности даже под штормом пакетов на 100 Гбит/с портах.

Есть и нормальный аварийный контур управления: выделенный физический порт IPMI (Intelligent Platform Management Interface) на отдельном сервисном контроллере. Если ядро Linux или консоль управления зависнут, инженер ЦОД сможет удалённо перезагрузить питание, посмотреть аппаратные логи или смонтировать ISO-образ для восстановления. Для корпоративного железа это не роскошь, а базовая гигиена.

Глава 8. Почему нельзя VRRP и магия GARP: как устроен High Availability

High Availability — второй критический узел высоконагруженного периметра. Простейший путь — взять keepalived и VRRP, но для stateful-файрвола это плохой путь. VRRP создавался для маршрутизаторов, которые не обязаны мгновенно переносить состояние миллиона активных сессий на соседнее устройство.

Под высокой нагрузкой или во время DDoS мультикаст-пакеты VRRP могут теряться, резервная нода ошибочно решит, что Master мёртв, и заберёт виртуальный IP. Так появляется split-brain: два устройства одновременно претендуют на один адрес и парализуют сеть.

В Mirada 900 VRRP в кластерной схеме не используется. На резервной ноде боевые IP отсутствуют, интерфейсы молчат, лишний сетевой трафик не генерируется. Для синхронизации выделен физический HA/Sync-порт: conntrack, конфигурации и пакеты согласования идут напрямую между устройствами по этому выделенному каналу.

При отказе Master резервная нода забирает себе управление трафиком, поднимает IP и отправляет Gratuitous ARP (GARP) на широковещательный MAC ff:ff:ff:ff:ff:ff. Коммутаторы обновляют CAM-таблицы и начинают отправлять трафик на новые физические порты. В типичной архитектуре это происходит прозрачно для пользовательских сессий, с минимальной потерей пакетов. Собственно так же работают и основные иностранные межсетевые экраны.

Отдельно решён сценарий LAG/LACP. Пока нода в Standby режиме, её LACP-линки на агрегированном интерфейсе заблокированы или находятся в passive/link-down. После failover новая Master-нода поднимает LACP, собирает bond и уже поверх него отправляет GARP. Это защищает от blackholing, когда коммутатор случайно балансирует трафик на пассивную ноду без IP.

Глава 9. Плотность портов на борту против «LEGO-конструкторов»

В ядре сети и фабрике ЦОД модульность часто превращается в скрытый налог: базовое шасси стоит отдельно, дополнительные 10G/40G/100G интерфейсы — отдельно, лицензии и обслуживание плат — тоже отдельно. В спецификации быстро появляется «конструктор», который усложняет охлаждение, коммутацию и запасные части.

Mirada идёт по пути максимальной портовой плотности на борту. Это относится к линейке сертифицированных аппаратных платформ Mirada 300T, 500X, 500XC, 700, 900 и операторской 900C. Андрей формулирует идею просто: лучше сразу дать инженеру полный набор 10G, 40G и 100G портов, чем вынуждать его докупать модули под каждое расширение.

Для заказчика это экономия места и времени. Свободный SFP+ или QSFP уже есть на панели, не нужно ждать плату. А для Codemaster фиксированная аппаратная база означает предсказуемость: можно оптимизировать Linux, DPDK-стек, драйверы и распределение прерываний под конкретное железо, а не под абстрактный сервер клиента.

Глава 10. Антивирус по доверенности: почему ICAP на 200 Гбит/с — ловушка производительности

В меню безопасности Mirada 1.2.0 есть пункт «Антивирус», но встроенного потокового AV-движка на борту нет. Реализована поддержка ICAP (Internet Content Adaptation Protocol): Mirada выступает ICAP-клиентом, перехватывает веб-трафик, при необходимости расшифровывает TLS, собирает файл в буфер и отправляет его на внешний сервер проверки.

На российском рынке за таким сервером обычно стоят Kaspersky Web Traffic Security или решения Dr.Web. Схема рабочая, но даже на 10 Гбит/с она становится инфраструктурно тяжёлой: файл надо полностью собрать, переслать на внешний узел, дождаться вердикта и только потом отдать пользователю. В документации указан диапазон одновременных подключений от 1000 до 10 000 — для крупной организации это быстро превращается в узкое место.

Главный недостаток ICAP-подхода — скрытый налог на инфраструктуру. Вместе с NGFW заказчику нужен отдельный кластер антивирусных серверов, лицензии, толстый линк и мониторинг задержек. Для зрелого NGFW желателен собственный облегченный потоковый AV-движок, способный анализировать файл без полной сборки тела в памяти. Для Mirada это понятная зона развития.

Глава 11. URL-фильтрация, TLS 1.3 и QUIC

Современная веб-фильтрация — это не просто блокировка домена. Безопаснику важно видеть конкретный URL, GET-запрос, тип файла и контекст: одно дело — легитимный документ на корпоративном хранилище, другое — вредоносный исполняемый файл на том же домене.

Без расшифрования Mirada может анализировать SNI в TLS Client Hello и блокировать сессию на уровне имени хоста. Для доменной блокировки этого достаточно, но увидеть полный URL внутри шифрованного туннеля невозможно. Для этого нужен TLS-шлюз и MITM-инспекция.

TLS 1.2 для корпоративного MITM здесь реализован, хотя дорог по ресурсам. С TLS 1.3 уже сложнее: рукопожатие шифруется раньше, наборы шифров строже, а принудительный downgrade до TLS 1.2 не всегда работает. Дополнительная проблема в сетях — HTTP/2 поверх QUIC/UDP: классический SSL-прокси такой трафик не расшифрует, поэтому его приходится либо блокировать на UDP/443, либо пропускать с ограниченной видимостью.

Также тут еще не реализована база URL-категорий. В версии 1.2.0 контроль опирается на DNS-запросы и фиксированный список доменов и их категорий. Для полноценного класса Secure Web Gateway нужна постоянно обновляемая база категорий и/или репутации. Ручное ведение списков здесь не масштабируется.

TLS-шлюз вынесен в отдельный модуль проксирования, поэтому инспекция не должна валить маршрутизацию dataplane, но на 100 Гбит/с ресурсы для расшифрования нужно считать отдельно.

Глава 12. Инженерная честность: математика логов на сотнях Гбит/с и реальные компромиссы

Разделы «Журналы регистрации» и «Syslog/CEF» в интерфейсе есть, но математика жёсткая. В 1-гигабитный management-интерфейс физически войдёт около 50 тысяч текстовых CEF-сообщений в секунду длиной 2500 байт. Если при 14,24 миллионов пакетов в секунду писать событие на каждый пакет, потребуется отдельный канал в десятки гигабит только под логи, а SIEM на приёмной стороне станет отдельной высоконагруженной системой. Даже при 100 байт на запись это больше 11 Гбит/с чистой полезной нагрузки, без учёта сетевых заголовков, очередей и повторов. В текущей версии есть возможность управлять рейтом syslog-сообщений, ограничивая весь поток логов. Отсюда — риск потери журналов на высоких скоростях.

Из тонкостей, которые важно знать: в интерфейсе в разделе «Сетевые функции → Утилиты → История сессий» видно дату, время, IP-адреса источника и назначения, порты и протокол для прошедших и закрытых соединений. Но заблокированные соединения в этот журнал не попадают: при дропе ACL увеличивает счётчик правила, а детальная запись о сессии не создаётся. Для расследований придётся использовать счётчики, точечный сбор трафика или внешнее зеркалирование/TAP.

Андрей подтвердил, что бэкенд отчётов перерабатывается: план — уйти от текстовой прослойки и передавать бинарные структуры из dataplane напрямую в ClickHouse, рассчитанный на сжатие и индексацию больших потоков событий без лишней нагрузки на CPU.

Важное замечание по метрике CPU: дашборд Mirada показывает агрегированную загрузку по всем 64 ядрам. Dataplane под нагрузкой работает на максимуме — именно так и должен работать изолированный Dataplane. Но в суммарной цифре это размывается остальными ядрами Control Plane и сервисных процессов. Поэтому 19% на дашборде не означает «процессор почти не занят» — это означает, что выделенный пул ядер dataplane занят полностью, а управление при этом не деградирует. Это и есть суть изоляции.

Глава 13. Иллюзия DPI: распознавание приложений через Suricata

От NGFW обычно ждут собственного DPI/App-ID: устройство должно распознавать тысячи приложений, отличать Telegram, BitTorrent, Skype и другие протоколы независимо от порта. В Mirada 1.2.0 эта логика в значительной степени опирается на Suricata: IDS-движок анализирует трафик и отдаёт события, которые дальше обрабатывает аналитический стек.

Suricata — сильный инструмент обнаружения вторжений, но это не то же самое, что проприетарный высокопроизводительный классификатор приложений. Настоящий App-ID обычно анализирует первые пакеты сессии, классифицирует приложение и переводит поток на Fast Path либо продолжает искать в трафике признаки изменений приложения.

Поэтому в текущей версии Mirada корректнее воспринимать распознавание приложений как развивающуюся функцию на базе IDS, а не как полностью зрелый DPI-классификатор уровня крупных зарубежных NGFW. Для грубой L3/L4-фильтрации и высокоскоростного периметра это не критично; для сложных политик по приложениям — ограничение.

Глава 14. Модель Кано: что уже работает и что должно дозреть до NGFW

Для продуктовой оценки я использую модель Кано: есть обязательные характеристики (Must-be), есть показатели производительности (Performance), а есть привлекательные функции (Delighters). Если базовые Must-be закрыты не полностью, красивые дашборды не спасают продукт в эксплуатации.

1. Обязательные характеристики L4-файрвола

На L4 обязательны стабильная фильтрация, NAT, понятное журналирование, а в корпоративных сетях — прикладные хелперы/ALG для legacy-протоколов. У Mirada сильная сторона — сверхбыстрая L3/L4-фильтрация на DPDK и нулевые потери в нагрузочных профилях. Слабые места версии 1.2.0 — ограниченная NAT-логика по ICMP, отсутствие описанных ALG для SIP/FTP/H.323 и отсутствие журналирования заблокированных событий локально. Это точка роста.

2. Обязательные характеристики L7/NGFW

Для полноценного NGFW нужны объектный движок политик, User-ID в правилах, зрелый DPI/App-ID, URL-категоризация, потоковый AV и корректная работа с современным TLS/QUIC. В Mirada эти функции находятся на разных стадиях зрелости: Active Directory уже даёт контекст, Suricata закрывает IDS-часть, TLS-шлюз есть, но связки уровня зрелых зарубежных NGFW пока не хватает.

3. Характеристики производительности

Здесь Mirada выглядит убедительно: высокая пропускная способность, миллионы PPS на мелких пакетах, изолированный Control Plane, собственная HA-схема без VRRP, выделенный HA/Sync и высокая плотность физических портов. Это не косметика, а фундамент, который сложно быстро повторить.

Глава 15. Инженерный подход: когда «своё железо» — не просто звук

Многие отечественные вендоры берут стандартную OEM-платформу x86, устанавливают операционную систему и называют результат программно-аппаратным комплексом (ПАК). Codemaster выбрал более трудный путь: изучает физические свойства своего железа, питание и охлаждение сетевых плат, чтобы они не уходили в термический троттлинг при длительной пиковой нагрузке. Обычно это незаметно, однако перегрев — одна из причин выключения устройств. В моей практике даже был вендор межсетевого экранирования, который выключился от перегрева после 2 часов работы под нагрузкой в ЦОД.

Такие вещи редко попадают в красивые буклеты, но именно они отличают промышленный ПАК от лабораторной сборки. Когда софт и железо проектируются как единая платформа, проще контролировать драйверы, PCIe, распределение прерываний, поведение DPDK и воспроизводимость результатов.

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

И что важно готовая аппаратная реализация в виде ПАК полезна тем, что устройство развёртывается у заказчика в сети буквально за несколько часов.

Глава 16. Мифы «независимой статистики» и открытый роадмап

В ИТ-маркетинге есть привычный приём: вендор нанимает агентство, получает красивый график с анонимными респондентами и рассказывает, что продукт «лучше конкурентов» по очередной независимой методике. Такие материалы редко помогают сетевому архитектору принять решение: ему важнее поведение устройства в его схеме, под его нагрузкой и с его ограничениями.

Я спросил Андрея, как в таком случае заходить в Enterprise. Ответ был логичным: через пилот, открытую документацию и честный роадмап. Да, в версии 1.2.0 статические правила ещё без привычных объектов, отчёты мигрируют к ClickHouse, а L7-функции дозревают. А рядом с этим важно отметить прекрасную работу Control Plane в то время как Dataplane под 100% нагрузкой, отлаженный механизм HA, устоичивую работу на миллионах PPS и аппаратную платформу на базе ASIC, оптимизированную под конкретную задачу фильтрации трафика.

Именно здесь, на мой взгляд, у Mirada появляется правильное позиционирование. Это не история про «мы уже заменили всех мировых лидеров по всем функциям». Это история про российского производителя и разработчика, который начал с самого сложного — быстрого сетевого ядра, отказоустойчивости и управляемой аппаратной платформы — и открыто достраивает вокруг них сервисы безопасности.

---

Итог продуктового аудита

Mirada 1.2.0 демонстрирует готовность в сегменте L4-файрвола, а не как полностью завершённый SWG/NGFW. Существующее разделение Dataplane и Control Plane, микросервисная архитектура, изоляция ресурсов, HA и аппаратная реализация выводят устройство как мощный промышленный ПАК.

Для достижения функциональной полноты класса NGFW/SWG ещё предстоит расширить объектную модель, реализовать поддержку User-ID в политиках безопасности, развить механизмы DPI/App-ID, категоризацию URL, потоковый антивирусный контроль и расширенное журналирование заблокированных событий.

Вместе с тем уже сегодня Mirada наиболее эффективно решает задачи, где определяющими являются высокая производительность фильтрации на уровнях L3/L4, минимальная задержка обработки пакетов, высокая плотность портов, предсказуемость аппаратной платформы, отказоустойчивость (HA) и наличие сертифицированной отечественной программно-аппаратной базы.

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