OpenVPN Access Server a Community: co naprawdę się przenosi

Profile się przenoszą; listy użytkowników zostają. Zespół przechodzący między Access Server a Community Edition napotyka tę lukę godzinę po przełączeniu, gdy jego pierwszy klient uwierzytelnia się, a potem nie ma polityki grupowej, trasy dla użytkownika ani samoobsługowego resetu hasła. Oba produkty mówią tym samym protokołem i przyjmują tego samego klienta, i właśnie dlatego luka pozostaje niewidoczna podczas planowania. To, co naprawdę wybierasz, to warstwa zarządzania i ludzie, którzy ją posiadają.

Potraktuj decyzję jako pytanie o inwentarz, a nie tabelę funkcji. Zapytaj, kto tworzy użytkowników, kto unieważnia certyfikaty i kto odbiera telefon o 02:00.

Dlaczego plik .ovpn nie przenosi konfiguracji

Profil .ovpn opisuje relację jednego klienta z jednym serwerem: zdalny host, protokół, CA, certyfikat i klucz klienta oraz wszelki wbudowany materiał tls-crypt. Wrzuć ten plik do nowej instalacji, a klient nadal ukończy uzgadnianie, więc migracja wygląda na zakończoną. Nic w nim nie wymienia użytkowników, ich grup, tras statycznych ani polityki, która decydowała, komu w ogóle wolno się łączyć. Te rekordy żyją we własnym magazynie serwera, a oba produkty przechowują je w różnych formach.

W Community Edition odpowiednikami są pliki, które sam utrzymujesz: wpisy client-config-dir z opcjami dla klienta, takimi jak ifconfig-push i iroute, CRL do unieważnień i klucz tls-crypt. Access Server trzyma te same pojęcia we własnej bazie danych i udostępnia je przez konsolę webową oraz narzędzie wiersza poleceń sacli. Pojęcia mapują się jeden do jednego; artefakty w ogóle się nie przenoszą.

Profile przemycają też zachowania, których nikt nie zauważa, dopóki się nie zmienią. Klient z redirect-gateway def1 wysyła całe przeglądanie przez serwer; przenieś go do instalacji bez tej linii, a skarga będzie taka, że internet się zepsuł. Niezgodność CA lub błędne ustawienie remote-cert-tls kończy się głośnym błędem, co jest dobrym wynikiem. Brakujący klucz tls-crypt kończy się cichym przekroczeniem limitu czasu, co nim nie jest.

Czym zarządza warstwa zarządzania

Policz to, co nie jest protokołem: tworzenie kont, reset haseł, przypisywanie do grup, rejestracja MFA, uprawnienia do połączeń i ślad audytowy odpowiadający, kto i kiedy się połączył. Community Edition nie dostarcza niczego z tego bezpośrednio. Wybierasz backend uwierzytelniania, podłączasz PAM, LDAP lub RADIUS przez wtyczkę albo auth-user-pass-verify, a resztą zajmujesz się sam. Access Server dostarcza portal użytkownika, konsolę administracyjną i integracje z popularnymi dostawcami tożsamości. Żadne z rozwiązań nie jest domyślnie bezpieczniejsze, bo politykę nadal musi napisać ktoś, kto zna sieć.

Uprawnienia to najostrzejsza różnica operacyjna. Access Server jest licencjonowany według liczby jednoczesnych połączeń i egzekwuje tę liczbę programowo. W Community Edition globalny limit to jedna linia max-clients, podczas gdy cokolwiek na użytkownika lub grupę oznacza więcej pracy z client-config-dir i własne egzekwowanie. Zespół bez ochoty na tę konserwację kupuje dokładnie to, płacąc za produkt komercyjny.

Licencje i wsparcie: pozycja, której nikt nie budżetuje

Community Edition jest darmowy i open source. Access Server jest komercyjny, a jego darmowy poziom historycznie obejmował niewielką liczbę jednoczesnych połączeń, powyżej czego obowiązuje płatna licencja. Każda liczba z dawnej odpowiedzi na forum jest już nieaktualna, więc sprawdź obecne warunki dostawcy, zanim policzysz koszt projektu. Uczciwe porównanie dodaje godziny spędzone na budowie zarządzania użytkownikami, MFA i monitoringu po stronie społeczności do pozycji licencyjnej po stronie komercyjnej.

Własność wsparcia podlega temu samemu podziałowi. Z Community Edition to ty jesteś ścieżką eskalacji dla każdego dziwnego klienta i każdej aktualizacji jądra. Z Access Server masz dostawcę, do którego można zadzwonić, i dziedziczysz jego rytm wydań, czy pasuje do twojego okna zmian, czy nie.

Kontrole przed przełączeniem

Przed przełączeniem w którąkolwiek stronę zinwentaryzuj, co faktycznie trzyma działający serwer. Po stronie Access Server wyeksportuj listę użytkowników i przypisania do grup oraz zanotuj, które konta opierają się na MFA. Po stronie Community Edition wymień wystawione certyfikaty, CRL i każdy plik w client-config-dir. Porównaj obie listy wiersz po wierszu, bo różnica między nimi to praca migracyjna.

Testuj reprezentatywnych klientów, gdy stara usługa jeszcze działa. openvpn --config client.ovpn --verb 4 na pierwszym planie wypisuje uzgadnianie, wysłane trasy i opcje DNS, a openssl x509 -in client.crt -noout -subject -enddate pokazuje, który certyfikat klient naprawdę przedstawia. Klient, który się łączy, ale nie dociera do hosta wewnętrznego, ma lukę w trasie lub w iroute, a nie błąd uwierzytelniania.

Utrzymuj starą ścieżkę odzyskiwania przy życiu, aż zamiennik przejdzie zarówno test odmowy dostępu, jak i test udany. Zapisz ostateczną mapę na jednej stronie: każde wymaganie, artefakt, który je dziś spełnia, i artefakt, który spełni je później.