Содержание
Введение1. Зачем готовить сеть к переходу на ViPNet Prime?
2. Этапы подготовки сети к миграции
3. Чем отличается файл лицензии Prime?
4. Чем похожа новая лицензия Prime?
5. Утилита верификации топологии сети
6. Чек-лист подготовки сети к переходу на ViPNet Prime
7. Процесс миграции на ViPNet Prime
7.1 Проверяем версию ViPNet Administrator8. Итоговое состояние сети
7.2 Утилита верификации
7.3 Проверка мастер-ключей
Введение
В предыдущей статье мы рассмотрели процесс установки ViPNet Prime и необходимые для этого условия. В данной статье мы сосредоточимся на миграции сети в Prime.Под словом «миграция» подразумевается процесс переноса уже существующей, развёрнутой и функционирующей сети, которая управляется ПО ViPNet Administrator, в новое поколение управляющего программного обеспечения — Prime.
Важно учитывать, что ПО ViPNet Administrator, хотя и продолжает поддерживаться, более не развивается. Кроме того, рано или поздно истечёт срок действия сертификата на это программное обеспечение. В связи с этим пользователям, у которых развёрнуты ViPNet‑сети и реализовано централизованное управление сетью через управляющее ПО, в перспективе придётся решать вопрос о переносе этих сетей в Prime.
В процессе такой миграции осуществляется замена управляющего ПО — с Administrator на Prime. Ключевое различие между решениями заключается в операционной системе: Prime функционирует под управлением Linux, тогда как Administrator работает в среде Windows. Соответственно, в ходе миграции на сервере, где развёрнуто управляющее ПО, происходит смена операционной системы. Помимо этого, заменяется и узел центра управления сетью, на котором установлено управляющее ПО.
Что важно, после такой миграции конечные устройства продолжают использовать старый протокол безопасности IPLir4 и шифровать трафик на алгоритмах ГОСТ 28147-89. Только после миграции сети в Prime можно будет переводить продукты на пятое поколение и на использование новых криптоалгоритмов Магма и Кузнечик. Сейчас переносим сеть из администратора в Prime.
1. Зачем готовить сеть к переходу на ViPNet Prime?
При планировании перехода с ViPNet Administrator на ViPNet Prime важно заранее подготовить сеть к миграции. Это необходимо по ряду существенных причин, связанных с принципиальными различиями между двумя решениями.Несмотря на то что Administrator и Prime обладают значительным общим функционалом, это два разных продукта, построенных на различных технологических принципах:
- ViPNet Administrator представляет собой десктопное приложение, работающее в среде Windows;
- ViPNet Prime — это веб‑приложение, функционирующее под управлением операционной системы Linux.
В Prime реализованы новые технологические подходы и пересмотрена логика работы с объектами сети. Такие изменения направлены на упрощение управления инфраструктурой, но требуют предварительной адаптации существующей конфигурации.
Кроме того, Prime ориентирован на работу с продуктами пятого поколения, что накладывает дополнительные требования к структуре и настройкам сети. Также в нём учтены актуальные требования регуляторов, зафиксированные при получении сертификата соответствия.
Процесс миграции в значительной степени автоматизирован и носит неинтерактивный характер — в момент переноса сети администрирование ViPNet Prime не требуется. Однако именно поэтому так важно заблаговременно привести инфраструктуру в соответствие с требованиями Prime. Предварительная подготовка позволяет:
- избежать сбоев в процессе переноса данных;
- обеспечить бесперебойную работу сети после миграции;
- минимизировать риски потери настроек и связей между элементами инфраструктуры.
Таким образом, грамотная предварительная подготовка сети — это ключевое условие успешного и бесшовного перехода на новое управляющее ПО.
2. Этапы подготовки сети к миграции
Можно выделить три больших этапа подготовки сети к миграции.1. Установка ViPNet Prime и получение подходящего файла лицензии. Независимый этап, может быть выполнен параллельно с другими этапами.
2. Подготовить объекты и топологию сети. Важно проверить те объекты сети, которые существуют, их функции, топологию, на предмет возможности перенесения в Prime, в соответствии с требованиями. В этом помогает утилита верификации и топологии сети.
3. Подготовка сети перед миграцией. Когда мы уже готовы запускать непосредственно саму процедуру миграции, нужно будет отправить актуальную информацию на узлы. Это будет самый последний финальный этап перед тем, как запустить миграцию.
3. Чем отличается файл лицензии Prime?
При переходе с ViPNet Administrator на ViPNet Prime важно учитывать, что лицензия, используемая в Administrator, не подойдёт для работы в Prime. Это обусловлено как форматом файла, так и принципиальными различиями в структуре лицензирования.Формат
Начнем с того, что администратор работал с несколькими форматами файлов лицензии. Это *itcslic и infotecs.reg. Prime работает только с лицензией формата *itcslic.
Лицензия на управляющее ПО и его модули
Но дело не только в формате, дело в составе лицензии. Сам Prime, как продукт, является лицензируемым. Помимо этого, он является модульным, и каждый модуль Prime тоже лицензируется отдельно.
При осуществлении миграции, нам необходимо будет, чтобы в составе Prime был как минимум один обязательный модуль, это модуль VPN, своего рода аналог ЦУС и УКЦ. В дальнейшем именно из этого модуля будем управлять типологией, будем настраивать узлы, будем управлять ключами. В новом файле лицензии обязательно есть лицензия на сам Prime и на модуль VPN.
Кроме того, меняется сама платформа узла центра управления сетью: вместо Windows используется Linux. Соответственно, на нем устанавливается клиентское ПО, и в файле лицензии теперь обязательно наличие как минимум одной свободной лицензии на Client for Linux. Кроме того, следует учитывать, что Prime не поддерживает ряд лицензий, действующих в предыдущей версии системы. Такие лицензии попросту не будут перенесены в новый файл — они исключаются из состава лицензионного пакета по техническим и архитектурным причинам.
4. Чем похожа новая лицензия Prime?
1. Номер сети.Тот гарант, почему мы можем мигрировать сеть и не переразворачивать дистрибутивы ключей на конечных устройствах.
2. Состав лицензий для узлов и их функций, управление которыми может осуществляться из Prime. Подробно в документации ViPNet Prime написано про то, какие лицензии не поддерживаются в Prime, что с ними делать.
5. Утилита верификации топологии сети
При переходе на ViPNet Prime критически важно убедиться, что текущая топология сети и настройки объектов соответствуют требованиям новой платформы. Поскольку корпоративные сети нередко имеют сложную и разветвлённую структуру, ручная проверка всех элементов может занять значительное время и повысить риск упустить важные детали.Для упрощения этой задачи разработана утилита верификации топологии сети. Она автоматизирует процесс анализа и позволяет:
- проверить все объекты сети;
- проанализировать их настройки и взаимосвязи;
- оценить возможность переноса в Prime с учётом отличий от ViPNet Administrator.
Утилита верификации топологии сети предназначена для запуска на машине с УКЦ и разработана специально для операционной системы Windows. Она распространяется в виде готового дистрибутива, что упрощает её установку и настройку. В комплект поставки, помимо собственно программы, входят два важных компонента: файл с настройками подключения к базе данных Administrator и подробное руководство для администратора. Благодаря файлу настроек утилита получает доступ к необходимым данным и может полноценно анализировать топологию сети.
Принцип работы утилиты основан на комплексном подходе к проверке готовности сети к миграции в Prime. Инструмент включает в себя 47 различных видов проверок, которые охватывают все возможные варианты построения топологии ViPNet‑сети — от простейших конфигураций до самых сложных и разветвлённых структур. Используя этот набор проверок, утилита тщательно анализирует текущее состояние сети, выявляет потенциальные проблемы и определяет, насколько инфраструктура готова к переносу в новую среду и формирует детальный отчет с результатами каждой проверки. Такой всесторонний подход гарантирует, что ни один критически важный аспект не останется без внимания при подготовке к миграции.
6. Чек-лист подготовки сети к переходу на ViPNet Prime
Что же нужно сделать в итоге, чтобы подготовить свою сеть? Процесс довольно простой и понятный. Если следовать рекомендациям, если изучить документацию, если использовать утилиту верификации, делать то, что она рекомендует, процесс довольно несложный, но он требует определенных усилий и временных затрат. Если сеть довольно объемная, мы рекомендуем вообще начинать подготовку сети к миграции заблаговременно, до срока, до того дня, когда запланирована миграция в новое управляющее приложение, просто потому что это может занять много времени.- Во-первых, проверим, что Administrator той версии, с которой можно мигрировать, а именно версии 4.6.11.
- Посмотрим, что формируют утилиты верификации. Нам нужен отчет без конфликтов, в идеале, без предупреждений.
- Следующим шагом рекомендуется сменить мастер-ключи, если им остается действовать менее чем полгода. Почему так? В Prime после миграции можно сменить мастер-ключи. Там процедура практически аналогичная той, которая есть в Administrator. Но процедура смены мастер-ключей подразумевает проведение регламентных работ, и это не самая типовая, не самая часто совершаемая операция в сети. Именно поэтому рекомендуем в знакомом интерфейсе, в знакомом управляющем приложении заранее это сделать, чтобы затем иметь какой-то буфер на привыкание к новому управляющему ПО.
- Статус межсетевого мастер-ключа. Посмотрим межсетевые взаимодействия, если у нас есть доверенные сети и проверим, что мастер-ключи для них созданы, введены в действие, и имеют статус «Текущий». Это очень важно.
- Устанавливаем Prime, в который будем мигрировать заблаговременно. Это Prime версия 1.9.11.
- Загружаем в него подходящую лицензию, заранее полученную в ИнфоТеКС.
- На машине, на которой будет осуществляться развертывание ViPNet Prime, устанавливаем клиентское ПО Client for Linux.
- Проверяем, что на управляемых продуктах нашей сети установлены те версии программного обеспечения, которые совместимы с новым Prime. В противном случае мы можем потерять управляемость узлом из центра. Это нужно будет сделать также обязательно.
- Перед запуском процесса миграции актуальную межсетевую информацию отправляем в доверенные сети, принимаем, обрабатываем обязательно ответную, чтобы все связи, все узлы, вся топология, соответственно, была перенесена корректно.
- Отправляем справочники и ключи на узлы своей сети.
- Если используете деловую почту, важно на период проведения регламентных работ расшифровать письма, которые не должны быть потеряны.
- Отключаем автоматические операции, вообще избегаем автоматических операций на период проведения миграции, чтобы какие-либо настройки, сделанные умышленно или случайно, не привнесли тех конфликтов и предупреждений в реальную сеть, которых мы так старались избежать перед миграцией.
- И последнее, необходимо проверить, что ваша сеть работоспособна до процедуры миграции в Prime. Это важно.
7. Процесс миграции на ViPNet Prime
Для наглядной демонстрации процесса миграции мы подготовили типовую тестовую среду. В её основе — демонстрационная сеть, управляемая посредством ViPNet Administrator версии 4.6.11, которая официально поддерживает переход на Prime.Инфраструктурная платформа решения включает:
- операционную систему Windows 10 Pro;
- среду виртуализации VMware Workstation.
Рис.1 ПО ViPNet Administrator
На рисунке 1 основные параметры демонстрационной сети, с которой мы будем работать. Мы видим номер сети: именно его мы вводили при установке Prime в прошлой статье.
Структура сети включает несколько ключевых компонентов:
- координаторы;
- конечные клиентские узлы (их количество ограничено — это сделано намеренно для наглядности демонстрации);
- пользователи (часть из них была создана заранее).
Кроме того, в сети настроены межсетевые взаимодействия с доверенными сетями. Все эти элементы позволят нам наглядно посмотреть работу утилит верификации.
Сейчас наша задача — последовательно пройти по чек‑листу и подготовить инфраструктуру к миграции.
7.1 Проверяем версию ViPNet Administrator
Прежде всего необходимо удостовериться, что версия ViPNet Administrator, под управлением которого работает наша сеть, соответствует требованиям для миграции. Для этого открываем свойства ЦУС и проверяем установленную версию ПО.Как видим, в нашем случае используется версия 4.6.11 — именно та, о которой шла речь в начале. Это означает, что дополнительное обновление управляющего приложения не требуется: мы можем приступить к миграции непосредственно из текущего состояния системы.
Рис.2 О программе ViPNet Administrator
Таким образом,текущее состояние управляющего приложения полностью соответствует требованиям процесса миграции. Дополнительное обновление ПО не требуется — это позволяет нам приступить к переносу данных непосредственно из имеющейся конфигурации, без обновления системы.
7.2 Утилита верификации
Рис.3 Исполняемый файл утилиты верификации и файл с настройками
Приступая к работе с утилитой верификации, мы видим два ключевых компонента: исполняемый файл самой утилиты и отдельный файл с настройками подключения к базе данных.
В стандартной конфигурации, если вы используете SQL‑сервер из поставки Administrator под учётной записью пользователя по умолчанию, никаких дополнительных действий с файлом настроек выполнять не требуется — он уже содержит все необходимые параметры и готов к работе.
Однако в нашем случае применяется иной сценарий: мы задействовали SQL‑сервер, не входящий в комплект поставки Administrator. Для работы с ним был создан специальный пользователь, обладающий необходимыми правами доступа к базе данных, где хранится вся релевантная информация о сети. Это означает, что нам предстоит вручную внести в файл настроек ряд ключевых параметров:
- адрес базы данных (BD);
- имя базы данных;
- логин и пароль пользователя, под учётной записью которого утилита верификации будет взаимодействовать с базой данных — считывать информацию об объектах сети и их настройках.
После того как все необходимые данные будут указаны, важно не забыть сохранить изменения в файле настроек.
Более подробные инструкции по заполнению файла вы найдёте в руководстве администратора — там представлены все необходимые пояснения и примеры корректного ввода параметров.
Рис.4 Заполненный файл с настройками БД
Запуск утилиты
Теперь приступим к запуску утилиты верификации — с её помощью мы проанализируем состояние нашей демонстрационной сети и оценим её готовность к миграции.
После запуска программы перед нами открывается консольный интерфейс. Именно в консоли отображается итоговый агрегированный результат — обобщённый вывод о том, соответствует ли текущая конфигурация сети требованиям для переноса в ViPNet Prime.
И вот какой вердикт выдаёт утилита: «Данные сети не готовы к миграции в ViPNet Prime из‑за конфликтов».
Обратите внимание: указанные конфликты мы создали намеренно — это сделано специально для того, чтобы на практике отработать алгоритм их выявления и устранения.
Важно отметить, что утилита не просто сообщает о наличии проблем — она формирует развёрнутый отчёт по всем проведённым проверкам. В этом отчёте вы найдёте детализированную информацию о каждом этапе анализа, включая результаты всех проверок, которые охватывают полный спектр параметров сети.
Рис.5 Результат проверки данных сети утилитой верификации ViPNet Prime
Анализ отчета
Все параметры настроек и перечень проверок, выполняемых утилитой верификации, детально описаны в руководстве администратора. При запуске инструмента эти же данные отображаются в сформированном отчёте — вы получаете полную картину по каждому проведённому тесту.
На текущем этапе наша задача — не просто ознакомиться с результатами проверки, а освоить принцип работы с выводом утилиты. Важно научиться анализировать полученные данные, выявлять проблемные зоны и выстраивать последовательность действий по их устранению.
Для наглядности мы разберём этот процесс на конкретных примерах — детально рассмотрим типичные конфликты и предупреждения, которые может выдать утилита.
Рис.6 Файл отчета утилиты верификации ViPNet Prime
На рисунке 6 представлен отчёт утилиты верификации. В его названии содержится ключевая информация:
номер сети, с которой мы работаем (тот же, что ранее демонстрировался в интерфейсе Administrator);
статус проверки — «Выявленный конфликт» (он полностью соответствует агрегированному статусу, отображённому в консоли);
дата и время создания отчёта.
Последние два параметра (дата и время) продублированы и в имени самого файла. Это продуманное решение: поскольку утилита верификации зачастую запускается многократно, такая маркировка позволяет легко различать версии отчётов и отслеживать динамику изменений.
Сам отчёт формируется в формате CSV. Это означает, что данные представлены в виде структурированной таблицы.
Рис.7 Список проверяемых данных и выявленных конфликтов в отчете утилиты верификации ViPNet Prime
В отчёте утилиты верификации представлен ряд проверок. Их количество достаточно велико. Часть проверок завершилась успешно, однако во втором столбце отчётливо видны выявленные конфликты и предупреждения.
Приступим к их последовательному разбору. Начнём с изучения каждой проверки. Описание проверки сформулировано в виде требования — оно чётко указывает, что именно анализирует утилита. Например, утилита проверяет, имеют ли узлы базовой роли значения, соответствующие типу узла в ViPNet Prime (или, иными словами, должны ли узлы иметь базовые роли, соответствующие типу узла в Prime).
В случае несоответствия фиксируется конфликт — в нашем примере система указывает,что не все узлы соответствуют.
В следующей строке отчёта, утилита верификации конкретизирует результат: указывается, какой именно узел содержит ошибку.
Рис.8 Выявленный конфликт узла
Как поступить в сложившейся ситуации? Утилита верификации предоставляет чёткую рекомендацию: необходимо назначить на узел базовую роль, которая определит его как клиент, координатор или координатор без функции VPN‑сервера.
Приступим к выполнению этой рекомендации в интерфейсе ЦУСа. Находим требуемый узел — «Мобильный Сергеев», который в нашей сети выполняет функции клиентского узла.
Рис.9 Необходимый клиентский узел в ПО ViPNet Administrator
После обнаружения узла проверяем его настройки: видим, что базовые роли на него пока не назначены.
Рис.10 Роли узла в интерфейсе ViPNet Administrator
Добавляем необходимую роль, однозначно определяющую узел как клиент. После выполнения этой операции конфликт считается устранённым — данный узел больше не будет препятствовать запуску миграции.
Рис.11 Добавление роли узла
Однако следует учитывать: несмотря на решение данного конкретного конфликта, в системе могут присутствовать иные проблемные моменты. Чтобы продолжить работу по подготовке к миграции, необходимо вновь обратиться к отчёту утилиты и проанализировать оставшиеся выявленные конфликты.
Следом рассмотрим два взаимосвязанных конфликта, выявленных утилитой верификации.
Первый конфликт указывает на нарушение требования: на каждом узле должно быть не более одного пользователя. Второй конфликт фиксирует обратное нарушение — наличие узлов без назначенных пользователей. Иными словами, нормативное требование сводится к следующему: каждый узел должен иметь ровно одного пользователя.
Рис.12 Конфликты узлов
Анализ отчёта показывает отклонения от этого правила:
В первой проверке выявлено, что узел «ПК Журавлёв» имеет более одного пользователя, хотя должен содержать только одного.
Во второй проверке указаны два узла, на которых пользователи отсутствуют вовсе: «Coordinator AdminDemo1» (строка 20) и «ПК Кузнецов» (строка 21).
Приступим к устранению всех выявленных несоответствий — будем работать одновременно с перечисленными узлами и их пользовательскими учётными записями.
Рис.13 Исправление конфликта узла «ПК Журавлев» в ЦУС ViPNet Administrator
Открываем свойства узла «ПК Журавлёв» и обнаруживаем, что на нём зарегистрированы два пользователя. Согласно отчёту утилиты верификации, необходимо удалить одного из них — оставить только одного пользователя на узле.
Рис.14 Удаление второго пользователя клиентского узла
Выполняем требуемое действие: удаляем второго пользователя, сохраняя лишь одного. Это обязательное условие — без его соблюдения миграция ViPNet Prime невозможна. Поэтому подобные рекомендации утилиты следует выполнять в обязательном порядке.
Рис.15 Выбор следующего узла
Переходим к узлу «Coordinator AdminDemo1». Проверяем наличие пользователей — выясняется, что ни одного пользователя на узле не назначено. Однако по требованиям должен присутствовать как минимум один.
Рекомендация утилиты: необходимо назначить на данный узел одного уникального пользователя. При этом важно, чтобы этот пользователь не был привязан к другим узлам сети.
Рис.16 Назначение пользователя узла «Coordinator AdminDemo1»
Также был выявлен ещё один клиентский узел, на котором отсутствуют пользователи. Согласно рекомендациям утилиты верификации, необходимо добавить пользователя на этот узел.
Рис.17 Добавление пользователя клиенту «ПК Кузнецов»
Хотя можно было создать нового пользователя, для экономии времени мы воспользовались заранее подготовленными учётными записями — они уже были созданы.
Таким образом, мы завершили работу по назначению пользователей на узлы в строгом соответствии с рекомендациями утилиты верификации.
В процессе проверки выявлены конфликты, связанные с настройками ключей ДСДР.
Рис.18 Конфликты, связанные с настройками ключей ДСДР
Рассмотрим первую проверку. Согласно требованиям, в УКЦ в настройках ключей ДСДР должны быть активированы:
- функция использования ключей ДСДР;
- функция контроля срока действия ключей.
Утилита верификации зафиксировала несоответствие: указанные функции в УКЦ не включены. В отчёте приведена рекомендация: либо активировать необходимые функции, либо удалить координаторы типа KB.
Это обусловлено тем, что существование координаторов типа KB возможно только при корректно заданных настройках ключевых блокнотов.
Перейдём ко второй проверке, которая также касается ключей ДСДР. Требование гласит: в УКЦ для всех координаторов типа KB в настройках ключей ДСДР обязательно должны быть указаны номера комплектов ключей на диске ДСДР.
Утилита выявила конкретное нарушение: для узла Coordinator AdminDemo3 (тип KB5000) номер комплекта ключей на диске ДСДР не задан.
Необходимо устранить данное несоответствие — без этого миграция ViPNet сети будет невозможна.
Рис.19 Удостоверяющий ключевой центр
Открываем Удостоверяющий и ключевой центр (УКЦ) — в данном случае не ЦУС, а именно УКЦ. Переходим в раздел настроек ключевых блокнотов ДСДР.
В интерфейсе видим, что необходимо установить отметку (галочку), рекомендованную утилитой верификации. Требуется:
включить использование ключей ДСДР;
задать соответствующие параметры.
Рис.20 Настройка ключей ДСДР
Выполняем настройку: указываем текущую серию ключей и задаём следующую серию. Также активируем функцию контроля сроков действия ключей. Хотя задание следующей серии ключей не является строго обязательным, мы выполняем эту операцию в рамках текущей процедуры.
Рис.21 Ввод серий ключей ДСДР
Далее обращаем внимание на узел Coordinator AdminDemo3: в его настройках отсутствует номер комплекта ключей. Однако для корректной работы в новом управляющем ПО Prime этот параметр обязательно должен быть задан.
Рис.22 Ввод номера комплекта ключей для координатора
Присваиваем узлу номер комплекта — в нашем случае выбираем значение «1».
Рис.23 Присвоение узлу номера комплекта ключей
После внесения всех необходимых изменений сохраняем настройки в УКЦ. Все заданные параметры фиксируются в системе.
В дальнейшем эти настройки должны быть переданы на узлы сети — это позволит устранить выявленные конфликты и обеспечить корректную работу системы в реальной сетевой инфраструктуре.
Перейдём к повторному запуску утилиты верификации. Предыдущий отчёт мы уже обработали — теперь проверим, как изменились результаты проверки.
Рис.24 Запуск утилиты ViPNet Prime для повторной проверки
После выполнения повторного запуска обращаем внимание на вторую строку отчёта: «Проверка данных завершена, обнаружены предупреждения».
Отметим важное изменение по сравнению с предыдущей проверкой: если ранее система фиксировала конфликты, то теперь выявлены только предупреждения.
Однако следует учитывать: наличие предупреждений означает, что после миграции сеть будет функционировать с определёнными ограничениями. Именно предупреждения являются причиной такого режима работы системы.
Открываем новый отчёт утилиты верификации. В отличие от предыдущей проверки, в текущем отчёте конфликты отсутствуют.
Теперь сосредоточимся на анализе предупреждений и их потенциальных последствий в случае, если мы не примем меры по их устранению.
Первое предупреждение указывает на следующее требование: в сети необходимо создать межсерверные каналы между координатором центра управления и остальными координаторами, обладающими функцией VPN‑сервера.
При анализе данных отчёта выявляем конкретное несоответствие: у узла ‑ «Coordinator admin‑demo2» отсутствует требуемый межсерверный канал.
Рис.25 Предупреждение в отчете с результатами проверки
Для работы нового транспорта в Prime критически важна веб‑связь центрального координатора с каждым координатором сети.
При создании новых координаторов в Prime такая связь добавляется автоматически. Однако при миграции существующей сети может оказаться, что межсерверный канал между центральным координатором и каким‑либо узлом отсутствует (например, связь осуществляется через цепочку других координаторов).
Если не создать прямой межсерверный канал до миграции:
будет невозможно включить автоматические операции;
нельзя автоматически отправлять справочники и ключи на недоступный напрямую узел;
придётся вручную передавать справочники и ключи, двигаясь от удалённого координатора к центру;
в противном случае потребуется перевыдавать дистрибутив ключей и доставлять его на проблемный координатор.
Поэтому важно устранить это предупреждение до миграции, чтобы избежать трудоёмких ручных операций в дальнейшем.
Утилита верификации уже указала, у какого координатора отсутствует межсерверный канал.
Рис.26 Выбираем центральный координатор
Но мы перейдём в центральный (Core) координатор, проверим список межсерверных каналов и добавим недостающие соединения со всеми координаторами, с которыми такие каналы не установлены.
Рис.27 Выбираем координаторы для добавления
В нашем случае утилита верификации выявила лишь один координатор без межсерверного канала. Добавляем этот межсерверный канал.
После этого отправим на узел справочники и ключи с учётом новых связей.
Предупреждение устранено.
В вашей сети может быть больше предупреждений — это нормально.
Далее все предупреждения связаны с доверенными сетями.
Рис.28 Предупреждение в отчете с результатами проверки
Первое предупреждение указывает на наличие межсетевых взаимодействий с сетями под управлением неподдерживаемого ПО.
Неподдерживаемое ПО в нашем случае — это:
- ViPNet Administrator версии ниже 4.6.9;
- ViPNet Prime версии ниже 1.6.
Такое межсетевое взаимодействие Prime невозможно. При миграции это взаимодействие будет утрачено.
Рассмотрим, какое именно межсетевое взаимодействие выявлено в нашей сети
Рис.29 Информация о доверенной сети
В руководстве администратора для каждого предупреждения указаны последствия и способы их предотвращения. Для данного случая есть три варианта действий:
Принять потерю межсетевого взаимодействия при миграции (если доверенная сеть несущественна). Утилита миграции автоматически не перенесёт его в Prime — никаких дополнительных действий не требуется.
Связаться с администратором доверенной сети и запросить обновление управляющего ПО до поддерживаемой версии (не обязательно до Prime — подойдёт актуальная версия администратора). Этот вариант выбирают, если важно сохранить связь.
Самостоятельно прекратить межсетевое взаимодействие.
В нашем случае доверенная сеть функционирует под управлением Prime версии ниже 1.6 (экспериментальная сеть). Поскольку потеря взаимодействия с ней не критична, мы осознанно прекращаем его вручную — вместо того чтобы допустить автоматическую потерю при миграции.
Рис.30 Прекращение взаимодействия с сетью
Как мы могли увидеть на рисунке 28, утилита верификации выявила ещё одно предупреждение: для одного из межсетевых взаимодействий не получена или не обработана ответная межсетевая информация.
Для сохранения всех связей между объектами сети после миграции в Prime такая информация должна быть корректно получена и обработана.
Возможные действия:
- смириться с потерей взаимодействия (если сеть не важна);
- разобраться с межсетевой информацией.
В нашем случае входящая межсетевая информация есть — она готова к обработке, но ранее не была обработана. Выполняем обработку.
Рис.31 Информация о доверенной сети
Рис.32 Подтверждение обработки межсетевой информации
После обработки у нас имеется корректная входящая межсетевая информация от доверенной сети. Это позволит сохранить межсетевое взаимодействие при миграции в Prime.
Мы завершили обработку всех предупреждений. Для итоговой проверки повторно запускаем утилиту верификации.
В результате видим сообщение во второй строке: «Проверка данных завершена. Данные сети готовы к миграции в ViPNet Prime».
Рис.33 Проверка данных утилитой верификации Prime
Утилита подтверждает отсутствие конфликтов и предупреждений. Это означает, что сеть может быть мигрирована в Prime в текущем настроенном состоянии — без потери функциональности.
7.3 Проверка мастер-ключей
Проверим актуальность мастер‑ключей. В УКЦ видно, что они созданы в конце сентября текущего года (недавно были обновлены), поэтому миграция в новое управляющее ПО возможна — времени до следующей смены ключей достаточно.
Рис.34 Раздел УКЦ с мастер-ключами
Далее проверяем статус межсетевого мастер‑ключа: он текущий, значит межсетевое взаимодействие сохранится в текущем виде (иначе потребовался бы обмен сетью с новым ключом).
Рис.35 Проверка статуса мастер-ключа
Также сверяем расположение файлов с актуальными мастер‑ключами — они должны находиться по пути, указанному в документации ViPNet Prime. Дополнительно проверяем, что дата изменения файла с мастер‑ключами совпадает с датой, отображённой в УКЦ.
Рис.36 Расположение мастер-ключей
Эта проверка — типовая обязанность администратора, прописанная в документации. Мы выполнили и подтвердили её корректность.
8. Итоговое состояние сети
Вернёмся к чек‑листу, чтобы убедиться в полноте подготовки к миграции:- Версия ViPNet Administrator проверена — 4.6.11.
- Утилита верификации сформировала отчёт без конфликтов — миграция программного обеспечения возможна.
- Срок действия мастер‑ключей — более полугода, смена не требуется.
- Статус межсетевого мастер‑ключа для МСВ — текущий, взаимодействие сохранится.
- В прошлой статье мы разобрали установку ViPNet Prime, загрузили лицензию.
- На машине с Prime будет установлен клиент for Linux.
- Проверим версии ПО на управляемых продуктах: при несовместимости — обновим.
- отправим актуальную межсетевую информацию, СКИ и ключи на узлы;
- проанализируем письма деловой почты;
- отключим автоматические операции;
- приступим к миграции.