Виртуальные контексты в Ideco NGFW: как работает VCE изнутри
Когда сеть разрастается до нескольких сегментов с пересекающейся адресацией, нескольких арендаторов или нескольких зон с разными требованиями к безопасности, возникает вопрос: как обеспечить изоляцию на уровне межсетевого экрана, не покупая отдельное устройство под каждую задачу?
Один из ответов на этот вопрос — виртуальные контексты. В Ideco NGFW эта технология реализована под названием VCE (Virtual Context Engine). В этой статье разберём, что это такое архитектурно, как работает изнутри и в каких сценариях это имеет практический смысл.
Три плоскости NGFW: точка отсчёта
Прежде чем говорить о контекстах, нужно зафиксировать базовую модель. В NGFW традиционно выделяют три функциональных плоскости:
Data plane — обрабатывает трафик: сетевой стек, фильтрация, NAT, маршрутизация пакетов.
Control plane — управляет сетевыми функциями: протоколы маршрутизации, построение таблиц, IKE для VPN.
Management plane — обеспечивает управление самой системой: веб-интерфейс, API, мониторинг, логирование.
VCE — это изолированная копия data plane и control plane. Management plane при этом остаётся общим и в контексты не входит.
Архитектурно это означает: система состоит из одного management plane и одного или нескольких контекстов, каждый из которых самостоятельно обрабатывает трафик и управляет своей сетевой конфигурацией.
Схема наглядно показывает разделение Management plane, VCE 1/2/3 с разными типами data plane (VPP и Legacy), распределение интерфейсов и VLAN. -->
С точки зрения информационной безопасности management plane рекомендуется изолировать полностью — вплоть до выделенного физического интерфейса или отдельной сети. Изоляция управляющей плоскости от трафика данных — одно из требований сертификации ФСТЭК по ММЭУС.
Зачем нужны несколько контекстов
Пересечение адресного пространства
В крупных распределённых сетях пересекающиеся диапазоны IP-адресов — норма, а не исключение. Классическое решение — VRF (Virtual Routing and Forwarding). Но VRF разделяет только таблицы маршрутизации. Если нужно разделить не только маршрутизацию, но и политики фильтрации, методы аутентификации, DNS-резолвер — VRF уже не помогает.
Пример: адрес 10.20.30.40 в контексте А принадлежит одному пользователю, в контексте Б — другому. В рамках единого контекста различить их по IP невозможно, и динамическая маршрутизация в такой топологии превращается в источник ошибок.
Изоляция нагрузки
Перегрузка одного контекста по трафику не распространяется на соседние. Это важно как для защиты от DDoS, так и для обеспечения принципа graceful degradation: при деградации одного сегмента остальные продолжают работать штатно.
Отказоустойчивость при ошибках конфигурации
Ошибка администратора, сбой программного компонента или некорректное обновление затрагивают только конкретный контекст. Контекст можно перезапустить без влияния на остальную систему. Это принципиально отличается от ситуации, когда вся инфраструктура работает в одном пространстве и одна ошибка может сломать всё.
Безопасность сильнее правил файрвола
Даже идеально написанные правила межсетевого экрана — это программная логика. Контекст — это архитектурная граница. Трафик, который не должен пересекаться между сегментами, физически не может пройти из одного контекста в другой: у них разные сетевые стеки, разные таблицы, разные состояния сессий.
Это эквивалент установки отдельного устройства, но на одном железе.
Административная независимость
Ряд параметров в Ideco NGFW глобален для всей системы. При использовании контекстов они становятся глобальными в рамках каждого контекста. Это значит, что для каждого контекста можно независимо настраивать: методы аутентификации пользователей, политики доступа, страницу блокировки, DNS.
Альтернатива — сложная структура профилей на базе зон и интерфейсов. Контексты проще и надёжнее, если сценарии использования не требуют сквозной связности между сегментами.
Подготовка к горизонтальному масштабированию
Если в будущем планируется распределить обработку трафика между несколькими физическими устройствами, контексты позволяют заранее реализовать эту модель на одном устройстве. Переход к распределённой схеме не потребует переработки логики — только переноса контекстов.
Тестовые среды и honeypot
В соседнем контексте можно развернуть тестовую среду, honeypot или стенд для отладки новых настроек — полностью изолированно от продуктивных процессов.
Два типа контекстов: классический и высокопроизводительный
Виртуальные контексты в Ideco NGFW реализованы в двух вариантах.
Классические контексты используют сетевой стек ядра Linux: netfilter, IPSec, стандартная маршрутизация. Трафик распределяется по VLAN: конкретные VLAN или физические интерфейсы передаются внутрь выбранного контекста.
Высокопроизводительные контексты основаны на DPDK и VPP. Здесь внутрь контекста передаётся вся сетевая карта целиком, а не отдельные VLAN. Производительность и масштабируемость значительно выше, но функциональный паритет с классическим стеком пока не достигнут.
Сейчас поддерживаются оба варианта. Стратегическое направление — полный переход на DPDK/VPP. Обработка трафика в корневом контексте (legacy-режим) считается устаревшей и будет удалена; миграция для существующих инсталляций пройдёт бесшовно.
Одно ограничение, которое нужно учитывать при работе с классическими контекстами: при разделении трафика по VLAN физический интерфейс остаётся общим. Перегрузка этого интерфейса затронет все контексты, использующие его порт. Это не архитектурный изъян, а следствие физической модели — его нужно учитывать при проектировании.
Ресурсная изоляция
Каждый контекст жёстко привязан к выделенным ресурсам: CPU-ядра, оперативная память, сетевые карты. Объём ресурсов задаётся вручную при создании контекста. Оптимальные значения зависят от структуры трафика, модели процессора и объёма правил фильтрации — и подбираются через мониторинг.
Ресурсы изолированы не только между контекстами, но и от management plane. Это означает, что при DDoS-атаке на один из контекстов доступ к управлению системой сохраняется.
У такой модели есть цена: простаивающие ресурсы одного контекста нельзя динамически перераспределить в пользу другого. На платформах с небольшим числом ядер это может выглядеть как неэффективное использование оборудования. Это осознанный компромисс: жёсткая изоляция важнее гибкости аллоцирования.
Второе ограничение — количество контекстов ограничено числом ядер и объёмом памяти платформы. На практике это редко становится проблемой: сценарии, требующие более десяти контекстов на одной аппаратной платформе, встречаются нечасто.
Архитектура изнутри: контейн��ризация без гипервизора
Виртуальные контексты реализованы на базе контейнеризации, а не гипервизора. Конкретная технология — systemd-nspawn.
Общая файловая система (Erofs, режим только для чтения) используется как корневым контекстом, так и всеми виртуальными. Изменяемая часть реализована через overlayfs: каждому контексту не нужен отдельный образ, что экономит место и ускоряет запуск.
Схема показывает послойную структуру: SSD → LVM → EROFS (read-only) → OverlayFS на каждый VCE → systemd внутри контейнера. -->
Внутри каждого контейнера запускается полноценный systemd с изолированным target-окружением. В него входят data plane и control plane. Часть management plane пока также находится внутри контекста — это текущее ограничение реализации, которое будет устранено в следующих версиях.
Некоторые сервисы вынесены в корневой контекст и являются общими: антивирусный движок, ClickHouse для хранения логов. Это снижает накладные расходы и предотвращает недоиспользование ресурсов при большом количестве контекстов.
Схема показывает, как общие сервисы в Management plane обслуживают несколько NGFW и их VCE, и фиксирует ограничение: перегрузка ClickHouse влияет на отчётность, но не на трафик. -->
Ключевое преимущество контейнерной модели перед гипервизорной: контексты работают в виртуальной среде без вложенной виртуализации. Нет накладных расходов на трансляцию инструкций, нет проблем с поддержкой аппаратных возможностей внутри вложенного гипервизора.
Про изоляцию честно
Контейнеризация даёт несколько уровней изоляции: разделённые сетевые стеки, отдельные файловые системы, пространства имён. Это работает.
Но важно понимать: текущая реализация не является multitenancy в строгом смысле. Часть процессов остаётся привилегированной по системным причинам. Иными словами, VCE — это мощный инструмент операционного разделения, но не замена полной изоляции на уровне гипервизора в сценариях, где это критично.
Интеграция с Ideco Center и кластером
Виртуальные контексты полностью интегрированы с центральной консолью управления Ideco Center. При добавлении устройства или кластера в консоль каждый контекст отображается как отдельная управляемая сущность с возможностью группировки и применения общих политик безопасности.
Схема показывает, как кластер NGFW и отдельный NGFW представлены в Ideco Center: каждый VCE виден как отдельная сущность, контексты группируются под общие политики. -->
В кластерной конфигурации все контексты работают на активной ноде. При переключении они продолжают работу на резервной ноде без потери состояния.
Схема Active/Standby показывает, что VCE наследуют состояние ноды, связь между VCE идёт через отдельные VLAN, root участвует в cluster link. -->
Направления развития
Ближайшие изменения в реализации VCE:
Вынос management plane из контекстов. Это устранит текущее архитектурное ��граничение и сделает изоляцию более строгой.
Новые типы контекстов — в том числе для сервисов, выходящих за рамки классической фильтрации трафика.
Развитие multitenancy на базе вложенных контейнеров, где каждый tenant получит собственный management plane и собственные VCE.
Общая таблица сессий авторизации и виртуальные линки между контекстами — для сценариев с контролируемым взаимодействием между изолированными сегментами.
Корневой контекст будет выведен из режима обработки трафика и станет исключительно management plane.
Итог
VCE — это архитектурный механизм, решающий конкретный класс задач: операционная изоляция сегментов сети на уровне одной платформы без дублирования оборудования.
Контексты дают предсказуемое поведение при отказах, изоляцию адресного пространства без VRF-костылей, независимость конфигурации на уровне каждого сегмента и подготовленную почву для горизонтального масштабирования.
Контейнерная реализация без гипервизора означает работу в виртуальных средах без потерь производительности. Жёсткая привязка ресурсов означает предсказуемость поведения под нагрузкой.
Ограничения тут тоже есть: статическое распределение ресурсов, отсутствие строгого multitenancy в текущей версии, зависимость классических контекстов от физического интерфейса при использовании VLAN. Всё это — известные компромиссы с понятной причиной.
