Не является большим секретом, что формальные сроки действия сертификации ФСБ на ViPNet Administrator и координаторы 4-го поколения (ViPNet Coordinator HW 4) до 29 октября уже истекли. Тем не менее, для многих предприятий миграция на ViPNet Prime остается задачей «со звёздочкой», которую часто откладывают до последнего, ведь координаторы пятого поколения могут управляться только с новой платформы.

Есть два сценария для тех, у кого уже есть своя сеть ViPNet:

1. Развернуть сеть заново на новой лицензии Prime и постепенно переносить туда клиентов.

2. Мигрировать сеть целиком с сохранением лицензии, номера сети и всех межсетевых связей.

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

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

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

Делайте снапшоты. Если работаете на «физической» машине — делайте полные копии диска. 

Основные этапы для снапшотов/копий:

1. После загрузки и распаковки установочного комплекта.

2. Перед запуском непосредственно установки через deployment‑configurator.

3. Ключевой снапшот: после того как вы успешно зашли в Web‑интерфейс (да, теперь управление идет через браузер, а сам Prime крутится на Linux, в том числе на Astra Linux), загрузили свою лицензию и подключили модуль VPN (но не инициализировали его!). В случае любых неожиданностей в процессе возвращаться будем именно к этому состоянию.

Пара важных советов на этапе подготовки:

Когда размечаете диск для установки ОС, закладывайте большой корневой раздел. Логи и временные файлы миграции могут занять неожиданно много места.

В качестве машины для управления выбирайте либо ту, на которой у вас есть возможность править /etc/hosts, либо используйте локальный DNS‑сервер. На нём нужно будет сделать несколько записей, привязывающих доменные имена, на которых функционирует Prime (например: 192.168.1.10 prime.local vpn.prime.local api.prime.local).

Обновите все межсетевые мастер‑ключи (ММК). Это будет критически важно как в процессе миграции, так и после неё.

Раскопайте всю историю межсетевых взаимодействий (особенно удаленных сетей. Дважды особенно — старых сетей с историей). Если встречаются ММК с датами «неизвестно» — миграция не пройдет, хотя формальные проверки в старом ЦУС могут проходить нормально.

Аналогичная проблема возникнет, если встречаются «осиротевшие» ММК: когда межсетевое взаимодействие было удалено в Центре управления сетью (ЦУС), при этом в Удостоверяюще‑ключевом центре (УКЦ) ключи не удалялись, но после удаления в ЦУС соответствующая запись пропала.

Если между получением дистрибутива и моментом миграции прошло некоторое время и были обновления лицензии, загрузите их в старый ЦУС и проверьте, чтобы все лицензии сошлись. В идеале должно оставаться хотя бы по 1–2 свободных места. Если в ЦУС загрузка лицензии проходит всегда (просто количество свободных уходит в минус, и можно перераспределить), то в Prime лицензия просто не загрузится и даже не покажет, что именно не так.

Запросите сразу у «Инфотекса» утилиту резервного копирования и восстановления. Она не входит в стандартный установочный комплект и запрашивается отдельно через техподдержку.

? Заложенное на всё время миграции умножайте на π. Это не шутка.

Как вообще у нас шла миграция: хроника боли

Мы получили установочный комплект Prime, загрузили содержимое дисков на сервер, и понеслась. 

Для установки Prime подойдет не всякий комп/сервер/виртуальная машина. Должно быть не больше 16 ядер, иначе не запустится модуль VPN. Согласно документации, 16 ядер — это лимит для сети в 10 тысяч клиентов. Вроде бы в новых версиях это ограничение уже сняли, но если ставите на Astra Linux, обязательно сверяйтесь со списком поддерживаемых конфигураций в документации к вашей конкретной версии Prime. Если сервер мощнее, на этапе установки может потребоваться ограничение через taskset или cgroups.

Далее по шагам:

1. Сгенерировали сертификат для TLS‑соединения. Здесь ничего сложного, но нужно не забыть сделать SAN с wildcard для поддоменов.

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

3. Проверили сеть с помощью утилиты миграции. Почистили от артефактов, которые однозначно препятствуют миграции (утилита об этом сообщает в отчете). 

4. На всякий случай сделали еще одну копию администратора (потом она перенесет множество страданий). 

5. Сделали выгрузку для миграции, загрузили на Prime, запустили процесс по инструкции... 

И на этапе загрузки данных для ключевого центра процесс прошел 360 попыток запуска модуля VPN, потратил 30 минут времени и упал в ошибку. Каких‑либо подробностей, позволяющих понять причину или хотя бы куда дальше копать, в логах не было. Просто таймаут:

text

[ERROR] VPN module startup attempt 360/360

[ERROR] Timeout waiting for VPN module initialization. Migration aborted.

Возвращаемся к снапшоту. (Надеюсь, все помнят, что его нужно сделать ДО запуска миграции?)

Здесь начинается череда экспериментов (естественно, на копии):

Удалить подозрительные межсети (по которым были предупреждения) → снова загрузить → снова таймаут. Возврат к снапшоту.

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

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

Очистить всю сеть, оставив так же админа, координатор и всё. Не грузится. Возврат к снапшоту. Тупик.

Решение: охота на «осиротевшие» ключи

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

А еще для одного из ключей формат записи отличался от остальных. В УКЦ он отображался со сроками выпуска и действия «неизвестно», и, судя по всему, именно он ломал логику утилиты миграции на стороне Prime.

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

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

1. В УКЦ удалить все неиспользуемые ММК для этой сети.

2. Снять отметку «Действующий» с оставшегося ММК и удалить его.

3. Только после этого разорвать межсетевое взаимодействие в ЦУС.

4. Сформировать и разослать справочники и ключи.

После тотальной чистки от «осиротевших» и всех неактуальных ММК мы в очередной раз запустили миграцию и, о чудо!, она отработала! В Prime загрузилась сеть со всей структурой.

Финал и рассылка ключей

На очередном шаге после непосредственно миграции нужно выпустить дистрибутив ключей для установки на машине с Prime (аналогично тому, как это делалось в Администраторе 4-й версии). 

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

После продления или коррекции сроков производится пробная рассылка обновлений справочников и ключей, отслеживание состояния. Убедившись, что всё нормально, можно переключаться в «боевой» режим. 

В рабочем режиме по умолчанию рассылка справочников осуществляется через 6 минут после последнего действия, затрагивающего справочники и ключи, и идёт сразу по всем узлам, для которых накопились изменения. После того как справочники и ключи отправлены, нужно ждать около 7–8 минут, чтобы получить ответы о доставке и приемке.

В принципе, после этого переход завершен. 

По времени мы планировали, что управимся за месяц. 

Спойлер: нет. Три месяца. 

Так что про умножение времени на π — это суровая реальность, а не просто красивая фраза.