OpenVPN Access Server супраць Community: што насамрэч пераносіцца

Профілі пераносяцца; спісы карыстальнікаў застаюцца. Каманда, якая пераходзіць паміж Access Server і Community Edition, сутыкаецца з гэтай прагалінай праз гадзіну пасля пераходу, калі яе першы кліент праходзіць аўтэнтыфікацыю і не мае ні груповай палітыкі, ні маршруту для карыстальніка, ні самастойнага скіду пароля. Абодва прадукты гавораць на адным пратаколе і прымаюць аднаго кліента, і менавіта таму прагаліна застаецца нябачнай падчас планавання. Насамрэч вы выбіраеце ўзровень кіравання і людзей, якія ім валодаюць.

Разглядайце рашэнне як пытанне інвентарызацыі, а не як табліцу функцый. Спытайце, хто стварае карыстальнікаў, хто адклікае сертыфікаты і хто адказвае на выклік у 02:00.

Чаму файл .ovpn не пераносіць налады

Профіль .ovpn апісвае стасункі аднаго кліента з адным серверам: аддалены хост, пратакол, CA, сертыфікат і ключ кліента, а таксама любы ўбудаваны матэрыял tls-crypt. Кіньце гэты файл у новую зборку — і кліент усё роўна завершыць рукапацісканне, таму міграцыя выглядае скончанай. Нішто ў ім не пералічвае карыстальнікаў, іх групы, іх статычныя маршруты ці палітыку, якая вырашала, каму наогул дазволена падключацца. Гэтыя запісы жывуць ва ўласным сховішчы сервера, і абодва прадукты захоўваюць іх у розных формах.

У Community Edition эквіваленты — гэта файлы, якія вы трымаеце: запісы client-config-dir з опцыямі для кожнага кліента, такімі як ifconfig-push і iroute, CRL для адкліканняў і ключ tls-crypt. Access Server трымае тыя ж паняцці ў сваёй базе даных і прадстаўляе іх праз вэб-кансоль і інструмент каманднага радка sacli. Паняцці супадаюць адно да аднаго; артэфакты ж зусім не пераносяцца.

Профілі таксама ўтойваюць паводзіны, якія ніхто не заўважае, пакуль яны не зменяцца. Кліент з redirect-gateway def1 накіроўвае ўсё агляданне праз сервер; перанясіце яго ў зборку без гэтага радка — і скарга будзе пра тое, што інтэрнэт зламаўся. Няўзгодненасць CA або няправільная налада remote-cert-tls правальваецца гучна, і гэта добры вынік. Адсутны ключ tls-crypt правальваецца як ціхі тайм-аўт, а гэта не так.

Што валодае ўзровень кіравання

Падлічыце ўсё, што не з'яўляецца пратаколам: стварэнне ўліковых запісаў, скід пароля, прызначэнне груп, рэгістрацыя MFA, правы на падключэнне і аўдытарскі след, які адказвае, хто і калі падключаўся. Community Edition не дае нічога з гэтага напрамую. Вы выбіраеце бэкенд аўтэнтыфікацыі, падключаеце PAM, LDAP або RADIUS праз плагін ці auth-user-pass-verify і самі падтрымліваеце астатняе. Access Server пастаўляе партал карыстальніка, адміністратарскую кансоль і інтэграцыі з папулярнымі пастаўшчыкамі ідэнтычнасці. Ніводная схема не бяспечнейшая па змаўчанні, бо палітыку ўсё яшчэ павінен напісаць чалавек, які ведае сетку.

Правы — гэта самая вострая аперацыйная розніца. Access Server ліцэнзуецца па колькасці адначасовых падключэнняў і трымае гэтую колькасць праграмна. У Community Edition глабальны ліміт — гэта адзін радок max-clients, а ўсё па карыстальніку ці групе азначае больш працы з client-config-dir і вашае ўласнае выкананне. Каманда без ахвоты да такой падтрымкі купляе менавіта гэта, калі плаціць за камерцыйны прадукт.

Ліцэнзаванне і падтрымка: радок, які ніхто не закладвае ў бюджэт

Community Edition бясплатны і адкрыты. Access Server — камерцыйны, і яго бясплатны ўзровень гістарычна пакрываў невялікую колькасць адначасовых падключэнняў, а вышэй — платная ліцэнзія. Любая лічба з даўняга адказу на форуме ўжо састарэла, таму праверце бягучыя ўмовы пастаўшчыка, перш чым лічыць кошт праекта. Сумленнае параўнанне дадае гадзіны, патрачаныя на стварэнне кіравання карыстальнікамі, MFA і маніторынгу на баку супольнасці, да радка ліцэнзіі на камерцыйным баку.

Адказнасць за падтрымку падпарадкоўваецца таму ж падзелу. З Community Edition вы — шлях эскалацыі для кожнага дзіўнага кліента і кожнага абнаўлення ядра. З Access Server у вас ёсць пастаўшчык, да якога можна звярнуцца, і вы атрымліваеце яго рытм выпускаў, падыходзіць ён вашаму акну змен ці не.

Праверкі, якія трэба правесці перад пераходам

Перад пераходам у любым кірунку праінвентарызуйце, што насамрэч трымае працуючы сервер. На баку Access Server экспартуйце спіс карыстальнікаў і прызначэнні груп і адзначце, якія ўліковыя запісы залежаць ад MFA. На баку Community Edition пералічыце выдадзеныя сертыфікаты, CRL і кожны файл у client-config-dir. Параўнайце два спісы радок за радком, бо розніца паміж імі — гэта праца па міграцыі.

Тэстуйце прадстаўнічых кліентаў, пакуль стары сэрвіс яшчэ працуе. openvpn --config client.ovpn --verb 4 на пярэднім плане друкуе рукапацісканне, перададзеныя маршруты і опцыі DNS, а openssl x509 -in client.crt -noout -subject -enddate паказвае, які сертыфікат кліент сапраўды прадстаўляе. Кліент, які падключаецца, але не дасягае ўнутранага хоста, мае прагаліну ў маршруце ці iroute, а не збой аўтэнтыфікацыі.

Трымайце стары шлях аднаўлення жывым, пакуль замена не пройдзе тэст адмовы ў доступе разам з паспяховым. Запішыце канчатковую карту на адной старонцы: кожная патраба, артэфакт, які задавальняе яе сёння, і артэфакт, які задаволіць яе пасля.