Начните со схемы потоков
Отметьте на схеме внешние каналы, DMZ, филиалы, облака и внутренние сегменты. Для каждого потока определите, через какую точку он должен проходить. Это покажет, требуется ли выделенный сетевой узел или NGFW удобнее разместить внутри виртуальной инфраструктуры.
В обоих вариантах заранее опишите путь управления: как администратор получит доступ при проблемах с маршрутизацией, виртуальным коммутатором или основным каналом. Управление не должно зависеть от единственного защищаемого приложения.
Когда полезна выделенная аппаратная платформа
ПАК удобно рассматривать, когда требуется выделенный узел с определённым набором физических интерфейсов и отдельной зоной ответственности. В проекте остаётся проверить подключения, питание, размещение и обслуживание устройства.
Состав интерфейсов и условия эксплуатации сверяйте с документами выбранной модели. При сравнении учитывайте также запасные компоненты, доступ к стойке и возможность обслуживания без отключения всей площадки.
Что проверить у виртуального варианта
Для виртуальной машины зафиксируйте гипервизор, распределение CPU и памяти, виртуальные сетевые адаптеры и путь каждого интерфейса. Согласуйте порядок резервирования ресурсов и действия при конкуренции за них.
Проверьте поведение во время резервного копирования и обслуживания хоста. Перенос виртуальной машины и отказ хоста являются отдельными сценариями: удачный запуск NGFW не подтверждает сохранение прикладных сессий при каждом таком событии.
- Ресурсы и правила их распределения
- Изоляция управляющих и транзитных сетей
- Зависимость от хранилища и сетевых коммутаторов
- Доступ администратора при отказе хоста
Разделите резервирование NGFW и инфраструктуры
Кластер гипервизоров и отказоустойчивость сетевого экрана решают разные задачи. Постройте схему доменов отказа: хост, коммутатор, питание, хранилище и канал связи. Размещение двух экземпляров в одном домене оставляет общий риск.
Проверьте отказ каждого компонента по отдельности и затем возврат к штатной схеме. Время восстановления оценивайте на стороне критичного приложения, а не только по смене статуса узла.
Как сравнить варианты на пилоте
Используйте один набор приложений, потоков, защитных модулей и критериев приёмки. Для виртуальной машины сохраните параметры хоста; для ПАК — модель и состав интерфейсов. Результаты разных режимов фильтрации оценивайте раздельно.
Итоговая матрица должна отвечать, кто обслуживает каждый слой, какие общие точки отказа остаются и какая схема проходит программу испытаний. Финансовое сравнение делайте по согласованным предложениям, без подмены цены предположениями.
Рабочая таблица проекта
Заполните таблицу для своей инфраструктуры. Значения и допустимые отклонения согласуйте до начала испытаний; готовый результат можно приложить к запросу конфигурации.
| Критерий | ПАК | Виртуальная машина |
|---|---|---|
| Ресурсы | Выделенная платформа | Параметры и резервирование на хосте |
| Подключения | Физические порты выбранной модели | Виртуальные адаптеры и коммутация |
| Домены отказа | Питание, устройство, внешние связи | Хост, хранилище, виртуальная сеть |
| Эксплуатация | Доступ к устройству и замена | Согласованные действия сетевой и виртуальной команд |
| Приёмка | Пилот на выбранной модели | Пилот на целевом гипервизоре |
Практический результат
Результат — заполненная таблица и программа проверки с измеримыми условиями приёмки. По ним можно сравнить варианты на одинаковом профиле нагрузки и согласовать конфигурацию с инженером.
Документация производителя
Нужна проверка на вашей схеме?
Подготовим методику и конфигурацию под инфраструктуру, а не под демонстрационный стенд.
