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