/ DOCS
nav-img
Evolution
Архитектурный центр

Виртуальный NGFW в качестве ядра сети в тенанте заказчика в отдельном кластере ESXi

Чтобы обойти ограничение количества виртуальных интерфейсов на аплаинс, информационную безопасность виртуальной инфраструктуры заказчика можно организовать с использованием паттерна виртуального NGFW в качестве ядра сети в тенанте заказчика, размещенном в отдельном кластере ESXi. Возможна организация более 10 виртуальных интерфейсов на аплаинс.

Паттерн виртуального NGFW в качестве ядра сети в тенанте заказчика в отдельном кластере ESXi имеет следующие преимущества и риски:

Преимущества паттерна

Риски

  • Ограничения на количество виртуальных интерфейсов на аплаинс зависят от выделенных под NGFW ресурсов.

  • Контроль трафика e-w, n-s.

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

  • Заказчик должен арендовать место под физический NGFW в ЦОДе Cloud.ru.

Общая схема

../../_images/schm__templates_security-tools_cloud-vmware_virtual-ngfw-esxi.svg

Описание паттерна

Предварительные требования:

  • Наличие у заказчика виртуального ЦОД на платформе Облако VMware.

Реализация

Single node:

  1. Заказчику выделяется пул белых адресов для внешнего интерфейса NGFW.

  2. Заказчик разворачивает виртуальный NGFW на инфраструктуре, размещенной в ЦОДе Cloud.ru.

  3. Команда Cloud.ru настраивает bridge необходимых сегментов инфраструктуры Заказчика.

  4. Внешний интерфейс аплаинса подключается к Edge/T1 для маршрутизации в интернет, остальные интерфейсы создаются как isolated и подключатся к NGFW.

  5. На NGFW Заказчик настраивает 0.0.0.0 в сторону Edge/T1.

  6. На Edge/T1 Заказчика настраивается редистрибуция маршрутов для сегмента с белыми адресами в сторону Provider Gateway/T0.

  7. Интерфейсы Заказчика настраиваются как isolated и подключаются к аплаинсу.

Cluster:

  1. Заказчику выделяется пул белых адресов для внешнего интерфейса NGFW.

  2. Заказчик разворачивает виртуальный NGFW на инфраструктуре, размещенной в ЦОДе Cloud.ru.

  3. Команда Cloud.ru настраивает bridge необходимых сегментов инфраструктуры Заказчика.

  4. Внешний интерфейс аплаинса подключается к Edge/T1 для маршрутизации в интернет, остальные интерфейсы создаются как isolated и подключатся к NGFW.

  5. На NGFW Заказчик настраивает 0.0.0.0 в сторону Edge/T1.

  6. На Edge/T1 Заказчика настраивается редистрибуция маршрутов для сегмента с белыми адресами в сторону Provider Gateway/T0.

  7. На аплаинсах выделяется отдельный интерфейс для сборки кластера.

  8. Интерфейсы Заказчика настраиваются как isolated и подключаются к аплаинсу.

См.также
Была ли статья полезной ?
Предыдущая статья
Виртуальный NGFW в качестве ядра сети в тенанте заказчика в «Виртуальный ЦОД»
Следующая статья
Виртуальный NGFW для сегмента DMZ
Поддержка Юридические документы
© 2025 Cloud.ru