От Access Server к Community OpenVPN: что нужно перестроить
Access Server хранит политику; Community OpenVPN просит написать её самому. Составьте карту идентичности, маршрутов и отзыва, прежде чем копировать хотя бы один сертификат.
Access Server и Community OpenVPN говорят на одном протоколе и почти ни в чём другом не совпадают. Рукопожатие, согласование шифров и плоскость данных туннеля совместимы, поэтому клиент часто подключается к любому из них, не правя профиль. Разница в том, кому принадлежит конфигурация: один продукт поставляет слой управления, который пишет и применяет политику, другой даёт файл конфигурации и набор хуков и ждёт, что решать будете вы.
Это различие и есть план миграции. Всё, что старый продукт решал за вас, должно стать явным решением где-то в новом развёртывании.
Где два развёртывания перестают быть взаимозаменяемыми
В Access Server веб-интерфейс администрирования владеет пользователями, группами, правами на пользователя, выпуском сертификатов и пакетом профиля, который человек скачивает. Демон под ним настраивается этим слоем, поэтому работающий сервис — результат сохранённого состояния, которое вы редко правите вручную. В Community OpenVPN файл конфигурации и есть состояние: он называет слушателя, удостоверяющий центр, хук аутентификации и каждую передаваемую опцию, и ничто не переписывает его за вас. Одна и та же машинерия TLS стоит под двумя очень разными моделями владения.
Короткая карта делает разрыв конкретным. Пользователи и группы существуют только в старой базе, пока вы не создадите их заново. Пакеты профиля становятся файлом конфигурации плюс сертификаты, которые вы распространяете сами. Права на пользователя становятся директивами в client-config-dir. Интерфейс администрирования становится тем процессом, который вы выберете для выпуска сертификатов и правки файлов.
Запишите эту карту, прежде чем трогать сервер. Каждая строка, которую вы не можете заполнить, — это функция, которую вы вот-вот потеряете, а тихая потеря — это путь, которым миграция становится сбоем две недели спустя.
Идентичность не переносится вместе с файлами сертификатов
Сертификаты старого центра могут корректно разбираться в новом сервисе и всё равно быть неверной идентичностью, потому что старый продукт связывал их с состоянием учётной записи, которого новый не видит. Сначала решите, аутентифицирует ли новое развёртывание только сертификатом, плагином, доходящим до PAM или RADIUS, или комбинацией, затем проверьте, что каждый вариант сохраняет нужные свойства. Общий сертификат без идентичности на пользователя — это один credential для всех, у кого он есть. Отзыв тоже должен работать с первого дня, а в Community OpenVPN это файл CRL, на который ссылается crl-verify, плюс процесс, который его пересоздаёт.
Планируйте регистрацию до переключения, а не после. Новые сертификаты, проверенный путь отзыва и документированный способ отключить одного человека — это предпосылки, а не последующая работа. Если многофакторная аутентификация пришла из интеграции старого продукта, назовите замену явно, потому что неустановленный плагин отказывает закрыто в худший момент.
Маршрутизация и разрешение имён следуют за автором конфигурации
Маршруты, настройки DNS и поведение полного туннеля — это передаваемые опции в обоих продуктах, но вычисляет их за вас только один. В Community OpenVPN вы сами пишете директивы push, решаете, принадлежит ли redirect-gateway серверу или клиенту, и подтверждаете, что на хосте есть пересылка и NAT. Завершённое рукопожатие ничего не говорит о пересылке, трансляции адресов или маршрутах, которые клиент действительно получил.
Поведение для отдельного клиента требует client-config-dir и файла, названного по common name сертификата клиента, а паре «площадка — площадка» нужны записи iroute для префиксов за ней. Если имя неверно, опции игнорируются без ошибки. Проверьте на одном нерабочем клиенте в его собственном пуле адресов, затем прочитайте выданный адрес, полученные маршруты и настройки резолвера, с которыми он закончил.
Упорядочьте переключение так, чтобы старый сервис мог вернуться
Запустите новый слушатель на другом порту или адресе и оставьте старый обслуживать трафик, пока вы доказываете замену. Два демона на одном сокете — это не план отката.
Переносите по одной группе, с её сертификатами, её пулом и её маршрутами, и репетируйте обратный путь, а не обнаруживайте его во время инцидента. Откат, который работает только если сначала остановить новый сервис, всё равно откат, но его нужно проверить, когда ничего не горит.
Наконец, перечислите функции без прямого эквивалента и решите судьбу каждой письменно: самостоятельная выгрузка профиля, флаги прав на пользователя, сам интерфейс администрирования, отчёты о подключениях в реальном времени. Заменить их документированным ручным процессом — законный ответ. Оставить строку пустой — нет.
Работа закончена, когда человек, никогда не видевший старого портала, может зарегистрироваться, подключиться, дойти до нужного внутреннего адреса и быть чисто отозван. Всё до этого — подготовка.