Wiele małych firm korzysta z serwera OpenVPN, który ktoś skonfigurował lata temu i którego od tamtej pory nikt nie ruszał. Działa do chwili, gdy zostanie zaktualizowany system operacyjny serwera albo pojawi się nowy laptop z najnowszym klientem, i nagle część użytkowników lub wszyscy nie mogą się połączyć. Debian 12 i 13 oraz Ubuntu 24.04 dostarczają serię OpenVPN 2.6, zbudowaną z OpenSSL 3, a razem rezygnują z kilku starych ustawień domyślnych. Ten przewodnik wyjaśnia, co zwykle przestaje działać przy aktualizacji OpenVPN 2.6, jak to naprawić właściwie, zamiast przywracać stare ustawienia, i co jeszcze sprawdzić, skoro konfiguracja jest i tak otwarta.

Szyfry: od cipher do OpenVPN data-ciphers

Starsze konfiguracje często zawierają linię w rodzaju cipher BF-CBC albo cipher AES-256-CBC, albo nie mówią nic i polegają na dawnym domyślnym Blowfish. Od wersji 2.5 OpenVPN negocjuje szyfr kanału danych z listy ustawianej opcją OpenVPN data-ciphers i domyślnie akceptuje AES-256-GCM oraz AES-128-GCM, a w 2.6 także CHACHA20-POLY1305, jeśli biblioteka kryptograficzna to obsługuje. Opcja cipher nie jest już automatycznie dodawana do tej listy. Bardzo stare klienty, które nie potrafią negocjować, albo serwery skonfigurowane nadal tylko pod Blowfish nie nawiążą połączenia.

OpenSSL 3 dokłada drugą barierę: nie oferuje już Blowfisha ani innych przestarzałych algorytmów, dopóki jawnie nie załaduje się jego dostawcy legacy. Ta opcja jest tymczasowym mostem, a nie celem. Trwałe rozwiązanie to aktualizacja klientów i pozwolenie, by obie strony wynegocjowały AES-GCM lub ChaCha20.

Kompresja jest domyślnie wyłączona

Konfiguracje z czasów wersji 2.3 i 2.4 często zawierają comp-lzo albo linię compress. Kompresja połączona z szyfrowaniem może zdradzać informacje o ruchu, co znane jest jako atak VORACLE, dlatego kompresja OpenVPN jest od lat odradzana. W 2.6 allow-compression ma domyślnie wartość no, chyba że konfiguracja jawnie wspomina o kompresji. Niezgodne ustawienia serwera i klienta objawiają się tunelami, które się łączą, a potem nie przepuszczają ruchu. Czyste rozwiązanie to usunięcie kompresji z serwera i z każdego profilu klienta. Jeśli część klientów nie może być od razu zaktualizowana, zostaw jawne, asymetryczne ustawienie tylko na krótki okres przejściowy.

Certyfikaty, klucze i "CRL has expired"

Przy aktualizacji zwykle wychodzą na jaw trzy problemy z certyfikatami:

  • Słabe stare klucze i podpisy. OpenSSL 3 w konfiguracji z Debiana i Ubuntu odrzuca klucze RSA krótsze niż 2048 bitów oraz certyfikaty podpisane przestarzałymi funkcjami skrótu. Urząd certyfikacji utworzony dziesięć lat temu z krótkimi kluczami trzeba wymienić, a każdy użytkownik potrzebuje nowego profilu.
  • Wygasające certyfikaty. Obecne wydania easy-rsa wystawiają certyfikaty serwera i klientów z ograniczonym okresem ważności. Sprawdź daty wygaśnięcia teraz, a nie rano w dniu, gdy upłyną.
  • Wygasła lista unieważnionych certyfikatów. Jeśli serwer używa crl-verify, lista unieważnień ma własną datę ważności, domyślnie 180 dni w easy-rsa. Gdy minie, każdy klient kończy z błędem "CRL has expired", choć nic innego się nie zmieniło. Wygeneruj ją ponownie poleceniem easyrsa gen-crl, skopiuj tam, skąd czyta ją serwer, i zaplanuj odnawianie, żeby to się nie powtórzyło.

Hardening serwera OpenVPN przy okazji

Aktualizacja to dobry moment, by dodać ustawienia, których brakuje w starych konfiguracjach:

  • tls-crypt lub tls-crypt-v2 z osobnym kluczem dla każdego klienta szyfruje i uwierzytelnia kanał kontrolny, więc serwer nie odpowiada nikomu bez klucza. Ukrywa serwer przed skanami i osłabia próby ataków typu odmowa usługi.
  • Minimalna wersja TLS 1.2 dla kanału kontrolnego.
  • Certyfikaty dla każdego użytkownika plus drugi składnik, żeby sam skopiowany profil nie wystarczył do połączenia.
  • Reguły firewalla dla grup, żeby profil wykonawcy docierał do jednej aplikacji, a nie do całej sieci biurowej.
  • Data channel offload w Linuksie, nowość w 2.6, który przenosi szyfrowanie pakietów do jądra, dając lepszą przepustowość na mocno obciążonych serwerach.

Każda opcja wraz z aktualną wartością domyślną jest opisana w podręczniku referencyjnym OpenVPN 2.6, który warto mieć otwarty podczas pracy.

Ścieżka aktualizacji OpenVPN 2.6 bez awarii w poniedziałek rano

  1. Skopiuj w bezpieczne miejsce obecną konfigurację serwera, klucze i profile klientów.
  2. Wypisz wszystkich używanych klientów: system operacyjny, wersję klienta i właściciela.
  3. Zbuduj nową konfigurację na instancji testowej lub drugim porcie i połącz po jednym zaktualizowanym kliencie każdego typu.
  4. Wystaw nowe profile tam, gdzie zmieniają się certyfikaty lub szyfry, i wyślij użytkownikom krótkie instrukcje konfiguracji klienta OpenVPN na ich urządzeniach.
  5. Przełącz w spokojnym momencie i trzymaj stary serwer w gotowości do powrotu, dopóki wszyscy się nie połączą.

Przy instalacji VPN na Linuksie budowanej od zera ta sama lista kontrolna staje się projektem: nowoczesne szyfry, brak kompresji, tls-crypt i certyfikaty z listą unieważnień, która odnawia się sama. Jeśli wolisz oddać tę pracę, nasza usługa konfiguracji OpenVPN obejmuje urząd certyfikacji, reguły firewalla i profile klientów.

Najczęściej zadawane pytania: aktualizacja OpenVPN 2.6

Czy po aktualizacji użytkownicy potrzebują nowych profili?

Tylko jeśli zmienia się coś, co mają u siebie: nowy urząd certyfikacji, nowe certyfikaty, klucz tls-crypt albo inne ustawienia szyfrów. Usunięcie kompresji zwykle oznacza też edycję profilu, dlatego wiele aktualizacji kończy się świeżymi profilami dla wszystkich.

Jak zapobiec ponownemu wygaśnięciu CRL?

Zaplanuj easyrsa gen-crl z dużym zapasem względem okresu ważności CRL, skopiuj nowy plik do ścieżki podanej w crl-verify i ustaw alert, gdy zbliża się data następnej aktualizacji. Obecne wersje wczytują plik ponownie po zmianie, więc restart nie jest potrzebny, ale plik musi pozostać czytelny dla użytkownika, z którego uprawnieniami działa serwer OpenVPN.

Czy stare klienty mogą działać w okresie przejściowym?

Przez krótki czas tak, jeśli na serwerze jawnie dopuścisz ich szyfry lub kompresję. Traktuj to jako termin, a nie ustawienie na stałe.

Klienci przestają się łączyć po aktualizacji albo masz serwer OpenVPN, na który nikt nie patrzył od lat? Nasza usługa instalacji i konfiguracji OpenVPN obejmuje hardening serwera, certyfikaty i profile dla każdego użytkownika na Windows, macOS, Linux i urządzenia mobilne, a jako usługa konfiguracji VPN wpisuje się w szerszą pracę nad bezpieczeństwem sieci i VPN dla biur w Long Beach i Los Angeles. Skontaktuj się z nami, podając wersję systemu operacyjnego serwera i wersje klientów używanych w zespole.