От 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 плюс файл, именуван по общото име на сертификата на клиента, а партньор сайт към сайт изисква записи iroute за префиксите зад него. Сбъркайте именуването и опциите се игнорират без грешка. Тествайте с един непроизводствен клиент в собствения му адресен пул, после прочетете зададения адрес, получените маршрути и настройките на резолвера, с които е завършил.
Подредете превключването така, че старата услуга да може да се върне
Пуснете новия слушател на друг порт или адрес и задръжте стария да обслужва трафик, докато доказвате замяната. Два демона на един сокет не са план за връщане.
Премествайте по една група, със свои сертификати, свой пул и свои маршрути, и репетирайте пътя за връщане, вместо да го откривате по време на инцидент. Връщане, което работи само ако новата услуга е спряна първо, пак е връщане, но трябва да се тества, докато нищо не гори.
Накрая избройте функциите без пряк еквивалент и решете съдбата на всяка писмено: самостоятелно изтегляне на профил, флагове за разрешения за всеки потребител, самият административен интерфейс, отчети за живи връзки. Замяната им с документиран ръчен процес е законен отговор. Оставянето на реда празен не е.
Работата е свършена, когато потребител, който никога не е виждал стария портал, може да се запише, да се свърже, да достигне желания вътрешен адрес и да бъде чисто отнет. Всичко преди тази точка е подготовка.