Миграция сети в ViPNet Prime

Содержание

1. Этапы миграции сети
2. Что мигрирует в ViPNet Prime?
3. Что в Prime не мигрирует?
4. Утилита миграции ViPNet Prime
5. Итоговое состояние сети
6. Миграция сети
1. Состав сети
2. Подготовка к миграции
3. Выгрузка данных из ЦУС и УКЦ
4. Текущее состояние ViPNet Prime
5. Перенос данных
6. Миграция данных в ViPNet Prime
7. Донастройка сети в ViPNet Prime
• Отключение VPN
• Создание дистрибутива ключей для нового ЦУС
• Перенос файлов на другую машину
• Координаторы
• Другие узлы
• Ресурсы
• Профили DNS
• Группы пользователей
• Группы узлов
• Автоматические группы узлов
• Сервисные функции
• Обновление ПО
• Журнал транспортных конвертов
• Мастер-ключи
• Ключи ДСДР
• Доверенные сети
• Настройка модуля
7. Заключение

Введение

Мы уже рассмотрели установку ViPNet Prime и подготовку развёрнутой сети к миграции. Сегодня приступаем к самому процессу переноса — миграции.
Под миграцией понимается перенос действующей сети, которая работает под управлением ViPNet Administrator, в новое управляющее ПО — ViPNet Prime. Необходимость такого перехода обусловлена двумя ключевыми факторами: во‑первых, ViPNet Administrator более не развивается как продукт, а во‑вторых, рано или поздно истечёт срок действия сертификата на Administrator. Для заказчиков, у которых развёрнуты ViPNet‑сети, это означает, что для сохранения централизованного управления узлами сети потребуется выполнить переход на ViPNet Prime.

При этом важно понимать, что миграция предполагает исключительно смену управляющего приложения — с Administrator на Prime. На данном этапе устройства в сети продолжают функционировать в прежнем режиме: используют протокол безопасности IPLir4 и шифруют трафик по ГОСТ 28147‑89. Переход на пятое поколение и использование новых криптоалгоритмов «Магма» и «Кузнечик» станет возможным только после того, как сеть будет успешно перенесена в Prime. Сейчас наша главная задача — выполнить этот перенос.
К текущему моменту мы уже установили и развернули ViPNet Prime, а также подготовили демонстрационную сеть к миграции. 

Сегодня разберём:

1. Какие объекты мигрируют в Prime, а какие — нет.
2. Как работает утилита миграции и как она переносит объекты сети.
3. Пошаговую процедуру миграции демонстрационной сети в Prime.
4. Где в Prime искать смигрированные объекты и как ими управлять.
5. Действия сразу после миграции, необходимые для сохранения работоспособности сети.

1.Этапы миграции сети

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

• подготовка сети ViPNet Administrator с помощью утилиты верификации (она проверяет, возможна ли миграция в Prime);
• установка ViPNet Prime и загрузка в него подходящего файла лицензии.

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

• выгрузку данных из ViPNet Administrator;
• импорт данных в ViPNet Prime;
• финальную настройку сети.

2.Что мигрирует в ViPNet Prime?

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

В ViPNet Prime мигрируют:

• узлы и пользователи со всеми настройками и связями;
• группы узлов и группы пользователей, созданные в ViPNet Administrator;
• данные о DNS‑серверах и DNS‑зонах;
• туннелируемые ресурсы;
• межсетевые взаимодействия (при выполнении необходимых подготовительных действий);
• данные УКЦ.

При этом часть объектов не переносится в Prime. Это обусловлено тем, что, несмотря на схожесть функционала, ViPNet Prime и ViPNet Administrator — разные продукты, имеющие определённые различия.

3.Что в Prime не мигрирует?

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

• Иерархические сети (в том виде, как они реализованы в Administrator). При этом возможность управления иерархическими структурами в Prime сохраняется.
• Данные журналов (аудит, события, транспортные конверты). Для сохранения этих данных требуется предварительный экспорт.
• Учётные данные администраторов:
• пароли администраторов групп узлов;
• учётная запись администратора ЦУС (в Prime необходимо создать новые учётные записи).
• Шаблоны и файлы:
• шаблоны сетевых узлов;
• файлы обновлений ПО (в Prime их можно загрузить заново и централизованно распределить).
• Полномочия пользователей:
• индивидуальные полномочия для каждого клиента;
• полномочия на клиентах с лицензией деловой почты.
  При этом система управления полномочиями в Prime остаётся доступной — её настройка выполняется после миграции.
• Определённые статусы межсетевых связей («запрещена своей сетью» и «запрещена доверенной сетью»). Это связано с архитектурными различиями в реализации межсетевого взаимодействия между Administrator и Prime, хотя функционально система работает аналогично.

4.Утилита миграции ViPNet Prime

• Сначала запускаем утилиту на машине с ViPNet Administrator: она автоматически экспортирует данные из ЦУС и УКЦ.
• Далее запускаем на машине с ViPNet Prime: утилита проводит необходимые проверки и импортирует данные, полученные на первом этапе.

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

5.Итоговое состояние сети

1. Текущая сеть функционирует под управлением ViPNet Administrator версии 4.6.1, что позволяет выполнить миграцию без предварительного обновления управляющего ПО.
2. Утилита верификации сформировала отчёт без конфликтов и предупреждений, подтверждая готовность сети к миграции.
3. Проверены:
• срок действия мастер‑ключей (позволяет избежать их замены сразу после миграции);
• статус межсетевых мастер‑ключей для сохранения необходимых взаимодействий.
4. ViPNet Prime (версия 1.9.11) уже установлен и лицензирован. 
5. Дополнительно:
• на машине с Prime развёрнуто клиентское ПО;
• обновлено ПО на управляемых продуктах до версий, совместимых с Prime.
6. Учтено изменение платформы:
• Administrator работает на Windows;
• Prime функционирует на Linux (узел создан, но не инициализирован).

1. Обменяться с доверенной сетью актуальной межсетевой информацией.
2. Отправить финальные справочники и ключи на узлы сети — это необходимо, поскольку в процессе подготовки были внесены изменения, которые должны быть применены на всех узлах.
3. Расшифровать письма Деловой почты.
4. Проверить отключение автоматических операций — это предотвратит внесение новых конфликтов или предупреждений в уже подготовленную сеть.

6.Миграция сети

Приступим к миграции сети.
Перед нами — демонстрационная сеть, развёрнутая специально для показа процедуры миграции. Обратите внимание: номер сети уже знаком нам по предыдущей статье. При развёртывании ViPNet Prime мы также вносили этот номер сети в настройки.

6.1 Состав сети

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

Для демонстрации процесса миграции сети в Prime мы сформировали несколько групп — в частности, группы пользователей и группу узлов. Также в сети настроена группа DNS‑серверов и DNS‑зон. Разумеется, присутствует и межсетевое взаимодействие.
Как мы помним из предыдущей статьи, сеть уже подготовлена к миграции. На текущий момент в ней сохраняется одно межсетевое взаимодействие, которое мы планируем перенести в ходе сегодняшней процедуры.

Важно отметить, что межсетевое взаимодействие ViPNet Prime не ограничивается общей настройкой — есть конкретная связь между пользователями разных сетей. В нашей сети это пользователь «Сергеев», который связан с «Полиной Михайловной» из доверенной сети. Эта межсетевая связь активно функционирует.

Чтобы лучше отследить результаты миграции, вы можете заранее выбрать любого пользователя (например, по фамилии), которого затем найдём в Prime после завершения переноса. Таким образом, мы актуализировали представление о структуре нашей сети перед началом миграции.

6.2 Подготовка к миграции

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

Отметим: если у вас несколько межсетевых взаимодействий (в отличие от нашей демонстрационной сети), отправлять информацию перед миграцией во все сети необязательно. Это нужно делать лишь в том случае, если вы не уверены, что у вас и у доверенной сети уже есть актуальные данные. Если вы не вносили изменений, о которых должна знать доверенная сеть, можно считать этот этап завершённым.

Теперь отправим справочники и ключи в нашу сеть — на координаторы и клиентские узлы. У нас развёрнуты реальные координаторы: отправим данные на оба. 

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

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

Перейдём в УКЦ и убедимся, что автоматическая рассылка справочников и ключей прекращена. Для этого откроем УКЦ и проверим наличие кнопки «Перейти в автоматический режим» — её присутствие подтверждает, что УКЦ больше не рассылает данные автоматически.

Мы отправили межсетевую информацию и ожидаем получения актуальных данных от доверенной сети. Узлу Центра управления сетью уже направлены справочники и ключи — он обязательно их примет. Осталось дождаться и обработать ответную межсетевую информацию.
Напомним: в  прошлой статье мы подробно обсуждали миграцию межсетевых взаимодействий. В отчёте верификации мы видели необработанную межсетевую информацию, а утилита предупреждала о возможных проблемах при миграции — в частности, о риске потери топологии. Сейчас ситуация аналогична: мы получили ответную межсетевую информацию, она готова к обработке, и мы её обработаем. Даже если бы мы забыли это сделать, утилита верификации напомнила бы нам об этом.

Итак, мы:

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

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

6.3 Выгрузка данных из ЦУС и УКЦ

Приступаем к миграции сети. Первый шаг — выгрузка данных из ЦУС и УКЦ.
Для этого используем утилиту миграции. Она автоматически сохранит необходимые данные из ЦУС и УКЦ, которые затем будут перенесены в ViPNet Prime.

Рассмотрим содержимое утилиты. В ней имеется директория с названием «backup», внутри которой расположен специальный скрипт. Именно этот скрипт предназначен для автоматического сбора всех данных из ЦУС и УКЦ — впоследствии они будут импортированы в Prime.

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

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

В директории backup, рядом со скриптом, появились две новые папки. Первая — «КЦ» — содержит данные УКЦ, вторая — «МС» — включает данные ЦУСа.
На этом утилита миграции завершила сбор необходимых данных. Теперь у нас есть полный комплект информации, требуемый для последующего импорта в ViPNet Prime. Весь процесс выполняется одной командой — и в результате мы получаем все нужные данные в готовом виде.

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

Однако на этом процесс не завершается — нам по‑прежнему требуются данные ЦУСа для корректной топологии. Поэтому запускаем второй скрипт. Его задача — получить данные ЦУСа, необходимые для их последующего переноса в ViPNet Prime. Скрипт также отрабатывает успешно, и мы видим, что нужная директория создана.

Проверим получившиеся директории — они соответствуют ожидаемым. На данном этапе мы завершили сбор всех необходимых для миграции данных: у нас есть и данные УКЦ, и данные ЦУСа. Теперь мы полностью готовы к их переносу в ViPNet Prime.

6.4 Текущее состояние ViPNet Prime

Проверим текущее состояние ViPNet Prime. Система запущена, и мы выполняем аутентификацию с использованием учётной записи по умолчанию. Напоминаем: данные этой учётной записи необходимо будет изменить в дальнейшем.

Мы видим, что Prime функционирует в полном объёме — запущено ядро системы, а также модуль ViPNet VPN, который успешно зарегистрирован.
Перейдём к проверке лицензии. Как уже упоминалось, лицензия была предварительно получена и загружена в систему. В интерфейсе видно, что лицензия на модуль VPN активна, при этом номер сети полностью совпадает с тем, который мы наблюдали в ЦУСе. Именно эту сеть мы планируем перенести в Prime.

Таким образом, система готова к работе: Prime запущен, лицензия активна, модуль VPN функционирует.
Обратим внимание на элемент интерфейса — в верхней панели отображается организация Core Network. Поясним: в Prime предусмотрена возможность разделения сети на изолированные сегменты, которые называются организациями. При установке системы автоматически создаётся сегмент с именем Core Network (это имя задано по умолчанию). Именно в этот сегмент будет перенесена наша сеть из ViPNet Administrator.

Модуль ViPNet  VPN предлагает создать узлы Центра управления, однако, опираясь на руководство, мы знаем, что этого делать не следует. Все необходимые узлы будут перенесены из Administrator в Prime в процессе миграции.

Итак, Prime полностью готов к миграции, а все необходимые данные для переноса уже подготовлены. Осталось разместить их в нужных директориях, чтобы процесс миграции прошёл корректно и в автоматическом режиме.

6.5 Перенос данных 

Напомню, что ViPNet Administrator работает на платформе Windows, а ViPNet Prime — на платформе Linux. Это две отдельные системы, развёрнутые на разных серверах (в нашем случае — на виртуальных машинах).

Для продолжения миграции необходимо перенести сохранённые данные — две созданные директории — с сервера Administrator на сервер Prime. Поскольку мы работаем с виртуальными машинами, для передачи файлов удобно использовать программу WinSCP. Она не входит в состав Administrator или Prime, но позволяет легко перемещать данные между виртуальными машинами.

Таким образом, собранные утилитой миграции данные ЦУСа и УКЦ мы переводим на сервер с установленным Prime. Теперь все необходимые файлы находятся на нужном сервере.

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

Перед нами — ранее собранные сведения из ЦУСа и УКЦ. Мы переходим в директорию, где расположена утилита миграции, и видим папки, названия которых практически совпадают с именами наших данных. Логика размещения очевидна: информацию из ЦУСа и УКЦ следует перенести в одноимённые директории.
Выполняем перемещение данных ЦУСа (часть МС), а затем аналогичным образом размещаем сведения из УКЦ. В результате все файлы оказываются в нужных директориях.

Таким образом, мы завершили подготовительный этап работы с данными: сначала получили их в ViPNet Administrator, затем перенесли на сервер с Prime и корректно разместили в требуемых директориях. Это означает, что теперь мы готовы приступить к их импорту в ViPNet Prime.

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

Приступаем к миграции данных в ViPNet Prime. Первым делом необходимо перевести систему в режим миграции. Для этого запускается специальный скрипт (up.sh) — он автоматически установит дополнительные компоненты, требуемые для процедуры. Процесс занимает непродолжительное время.

Важно отметить ключевые рекомендации:

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

В ходе миграции система запрашивает:
Мастер-Пин — его значение задавалось при развёртывании Prime (необходимо помнить и вводить при каждом запуске системы);
пароль администратора УКЦ — его также нужно ввести и подтвердить повторным вводом.

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

Что именно выполняет утилита миграции:

• Проводит серию проверок — аналогично утилите верификации и топологии сети. При обнаружении конфликта процесс останавливается, чтобы избежать некорректной работы сети после частичной миграции. В документации описаны шаги по повторной подготовке Prime и возобновлению миграции.
• Убеждается в выполнении всех необходимых условий для корректного переноса данных:
• Prime запущен (работают ядро и модуль VPN);
• присутствует лицензия;
• в лицензионном файле содержатся разрешения на все переносимые продукты и функции.

Отсутствие любого из этих компонентов приведёт к остановке миграции, поскольку система не сможет определить, какие узлы допустимо перенести.
По завершении работы утилиты миграции Prime необходимо вывести из режима миграции, запустив скрипт down.sh

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

Для небольшой сети (около 300 узлов: три координатора, по 100 клиентов за каждым) процесс выглядит так:

• сохранение данных из УКЦ и ЦУСа занимает около 2 минут;
• импорт в Prime — от 5 до 15 минут.

Для объёмной сети (порядка 30 000 узлов, включая 300 координаторов, за каждым из которых также по 100 клиентов, при топологии «каждый с каждым») временные затраты существенно выше:

• сохранение данных может занять около 30 минут;
• импорт в Prime — до 12 часов.

После перезагрузки машины потребуется снова ввести Мастер-Пин от Prime. 
Таким образом, мы завершили миграцию сети из Administrator в Prime.

Теперь давайте изучим перенесённую сеть через интерфейс нового управляющего приложения. Для удобства ориентации переключимся на машину с ViPNet Administrator, так как это десктопное приложение, размещённое на отдельном сервере.
Открываем браузер непосредственно на этой машине и переходим в ViPNet Prime, куда только что была перенесена наша сеть. При входе в систему Prime модуль VPN запрашивает создание мастер‑ключей.

Что представляют собой эти мастер‑ключи? Это криптографические ключи, которые понадобятся в дальнейшем при развёртывании в сети продуктов пятого поколения, поддерживаемых Prime. В ViPNet Administrator такие ключи отсутствовали — по сути, они восполняют недостающий элемент инфраструктуры.

Создадим мастер‑ключи в соответствии с параметрами, предлагаемыми системой: используем предустановленные алгоритмы и заданные сроки действия ключей.
Теперь мы можем увидеть нашу сеть в новом интерфейсе — она успешно перенесена, и мы готовы вновь с ней ознакомиться.

Напомним: ранее мы предлагали запомнить фамилию какого‑либо пользователя из исходной сети. Хотя общее количество пользователей было невелико, среди них присутствовало определённое разнообразие. Надеемся, вы сохранили в памяти имя интересующего вас пользователя — теперь вы можете убедиться, что он успешно перенесён в Prime.

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

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

Для наглядности рассмотрим любого пользователя в интерфейсе Prime и убедимся, что его функциональные возможности и настройки остались неизменными — такими же, какими они были до миграции.
Рассмотрим состояние пользователей после миграции. На примере пользователя Журавлёва видно, что назначенное ему ПО ViPNet Connect сохранилось. Это означает: пользователь может продолжать работу в чате без каких‑либо изменений — переход на новое управляющее ПО никак не повлиял на его взаимодействие с приложением ViPNet Connect.

Обратим внимание на пользователя Сергеева — он имеет особую роль, поскольку связан с пользователем доверенной сети. Напомним: ранее мы тщательно готовили межсетевое взаимодействие к миграции. Проверка показывает: Сергеев по‑прежнему доступен в доверенной сети.

Убедимся в сохранении связей. Действительно, связь пользователя с Полиной Михайловной из доверенной сети полностью сохранена. Это подтверждает общий принцип: при условии корректного переноса межсетевого взаимодействия в Prime все связи между объектами доверенной сети остаются рабочими.

Таким образом, мы убедились, что пользовательские данные успешно перенесены в новую систему. 
Переходим к проверке клиентских узлов.

В Prime доступен полный список клиентских узлов — все они были корректно перенесены. При этом сохранены:

• координаторы, за которыми зарегистрированы клиенты;
• назначенные пользователям учётные записи;
• исходные типы узлов.

6.7 Донастройка сети в ViPNet Prime

Приступим к первому важному шагу после завершения миграции — донастройке сети.
Перейдём к узлу Центра управления. В интерфейсе Prime обращает на себя внимание жёлтый баннер с предупреждением: «Создайте дистрибутив ключей». Это сигнализирует о том, что для данного узла дистрибутив пока не сформирован. Такая ситуация закономерна: как уже отмечалось ранее, происходит смена платформы узла Центра управления сетью — с Windows на Linux.

Отключение VPN

Для корректной работы необходимо выполнить инициализацию узла и предоставить ему соответствующий дистрибутив ключей. Прежде чем приступить к этому, требуется выполнить обязательное действие: перейти к старому узлу Центра управления (на машине с ViPNet Administrator) и отключить на нём VPN.

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

Создание дистрибутива ключей для нового ЦУС

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

Согласно правилам работы с Prime, для печати пароля следует использовать принтер с PIN‑конвертами. Распечатанный пароль передаётся конечному пользователю — он потребуется для инициализации узла: пользователь введёт этот пароль непосредственно на конечном узле.

После формирования дистрибутив сохраняется. Обратите внимание: поскольку мы работаем через браузер на машине с ViPNet Administrator, дистрибутив сохраняется именно там. Формат файла остаётся прежним — DST, знакомый по работе с Administrator.

Перенос файлов на другую машину

Далее необходимо перенести файлы на другую виртуальную машину. В реальной рабочей ситуации для этого обычно используют флеш‑накопитель: на него копируют дистрибутив ключей, после чего переносят к управляемому узлу для развёртывания дистрибутива на нём.
В нашем случае процедура несколько упрощена: мы переместили файл с дистрибутивом ключей между виртуальными машинами и теперь переходим к серверу с установленным ViPNet Prime. На этом сервере уже предварительно развёрнуто клиентское ПО.

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

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

Давайте проверим информацию о нашем ViPNet Client. Для этого выполним соответствующую команду в терминале и проанализируем полученные данные.
В выводе команды мы видим номер сети — это подтверждает, что узел успешно интегрирован в нашу сетевую инфраструктуру. Речь идёт о том самом сервере, на котором развёрнут ViPNet Prime вместе с клиентским ПО для Linux.

Инициализация узла завершена успешно, поэтому теперь вернёмся в интерфейс Prime. Следующий шаг — отправка на узел справочников и ключей.

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

Координаторы

Продолжим изучение интерфейса и проверим оставшиеся элементы конфигурации. Обратим внимание на координаторы: как можно убедиться, они успешно перенесены из ViPNet Administrator.
Отметим, что в текущем представлении может отсутствовать xFirewall — этот вопрос мы рассмотрим отдельно чуть позже. На экране отображаются все координаторы, выполняющие функцию VPN‑сервера.

Для наглядности проанализируем перенос настроек на примере центрального координатора. Сначала обратимся к интерфейсу Administrator и откроем свойства нужного узла. Центральный координатор располагается в списке предпоследним.

В первую очередь проверим назначенную ему роль. Как видно из настроек, это устройство типа VA2000 — в нашей конфигурации оно уже развёрнуто.

Далее изучим сетевые параметры координатора. Мы можем убедиться, что узел доступен напрямую из внешней сети, а также определить его IP‑адрес, по которому осуществляется подключение.

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

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

Давайте найдём необходимые данные в интерфейсе Prime. Перед нами — наш центральный координатор.
При проверке видно, что его тип остался прежним: это по‑прежнему VA2000. 

Перейдём к параметрам подключения — координатор, как и раньше, доступен напрямую, его IP‑адрес не изменился.

Теперь обратимся к связям координатора. Мы демонстрируем эти шаги, чтобы вам было проще ориентироваться в новом пользовательском интерфейсе. Открыв раздел связей, мы видим те же явно добавленные соединения — в том числе мобильные устройства и персональные компьютеры.

Помимо явных связей, в Prime присутствуют и технические связи — сейчас мы их также рассмотрим.
Давайте изучим технические связи координатора, рассмотрев в качестве примера взаимодействие с одним из клиентов. Выберем, к примеру, StateWatcher.

Возникает вопрос: по какой причине у координатора появилась связь с этим клиентом? Анализ показывает, что данная связь была создана системой Prime автоматически. Это обусловлено тем, что указанный клиент зарегистрирован за нашим центральным координатором — он является его клиентом.
Для более полного понимания механизма формирования связей рассмотрим ещё один пример — взаимодействие между координаторами. Мы видим, что центральный координатор связан с другим координатором. Такая технологическая связь является обязательной для каждого координатора в сети с координатором Центра управления.

Как и в предыдущем случае, эта технологическая связь также была автоматически создана системой Prime.
Мы завершили осмотр координаторов. Теперь необходимо отправить на Координатор Центра Управления справочники и ключи — выполним эту процедуру.

Другие узлы

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

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

• межсетевые экраны;
• узлы квантовой сети.

Ресурсы

Обратим внимание на раздел «Ресурсы». При миграции из ViPNet Administrator в Prime были перенесены ресурсы. Заметим, что их имена представлены в различных форматах — сейчас разъясним суть этого явления и происхождение данных объектов.

Рассмотрим первый ресурс. Его наименование уже даёт представление о происхождении. Мы видим, что это DNS‑сервер: отображается его IP‑адрес, принадлежность к нашей сети, а также связь с координатором AdminDemo1.

Ресурс — это IP‑адрес, либо диапазон адресов, которые туннелируются определённым координатором. В нашем случае мы наблюдаем конкретный IP‑адрес, перенесённый в систему и туннелируемый координатором AdminDemo1.

Перейдём к изучению новых с точки зрения интерфейса объектов — ресурсов. При миграции из Administrator в Prime все они были перенесены.
Рассмотрим, где именно искать информацию о ресурсах в Administrator. Процесс не вполне очевиден. Для примера возьмём координатор AdminDemo1. Нам нужно перейти не в раздел туннелирования, а в настройки DNS‑сервера — именно там мы найдём нужный IP‑адрес, на который намекало имя ресурса в Prime.

Что это означает на практике? Когда узел будет обращаться к DNS‑серверу, он направится по указанному IP‑адресу, который туннелируется нашим координатором. Именно поэтому в Prime этот IP‑адрес представлен как ресурс.
Важно зафиксировать: ключевой факт заключается в том, что IP‑адрес (или диапазон адресов), туннелируемый координатором, успешно перенесён в Prime в качестве ресурса.
Если взглянуть на другие ресурсы в Prime, можно заметить, что они представлены в разных форматах. Например, встречаются объекты с названием просто «Ресурс». При изучении их свойств мы видим:

• принадлежность к нашей сети;
• связь с координатором AdminDemo1;
• перечень IP‑адресов;
• диапазоны адресов;
• исключения.

Рис.56 Свойства ресурса координатора AdminDemo1 в интерфейсе ViPNet Prime

Всё это — туннелируемые адреса и диапазоны, управляемые координатором.
Для наглядности вернёмся в интерфейс Administrator. В свойствах туннелирования того же координатора AdminDemo1 мы обнаружим все IP‑адреса и диапазоны, которые были заданы для туннелирования. Именно они были перенесены в Prime как единый ресурс.
Таким образом, все туннелируемые IP‑адреса и диапазоны, относящиеся к одному координатору, объединяются в Prime в один ресурс.

На этом обзор ресурсов завершён.

Профили DNS

В ViPNet Prime появился новый с точки зрения управления объект — «Профили DNS». При этом по своей сути они полностью соответствуют знакомым по ViPNet Administrator объектам.
Рассмотрим первый профиль — DNS Servers Group 1. Его название совпадает с именем группы DNS‑серверов и DNS‑зон, которую мы предварительно создавали в ViPNet Administrator. Перейдём в Administrator (ЦУС) и найдём эту группу: действительно, имена полностью совпадают.

Изучим содержимое группы:

• в качестве DNS‑сервера указан конкретный IP‑адрес — тот самый, который туннелируется координатором AdminDemo1;
• задан ряд DNS‑зон (мы предварительно создали две зоны перед миграцией сети).

• имя DNS‑профиля идентично имени группы DNS‑серверов и зон;
• в качестве сервера выбран ресурс — тот самый IP‑адрес, который мы рассматривали ранее (туннелируемый координатором и указанный в свойствах как DNS‑сервер);
• DNS‑зоны перенесены в полном объёме;
• узел, к которому применён этот DNS‑профиль (AdminDemo3), также мигрирован из администратора.

Теперь рассмотрим второй DNS‑профиль. Его имя имеет иной формат: в нём указаны наша сеть и координатор AdminDemo2. Это сигнализирует о специфике миграции объекта:

• добавлен DNS‑сервер — снова ресурс (IP‑адрес, туннелируемый координатором AdminDemo2);
• ресурс задан в свойстве DNS‑сервера (что подтверждается названием объекта).

Почему этот профиль перенесён отдельно? Дело в том, что он не входил ни в одну группу DNS‑серверов и DNS‑зон. Чтобы администратору после миграции не пришлось вручную создавать DNS‑профиль для назначения ресурса в качестве DNS‑сервера на узел, утилита миграции автоматически сформировала отдельный DNS‑профиль. Теперь его можно применять к различным узлам.

На этом мы завершаем обзор новых с точки зрения управления объектов. Самое сложное позади — далее возвращаемся к интерфейсу, привычному по ViPNet Administrator. Пока пропустим раздел «Доверенные организации» (это принципиально новая для Prime функциональность), к нему мы вернёмся позже.
Перейдём к рассмотрению групп в системе.

Группы пользователей

В ViPNet Prime мы видим группу пользователей узлов. Важно отметить: все группы пользователей успешно перенесены из ViPNet Administrator — их состав и настройки полностью сохранены.

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

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

Группы узлов

Давайте рассмотрим, как в ViPNet Prime представлены группы узлов, перенесённые из ViPNet Administrator.
Если открыть соответствующий раздел в Prime, можно убедиться: в систему успешно импортированы все группы, включающие координаторы с именами AdminDemo 1, AdminDemo 2 и AdminDemo 3, с которыми мы работаем.

Автоматические группы узлов

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

Что даёт работа с автоматическими группами:

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

Рис.65 Просмотр состава автоматической группы узлов в интерфейсе ViPNet Prime

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

Сервисные функции

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

• политики;
• сервис мониторинга.

• Police Manager продолжает функционировать в сети в прежнем режиме;
• задействованные узлы остались теми же и по‑прежнему выполняют свои штатные функции.

Рис.66 Раздел ViPNet Prime «Сервисные функции» 

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

Детальное рассмотрение механизмов настройки полномочий оставим за рамками текущего обзора. Продолжим последовательное изучение интерфейса согласно намеченному плану.

Обновление ПО

В системе предусмотрен раздел «Обновление ПО». При выполнении миграции прошивки не были перенесены  -это обусловлено стремлением не увеличивать время работы утилиты миграции.

Дело в том, что сетевая инфраструктура зачастую отличается значительной объёмностью: может иметь разветвлённую топологию, содержать множество настроек и связей. Кроме того, в системе могут присутствовать объёмные файлы, которые утратили актуальность или были оставлены без внимания администратором.
В связи с этим было принято решение не переносить прошивки, а предоставить возможность загрузить актуальные обновления уже в новой системе. Это даёт дополнительный шанс обеспечить узлы самыми свежими версиями ПО.
При этом функционал работы с обновлениями в Prime полностью соответствует привычному интерфейсу Administrator: можно выбирать узлы‑получатели, настраивать расписание отправки обновлений и управлять процессом их распространения по сети.

Журнал транспортных конвертов

Перейдём к журналу транспортных конвертов. В нём отображается информация о доставке справочников и ключей: согласно данным журнала, они успешно достигли как узла Центра управления сетью, так и Центрального координатора. Конечные узлы приняли и обработали отправленные данные.
Это подтверждает, что узлы корректно получают справочники и ключи от Prime. При этом важно отметить: Центральный координатор не подвергался дополнительным настройкам — он продолжает автоматически получать справочники и ключи от нового управляющего ПО, как и Центр управления сетью, который мы ранее разворачивали.

Мастер-ключи

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

Ключи ДСДР

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

• задать серии ключей;
• настроить контроль срока действия ключей;
• назначить номер комплекта.

Доверенные сети

На рисунке мы видим желтый маркер напротив раздела «Доверенные сети.
Prime уже сообщает нам о том, что нам нужно осуществить какие-то действия с нашей доверенной сетью.
Межсетевое взаимодействие установлено, оно смигрировало из ViPNet Administrator.
Нам необходимо отправить межсетевую информацию в доверенную сеть,
и мы это делаем.