Миграция ViPNet Policy Manager и ViPNet StateWatcher в ViPNet Prime

Продолжаем цикл статей, посвящённых миграции сети и данных из управляющих приложений четвёртого поколения в управляющие приложения пятого поколения. В данной статье мы сосредоточимся на детальном рассмотрении процесса переноса данных из модулей ViPNet Prime. Модуля мониторинга, включающих сведения об устройствах и параметрах, из приложения ViPNet StateWatcher в модуль Network Visibility System (NVS) ViPNet Prime. Одновременно опишем перенос политик безопасности из ViPNet Policy Manager в модуль ViPNet Policy Management.

Мы последовательно определим типы данных, подлежащих миграции, и их целевые модули в ViPNet Prime, проанализируем условия, необходимые для начала миграционного процесса, а также оценим текущее состояние сети и развёрнутых управляющих приложений. Особое внимание будет уделено готовности инфраструктуры к переходу с управляющего приложения четвёртого поколения ViPNet State Watcher на современный модуль NVS.

Подготовка к миграции модулей ViPNet Prime

Условия миграции

Процесс миграции данных предполагает последовательный экспорт информации из исходных систем с последующей загрузкой в целевые модули ViPNet Prime.

Сначала выполняется экспорт данных из ViPNet Policy Manager: выгружаются шаблоны политик безопасности и вспомогательные файлы, которые впоследствии импортируются в модуль ViPNet Prime Policy Management.

Аналогичным образом осуществляется работа с данными из ViPNet StateWatcher. С помощью штатных средств интерфейса приложения данные экспортируются в XML‑файл, который затем переносится в модуль ViPNet Prime Network Visibility System (NVS).

Для успешного проведения миграции необходимо соблюдение следующих условий:

1. Защищённая сеть должна быть перенесена под управление ViPNet Prime версии 1.9.11. Это критически важно, поскольку узлы защищённой сети используются в составе политик безопасности и впоследствии будут поставлены на мониторинг с помощью модуля NVS.

2. В сети должны быть развёрнуты управляющие приложения ViPNet Policy Manager (версия не ниже 4.5.5) и ViPNet StateWatcher (версия не ниже 4.9.2). Если установленные версии ПО ниже указанных, требуется предварительное обновиться до требуемых версий и только после этого можно приступать к экспорту данных.

Что нужно для миграции?

В предыдущих статьях цикла мы рассматривали процесс загрузки файла лицензии формата .itcslic на сеть ViPNET Prime. Для использования функциональности модулей Policy Management Module (PMM) и Network Visibility System (NVS) необходимо, чтобы соответствующие лицензии были включены в файл лицензии. Кроме того, должны быть добавлены лицензии на требуемое количество Policies Nodes и Monitoring Nodes.

Помимо лицензий, для успешной миграции потребуются следующие компоненты:

• Скрипт обогащения и скрипт импорта данных — необходимы для получения дополнительных вспомогательных файлов из ViPNET Policy Manager. Эти скрипты входят в комплект поставки модуля ViPNET Policy Management.

• Дистрибутив сборщика данных — его потребуется установить и настроить. Сборщик данных необходим для реализации сквозного сценария: не только переноса устройств мониторинга со всеми параметрами, но и последующего получения данных с этих устройств. В рамках данной статьи сборщик данных уже предварительно подготовлен.

Дополнительно в статье будет рассмотрен вариант установки модулей на одну машину. При этом демонстрация процесса установки самих модулей не предусмотрена. В первой статье цикла уже приводились подробные инструкции по установке ViPNET Prime.

Рекомендации по установке модулей:

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

• Либо выполните установку с помощью стандартных дистрибутивов из комплекта поставки модулей ViPNET PMM и ViPNET NVS.

Особенности миграции в VIPNet Prime PMM

При миграции политик безопасности в ViPNET Prime PMM необходимо учитывать ряд важных особенностей, влияющих на корректность переноса и последующую работу системы:

1. Соответствие шаблонов и слоёв. Один шаблон политики безопасности в Policy Manager (PM) соответствует одному слою в Policy Management Module (PMM).

2. Сохранение порядка правил. Порядок правил внутри шаблона политики безопасности (то есть внутри слоя в PMM) сохраняется при миграции.

3. Приоритеты шаблонов. Поскольку шаблоны импортируются в систему последовательно, их приоритеты относительно друг друга не сохраняются автоматически. Администратору необходимо вручную настроить приоритеты слоёв в PMM после завершения импорта.

4. Ручная настройка параметров политик. Ряд настроек требуется задавать вручную для отдельных устройств или групп устройств. К таким настройкам относятся:

• опция переключения режима работы для координаторов IG (ранее задавалась в Policy Manager, теперь должна быть включена вручную для соответствующих координаторов в PMM);

• правила обработки прикладных протоколов — их также необходимо настроить вручную в рамках политики безопасности.

5. Назначение политик и лицензий. Автоматическое назначение политик безопасности на устройства не предусмотрено. Администратору требуется:

• вручную назначить политики на соответствующие устройства;

• списать лицензии для задействованных устройств.

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

Экспорт данных в ViPNet Policy Management Module

На текущем этапе мы работаем с интерфейсом Policy Manager. На рисунке 1 представлен скриншот управляющего программного обеспечения, на котором отображены сетевые узлы, уже перенесённые под управление ViPNet Prime VPN: открытые клиенты, координаторы и компоненты xFirewall.

Рис.1 Скриншот управляющего ПО Policy Manager.

Далее обратимся к конфигурации шаблонов политик безопасности. В системе зарегистрированы шаблоны различных типов — отдельно для клиентов, координаторов и xFirewall. Каждый шаблон содержит набор правил фильтрации и трансляции с чётко определёнными действиями, источниками и назначениями трафика.

Рис.2 Шаблоны политики безопасности ПО Policy Manager.

При детальном рассмотрении любого из шаблонов подтверждается их полная готовность к экспорту данных: структура заполнена корректными правилами, соответствующими текущей политике безопасности сети. Это позволяет приступить к непосредственному экспорту данных для последующей миграции в ViPNET Prime PMM.

Рис.3 Свойства шаблона политик безопасности ПО Policy Manager.

В составе правил фильтрации и трансляции, заданных в шаблонах политик безопасности, активно используются группы объектов. Проведённая проверка подтвердила, что все необходимые группы объектов созданы в системе Policy Manager, корректно настроены и наполнены актуальными данными.

Данные группы будут выгружены штатными средствами экспорта Policy Manager.

Рис.4 Раздел групп объектов ПО Policy Manager.

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

В рамках текущего сценария, поскольку используется тестовая сеть с тестовыми данными, для демонстрации процесса мы выбираем три шаблона: шаблон для клиента, шаблон для координатора и шаблон для xFirewall.

Рис.5 Выбранные шаблоны политик безопасности ПО Policy Manager.

Далее выбираем директории для сохранения экспортируемых данных.

Рис.6 Выбор директории для экспорта политик безопасности.

Рис.7 Уведомление об успешном экспорте шаблонов из ПО Policy Manager.

Полученных на предыдущем этапе данных недостаточно для непосредственного импорта в ViPNet Policy Management Module (PMM). Для подготовки полного комплекта необходимых файлов требуется выполнить запуск скрипта обогащения. Открываем PowerShell, копируем команду из руководства администратора Vipnet Prime PM и запускаем её. В результате работы скрипта будут автоматически сформированы все вспомогательные файлы, необходимые для корректного импорта данных в модуль управления политиками.

Рис.8 Запуск скрипта обогащения в PowerShell.

Импорт данных в ViPNet Policy Management Module

Подготовка к импорту

Прежде чем приступить к миграции данных в ViPNet Policy Management Module, важно убедиться, что система настроена корректно и все необходимые условия выполнены.

Сначала проверяем организацию и лицензии:

• открываем главную консоль управления ViPNet Prime;

• убеждаемся, что файл лицензии загружен;

• проверяем, что лицензия на модуль политик присутствует в составе лицензионного файла;

Рис.9 Проверка лицензии модуля политик в консоли управления ViPNet Prime.

• уточняем распределение лицензий на управляемые устройства — они должны быть назначены организации Corn Network;

• подтверждаем, что лицензии пока не использованы.

Рис.10 Проверка распределения лицензии между организациями в консоли управления ViPNet Prime.

Далее переходим в модуль ViPNet VPN. Здесь проверяем, что все защищённые устройства (клиенты и координаторы) уже перенесены под управление ViPNet Prime из ViPNet Administrator. Это узлы защищённой сети, которые будут участвовать в политиках безопасности.

Рис.10 Список клиентов в модуле VPN в консоли управления ViPNet Prime.

Затем проверяем назначение сервисной функции: для выбранного узла должна быть назначена функция «Центр управления политиками безопасности». Без неё невозможно формировать и отправлять результирующие политики на устройства. Узел выбран, сервисная функция назначена. Если все проверки пройдены успешно, система готова к миграции.

Рис.11 Раздел сервисных функций в консоли управления ViPNet Prime.

Наконец, переходим в модуль Policy Management. Здесь критически важно убедиться, что модуль чист:

• нет ранее созданных политик безопасности;

• отсутствуют заведённые группы объектов (адреса открытой сети, устройства защищённой сети и пр.);

• не было выполнено никакого импорта данных (ни вручную, ни автоматически).

Проверяем каждую вкладку в модуле.

Рис.12 Проверка данных в Policy Management Module.

После перехода на вкладку «Интеграция» система готова к выполнению импорта данных. В интерфейсе предоставляется выбор источников импорта: Check Point или Policy Management. В рамках текущей статьи мы импортируем из Policy Manager.

Импорт данных

Рис.13 Выбор источника импорта в интерфейсе Policy Management Module.

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

Рис.14 Мастер импорта из Policy Manager.

Дополнительно в интерфейсе предусмотрена справочная информация для администратора. Она содержит:

• общие сведения о процессе импорта шаблонов политик безопасности;

• правила именования объектов при миграции;

• рекомендации по импорту групповых объектов.

Эта справка служит вспомогательным инструментом, помогающим избежать ошибок и обеспечить корректность переноса данных в Prime PMM.

Полное описание процедуры есть в руководстве администратора. Здесь только краткая выжимка: только самое важное, чтобы администратор мог быстро найти нужные сведения и приступить к работе.

Рис.15 Справка в мастере импорта из Policy Manager.

Возвращаемся к работе с мастером импорта. На текущем этапе счётчик загруженных шаблонов отображает значение «0», а вспомогательные файлы в системе отсутствуют — они ещё не загружены.

Рис.16 Импорт шаблонов из Policy Manager.

Приступаем к загрузке подготовленных данных:

• выбираем экспортированные ранее шаблоны политик безопасности;

• загружаем вспомогательные файлы, сформированные в результате выгрузки из базы данных.

Рис.17 Загрузка подготовленных файлов для импорта.

После выполнения этих действий наблюдаем изменение счётчика загруженных шаблонов — он отражает количество выбранных шаблонов (в нашем случае — три, экспортированных ранее из Policy Manager).

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

Рис.18 Успешно загруженные файлы шаблонов политик безопасности в мастере импорта.

На втором шаге в мастере импорта предоставляется возможность выбрать режим обработки групп объектов:

• создание новых групп при импорте данных;

• использование существующих групп, уже присутствующих в модуле ViPNet PMM.

Второй вариант актуален в следующих случаях:

• если группы объектов были созданы вручную;

• если ранее выполнялся частичный импорт данных и в системе уже присутствуют необходимые группы объектов. В этом случае существующие группы будут задействованы в новых шаблонах политик безопасности.

Поскольку на предыдущем этапе было подтверждено отсутствие каких‑либо данных в модуле, выбираем режим создания новых групп. После подтверждения выбора инициируем процесс импорта.

Рис.19 Выбор параметров импорта групп объектов Policy Manager.

В ходе выполнения операции отображается информационное окно, информирующее о текущем статусе импорта: загрузке шаблонов политик безопасности. Дополнительную информацию о процессе можно отслеживать на вкладке «Интеграция» — здесь отображается статус последнего импорта.

Рис.20 Выполнение импорта групп объектов в интерфейсе ViPNet Policy Management.

По завершении операции доступны следующие данные:

• время начала и окончания импорта;

• итоговый статус операции;

• возможность скачать журнал ошибок для анализа возможных проблем.

Рис.21 Просмотр статуса импорта в интерфейсе ViPNet Policy Management.

Журнал ошибок

Для демонстрации формата журнала ошибок были намеренно внесены ошибки в правила фильтрации и групповые объекты в Policy Manager.

Журнал ошибок формируется в формате .xlsx и содержит следующие столбцы:

• Имя файла — имя шаблонов «Политики безопасности» в PM и слоев в PMM, в которых обнаружена ошибка. Это позволяет точно локализовать проблемный элемент.

• Идентификатор объекта — помогает идентифицировать проблемный элемент. Если идентификатор начинается с 200 000, это указывает на правило.

• Имя объекта — название элемента, в котором найдена ошибка.

• Описание проблемы — текстовое описание ошибки (представлено на английском языке).

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

При обнаружении ошибок возможны следующие действия:

1. Внести исправления непосредственно в Policy Manager.

2. Удалить данные из PMM.

3. Повторно выполнить импорт уже исправленных данных.

Система автоматически валидирует загружаемые данные. Если ошибок не обнаружено, журнал не формируется, а статус операции отображается как «Импортировано».

Рис.22 Журнал ошибок импорта Policy Management.

Проверка политик безопасности

После завершения импорта данных необходимо убедиться, что политика безопасности успешно создана. Для этого:

1. Перейдите на вкладку «Политики».

2. Проверьте наличие созданной политики и её статус. В нашем случае статус указывает, что политика не назначена ни на одно устройство.

3. Откройте политику безопасности для детального анализа.

Рис.23 Созданные политики в интерфейсе Policy Management.

Переходим в политику безопасности и видим, что у нас созданы правила фильтрации трафика. Они представлены в ViPNET PM различных типов.

Проверьте количество правил для каждого типа фильтрации — эта информация отображается напротив соответствующего типа, при необходимости переключитесь между типами правил для детального просмотра.

Рис.24 Правила фильтрации трафика политик в интерфейсе Policy Management.

Дополнительно убедитесь в корректности переноса правил трансляции адресов (NAT). В нашем сценарии правила NAT содержались в двух из трёх исходных шаблонов и были успешно перенесены в политику безопасности.

Рис.25 Правила трансляции адресов NAT в интерфейсе Policy Management.

Важно отметить, что все шаблоны политик безопасности, экспортированные из Policy Manager, загружаются в единую политику в модуле Policy Management Module (PMM). Это обеспечивает централизованное управление политиками и упрощает администрирование.

Импортированная политика безопасности выступает в роли базового шаблона («донора») для дальнейшей настройки. В последующих разделах будет продемонстрирован процесс донастройки политики и её отправки на целевое устройство.

Каждый слой политики безопасности соответствует одному шаблону политики безопасности из Policy Manager. При этом:

• для правил фильтрации трафика создаётся один слой с наименованием, полностью идентичным названию шаблона в Policy Manager;

Рис.26 Слои правил фильтрации трафика в интерфейсе Policy Management.

• для правил трансляции трафика (NAT) создаётся отдельный слой с тем же именем. В результате для одного шаблона может быть сформировано два слоя;

• если в исходном шаблоне отсутствуют правила трансляции, соответствующий слой не создаётся.

В нашем сценарии из трёх возможных слоёв были созданы два — это соответствует структуре исходных шаблонов.

Рис.27 Слои правил трансляции адресов NAT в интерфейсе Policy Management.

Аналогично механизму приоритезации шаблонов в Policy Manager, в PMM предусмотрена возможность установки приоритетов между слоями политики безопасности. Порядок приоритетов определяет последовательность применения правил при обработке трафика.

Пример настройки:

1. Выбираем слой «demo координатор PM».

2. С помощью кнопки-стрелки перемещаем его на первое место в списке.

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

Такая же процедура может быть выполнена для любых других слоёв. В интерфейсе также отображается информация о типах правил (фильтрации и трансляции), содержащихся в каждом слое.

Рис.28 Приоритезация шаблона слоя правил фильтрации трафика в интерфейсе Policy Management Module.

Работа с журналом событий и настройка политик

Чтобы отследить, как был выполнен импорт данных, откройте Журнал событий в главной консоли ViPNet Prime. Для удобства фильтрации выберите модуль, где происходило событие.

Рис.29 Фильтрация по модулю в журнале событий в интерфейсе ViPNet Prime.

В журнале запрос на импорт отображается как составное событие. Внутри него фиксируются все ключевые операции:

• создание правил фильтрации трафика;

• настройка правил трансляции адресов (NAT);

• формирование групп объектов;

• создание политики безопасности и её слоёв.

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

Рис.30 Дополнительная информация о событиях в Журнале событий в интерфейсе ViPNet Prime.

Создание новой политики и перенос слоев правил

Основная политика, полученная после импорта, выступает донором — из неё мы будем выбирать нужные слои и правила для целевой политики.

Пошагово:

• создадим новую политику (например, «Policy»);

Рис.31 Создание новой политики в ViPNet Policy Manager.

• выбираем слои, соответствующие шаблону «demo coordinator PM»;

• добавляем слой «demo coordinator PM» в новую политику через функцию «Добавить в другую политику»;

Рис.32 Добавление слоя фильтрации трафика в новую политику Policy.

• переносим в «Policy» все правила фильтрации трафика и трансляции NAT адресов из выбранного слоя.

Рис.33 Добавление слоя правил трансляции адресов NAT в новую политику Policy.

Переходим в политику «Policy»:

• необходимо убедиться, что правила фильтрации трафика перенесены корректно;

• а также проверить наличие правил трансляции адресов.

Рис.34 Проверка переноса правил в новую политику Policy.

После подтверждения корректности переноса можно переходить к назначению политики на целевые устройства.

Назначение политики на целевые устройства

Целевые устройства не добавляются в политику безопасности автоматически — администратор должен выполнить это действие вручную.

Рис.35 Добавление целевых устройств в политику безопасности ViPNet Policy Management.

В нашем случае выбираем устройство «demo coordinator PM», однако при необходимости можно назначить политику одновременно на несколько устройств.

Рис.36 Список целевых устройств.

После выбора целевого устройства статус результирующей политики изменяется на «Изменена», что подтверждает внесение изменений в конфигурацию и сигнализирует о готовности к следующим этапам работы.

Рис.37 Изменение статуса политики Policy.

В процессе проверки состояния устройства было выявлено отсутствие лицензии на «demo coordinator PM». Лицензия назначается вручную: соответствующая лицензия выбирается в разделе управления лицензиями и привязывается к целевому устройству.

Рис.38 Назначение лицензии для устройства Coordinator PM.

Сохраняем выбранную лицензию. Видим, что она действует до 2 октября 2026 года.

Рис.39 Лицензия для устройства Coordinator PM назначена.

На завершающем этапе выполняется проверка состава результирующей политики безопасности. Администратор убеждается, что в политику корректно включены:

• правила фильтрации трафика — они определяют, какой трафик разрешён или запрещён в рамках заданной политики;

• правила трансляции адресов (NAT) — обеспечивают корректную маршрутизацию и преобразование сетевых адресов в соответствии с настройками безопасности.

Таким образом, после выполнения всех необходимых действий политика безопасности полностью настроена: она связана с целевым устройством, обеспечена соответствующей лицензией, содержит все требуемые правила и готова к развёртыванию в инфраструктуре ViPNet Prime. Это гарантирует соблюдение заданных параметров защиты и корректную работу сетевых сервисов на целевом устройстве в рамках установленных лицензионных ограничений.

Рис.40 Результирующая политика устройства Coordinator PM.

Аналогично так же можем поступить для правил фильтрации трафика.

Отправка политики безопасности и проверка её согласованности в ViPNet Prime

После настройки правил фильтрации трафика можно переходить к отправке политики на целевое устройство. Для этого в интерфейсе системы выбирается опция «Отправить изменения на устройства».

Рис.41 Отправка изменений на устройство Coordinator PM.

Поскольку в нашем случае изменения подготовлены исключительно для устройства «Coordinator PM», система автоматически отображает его и соответствующую результирующую политику. При необходимости администратор может предварительно просмотреть политику перед отправкой — это позволяет убедиться в корректности всех параметров и настроек.

При инициировании отправки система выполняет автоматическую инспекцию результирующей политики на согласованность и консистентность. В ходе проверки анализируются:

• Дублирование правил — выявляются правила с полным совпадением настроек (идентичные правила).

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

Такая проверка критически важна: она предотвращает конфликты в политике безопасности и гарантирует, что итоговая конфигурация будет работать предсказуемо и корректно.

Рис.42 Уведомление о прохождении инспекции политик устройства Coordinator PM.

По завершении инспекции система отправляет результирующую политику на целевое устройство. В нашем сценарии операция прошла успешно — данные перенесены в единую политику безопасности. Статус операции подтверждает успешное завершение сценария.

Созданная политика безопасности предоставляет администратору широкие возможности для дальнейшей работы:

• на её основе можно сформировать отдельные политики для разных устройств — например, если требуется адаптировать настройки под специфику конкретного оборудования;

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

• есть возможность доназначить специфические правила для отдельных устройств в рамках общей политики безопасности — это позволяет учитывать индивидуальные требования без создания полностью новых политик.

Миграция данных в ViPNet Prime NVS

При миграции в Prime NVS осуществляется перенос следующих данных из ViPNet StateWatcher:

• списка защищённых устройств;

• параметров мониторинга (в т. ч. признака мониторинга и периода мониторинга для каждого устройства);

• настроек SNMP‑агента.

Процесс выгрузки данных

Для выполнения миграции необходимо открыть ViPNet StateWatcher и перейти на вкладку администрирования, где отображаются узлы, ранее перенесённые под управление ViPNet Prime VPN. Среди них представлены различные типы устройств:

• клиенты;

• координаторы (включая Coordinator PM);

• XFirewall и другие компоненты сети.

Рис.43 Узлы мониторинга в интерфейсе ViPNet StateWatcher.

Далее с помощью штатных средств системы выполняется экспорт необходимых данных:

1. Перейдите в раздел настроек ViPNet StateWatcher.

Рис.44 Экспорт данных в интерфейсе ViPNet StateWatcher.

1. Запустите процедуру выгрузки конфигурации.

2. Система автоматически сформирует файл с настройками в формате XML.

Рис.45 Файл с настройками ViPNet StateWatcher.

Перенос устройств в Vipnet Network Visibility System

После получения XML‑файла с данными из Vipnet StateWatcher переходим к переносу устройств на мониторинг в Vipnet Prime NVS. Прежде чем приступить к миграции, необходимо выполнить проверку лицензий для модуля Network Visibility System (NVS).

Убедимся, что имеются необходимые лицензии:

• лицензия на управление модулем NVS — обеспечивает доступ ко всем функциям модуля;

Рис.46 Проверка лицензии Network Visibility System.

• лицензия Monitoring Nodes — определяет количество управляемых устройств в модуле.

Рис.47 Проверка лицензии Monitoring Nodes.

В ходе проверки выясняется, что одна лицензия уже использована. Разберём причину: она распределена на одно из устройств, уже добавленных в модуль NVS.

Дополнительно проверим корректность настроек в модуле ViPNet VPN:

1. Перейдите в раздел Сервисные функции и убедитесь, что активирована функция Сервера мониторинга.

2. Проверьте наличие узла StateWatcher — он должен отображаться в списке.

Рис.49 Проверка наличия узла StateWatcher.

1. Просмотрите перечень заведённых узлов в модуле ViPNet VPN:

• клиенты;

• координаторы (включая Coordinator PM);

• другие узлы сети.

Результаты проверки подтверждают, что структура сети не изменилась после предыдущего переноса данных в ViPNET Prime.

Открываем модуль NVS и попадаем на инфопанель. Здесь видно, что уже создано одно устройство — именно на него распределена ранее упомянутая лицензия. Статус устройства по параметру «Состояние здоровья» указывает на корректную работу компонента.

Рис.48 Инфопанель Network Visibility System.

Для дополнительной проверки перейдите в перечень устройств модуля ViPNet NVS — там вы также увидите это устройство.

Теперь переходим непосредственно к импорту устройств в Network Visibility System.

Почему было развёрнуто одно устройство? Ранее мы говорили о необходимости предварительно настроить и установить сборщик данных — речь шла именно об этом устройстве. Оно уже заведено в модуле NVS, сборщик данных настроен.

Сборщик данных необходим для получения данных мониторинга с устройств, передающих информацию по SNMP‑протоколу. Для вашей миграции предварительное создание сборщика может быть необязательно: его можно создать уже после импорта всех необходимых данных.

Однако, поскольку мы демонстрируем полноценный сценарий с получением данных, сборщик был развёрнут заранее.

Мы уже ознакомились с устройствами на инфопанели. Теперь видим устройство сборщика данных, которое было предварительно создано и донастроено в системе. Переходим к импорту устройств.

Рис.49 Устройство сборщика данных в интерфейсе Network Visibility System.

С помощью данного сборщика мы будем получать данные мониторинга Coordinator, XFirewall.

Импорт устройств в Network Visibility System

Рис.50 Запуск процедуры импорта устройств в интерфейсе Network Visibility System.

Переходим в раздел импорта устройств. Здесь также доступна справка — краткое описание правил миграции данных:

• с какой версии ViPNet StateWatcher возможна миграция;

• какие настройки переносятся, а какие — нет.

Более расширенную версию справки можно найти в руководстве администратора.

Переходим непосредственно к импорту: выбираем подготовленный ранее файл и открываем его.

Поскольку устройство сборщика уже добавлено в систему, появилась дополнительная вкладка. Если бы устройства отсутствовали, вкладка не отобразилась бы.

Рис.51 Устройства доступные для добавления Network Visibility System.

В системе присутствует устройство Core Coordinator Admin — это и есть заранее заведённый сборщик данных. Для добавления доступны все остальные устройства.

Администратор может выбрать часть устройств для добавления при импорте. В нашем случае мы выбираем все устройства, чтобы импортировать полные данные.

Выполняем импорт:

1. Выбираем опцию «Импортировать».

2. Получаем информационное окно с подтверждением: импорт произведён успешно.

Рис.52 Уведомление об успешном импорте устройств в интерфейсе Network Visibility System.

Переходим в список устройств и убеждаемся в результатах:

• ранее в списке присутствовало только одно устройство;

• после импорта добавлены все устройства, содержавшиеся в файле.

Рис.53 Список импортированных устройств.

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

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

Рис.54 Уведомление о невозможности сбора данных с устройства.

Для решения проблемы используем предварительно развёрнутый сборщик данных. Необходимо принудительно отправить ключи из модуля ViPNet VPN — это обеспечит ассоциацию устройств со сборщиком.

Выполняем следующие действия:

1. Переходим в модуль ViPNet VPN и выбираем несколько устройств, требующих ассоциации.

2. Вручную отправляем на них ключи.

Рис.55 Отправка справочников и ключей устройств в модуле ViPNet VPN.

Таким образом обеспечивается возможность сбора данных мониторинга с ранее неассоциированных устройств.

После отправки ключей устройствам требуется некоторое время для их принятия и обработки в справочнике — после этого произойдёт ассоциация со сборщиком данных.

Пока идёт обработка, рассмотрим возможности мониторинга состояния здоровья системы. После установки, настройки и регистрации ViPNet Network Visibility System (NVS) становится доступна возможность мониторить состояние здоровья внутренних модулей — Prime и VPN. Также есть возможность отслеживать состояние сервисов самого NVS, состояние TLS‑сертификатов и объёма свободного места в хранилище данных.

Рис.56 Мониторинг состояния системы ViPNet Network Visibility System (NVS).

Дополнительно рекомендуем настраивать задачи по свертке и удалению данных мониторинга.

Это необходимо для предотвращения переполнения хранилища.

Рис.57 Настройки задач по свертке и удалению данных мониторинга ViPNet Network Visibility System (NVS).

Вернёмся к перечню устройств — ассоциация со сборщиком уже произошла. Заметим, что предупреждения об отсутствии ассоциации исчезли. Теперь мы можем получать данные с устройств, установленных на мониторинг.

Рис.58 Отсутствие предупреждений об ассоциации в интерфейсе ViPNet Network Visibility System (NVS).

Проверка поступления данных в ViPNet Network Visibility System

Для проверки поступления данных мы выбрали Coordinator PM и запросили информацию с него. Аналогичным образом поступили с Coordinator Admin.

Рис.59 Запрос данных об устройстве Coordinator PM.

Теперь доступна возможность просмотреть более подробные данные:

• состояние здоровья устройства;

• состояние сетевых интерфейсов и служб;

• метрики;

• данные инвентаризации для выбранного устройства.

Таким образом, все данные успешно поступают в ViPNet Network Visibility System.

Рис.60 Полученные данные об устройстве Coordinator PM.

Убедимся, что данные также поступают для Core Coordinator Admin. Для этого координатора также доступны: состояние здоровья устройства, события, метрики, данные инвентаризации. Есть возможность ознакомиться с графиком — для этого нужно вернуться в раздел метрик.

Рис.61 Метрики устройства Core Coordinator Admin.

При переходе в метрики открывается дополнительное окно с графиком. На текущий момент объём данных невелик, но уже можно отслеживать изменения метрик.

Рис.62 График изменения метрик устройства Core Coordinator Admin.

Итоги

Все устройства поставлены на мониторинг в ViPNet Network Visibility System:

• данные поступают в систему;

• устройства ассоциированы со сборщиком данных.

На основании вышеизложенного считаем, что импорт данных произошёл успешно.