Dlaczego OpenVPN przestał się łączyć po aktualizacji Ubuntu?

Profile VPN, które działały w zeszłym tygodniu, psują się po aktualizacji wydania Ubuntu, a dziennik rzadko wspomina o aktualizacji. Wymienia za to warstwę, która zawiodła: uścisk dłoni TLS, szyfr wynegocjowany dla kanału danych, zainstalowany pakiet lub kopię OpenSSL, którą binarka ładuje przy starcie. Każda warstwa ma własną postać błędu i własną naprawę, więc klasyfikacja jest pierwszą pracą, a edycja drugą. Traktuj profil jako niewinny, dopóki dziennik go nie nazwie.

Która warstwa zawiodła: uścisk dłoni, szyfr, pakiet czy biblioteka

Przeczytaj dziennik klienta, zanim dotkniesz profilu. najwcześniejszy błąd w wyjściu wskazuje warstwę; wszystko wydrukowane później jest zwykle skutkiem tego pierwszego błędu. Gdy klient w ogóle nie startuje, dziennik VPN jest niewłaściwym plikiem do otwarcia.

Skargi na certyfikaty i podpisy albo komunikat o długości klucza pochodzą z kanału kontrolnego i polityki biblioteki, która nim rządzi. Ostrzeżenie zaczynające się od DEPRECATED OPTION należy natomiast do negocjacji kanału danych.

Linia typu Unrecognized option to trzecia kategoria: nowa binarka nie przyjmuje już dyrektywy, którą tolerowała stara, więc profil trzeba przepisać, a nie poluzować bibliotekę. Błędy pakietów wyglądają jeszcze inaczej, bo zdarzają się, zanim ruszy jakikolwiek kod tunelu. Brakująca binarka, wtyczka, która się nie ładuje, albo repozytorium wskazujące złą nazwę kodową dają tę samą postać. Cztery objawy, cztery miejsca do sprawdzenia i prawie żadnego nakładania się napraw.

Gdy uścisk dłoni zawodzi, polityka TLS odrzuca certyfikat

Ubuntu 22.04 przeniósł system na OpenSSL 3, a domyślny poziom bezpieczeństwa w tej gałęzi jest surowszy wobec podpisów certyfikatów i rozmiarów kluczy niż w 20.04. Certyfikat CA podpisany starszym skrótem albo klucz poniżej obecnego progu zawodzą teraz podczas uścisku dłoni. Ponieważ nic nie zostało jeszcze uwierzytelnione, błąd czyta się jak złe hasło albo martwy serwer.

Wąska naprawa przypina ciąg szyfru tylko do tego połączenia. W edytorze pulpitu otwórz profil, przejdź do ustawień zaawansowanych i wpisz DEFAULT:@SECLEVEL=0 w polu szyfru TLS. Plik klucza NetworkManagera przyjmuje tę samą wartość w sekcji [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Uruchom ponownie NetworkManagera i połącz się od nowa, bo demon buforuje przetworzone profile i inaczej będzie dalej używał kopii, którą już ma. Wiedz, co robi ta linia, zanim ją zostawisz: to ustawienie jest progiem obejmującym kilka parametrów certyfikatu i klucza, a nie nazwą szyfru, więc jego obniżenie poszerza to, co akceptuje pojedynczy profil. Zanotuj, który serwer tego wymagał, i usuń ustawienie, gdy operator ponownie wyda aktualny materiał. Zmiana /etc/ssl/openssl.cnf sięga tego samego progu dla każdego programu czytającego ten plik, co wychodzi daleko poza VPN.

OpenVPN 2.6 wymaga szyfru wymienionego do negocjacji

Ubuntu 22.10 dostarczył OpenVPN 2.6, a w tym wydaniu --cipher przestaje sam wybierać kanał danych. Szyfr musi też być na wynegocjowanej liście data-ciphers, inaczej klient wypisze ostrzeżenie o przestarzałości i potem nie zdoła podnieść tunelu.

Wtyczka NetworkManagera z tego okresu wciąż pisała tylko starą dyrektywę. Ten szczegół dzieli diagnozę, bo profil poprawiony ręcznie może połączyć się z powłoki i nadal zawodzić z apletu pulpitu. Dodaj listę do pliku połączenia w sekcji [vpn]:

data-ciphers=AES-256-CBC

Użyj wartości ogłaszanej przez serwer, nie tej, którą pamiętasz; serwer oferujący AES-256-GCM nie wynegocjuje z listą klienta wymieniającą tylko CBC. Uruchom menedżera ponownie i połącz się, potem powtórz próbę z powłoki, podając szyfr jawnie zarówno do negocjacji, jak i zapasowo:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Jeśli to polecenie podniesie tunel, serwer, certyfikaty i poświadczenia są zdrowe, a jedyną pozostałą usterką jest zapisana opcja menedżera. Ostrzeżenie o dyrektywie keysize należy do tego samego porządkowania: zakomentuj ją i zachowaj oryginalny plik obok profilu.

Usterki pakietów i wtyczek wyglądają jak usterki VPN

Nie każda awaria po aktualizacji jest kryptograficzna. Repozytorium OpenVPN dodane pod nazwą kodową, której wydanie nie używa, daje pakiet, który nigdy się nie instaluje, więc porównaj, co lsb_release -a raportuje, z dodanym plikiem listy. Brakujący składnik universe lub kieszeń bezpieczeństwa dają pakiet, którego nie da się w ogóle znaleźć. Oba przypadki zostawiają profil nietknięty, a tunel niemożliwy.

Przeczytaj błąd menedżera pakietów przed dziennikiem VPN. Jeśli klienta nigdy nie zainstalowano, żadna edycja profilu nie da uścisku dłoni.

Profile z dwoma czynnikami, które przestają pytać, to wtyczkowa wersja tej samej historii. Wyzwanie pochodzi z wtyczki uwierzytelniania, a aktualizacja, która ją usunęła lub zastąpiła, zostawia profil nietknięty, podczas gdy monit znika. Zainstaluj ponownie obsługiwaną wtyczkę zamiast usuwać drugi czynnik, żeby połączenie działało.

Biblioteka dostawcy może ukryć się za błędem polityki

Jeden wzorzec zasługuje na rozpoznanie, bo pokonuje każdą naprawę polityki. Narzędzie konfiguracyjne dostawcy sprzętu może zainstalować własne biblioteki OpenSSL i umieścić je przed kopiami systemowymi w ścieżce wyszukiwania loadera. Klient startuje wtedy przeciw bibliotece, której nikt nie zaktualizował, a błąd startu wygląda dokładnie jak odrzucony certyfikat.

Ponowna instalacja pakietu VPN nie zmienia tego, która biblioteka zostanie znaleziona pierwsza, a obniżenie poziomu TLS nie sięga biblioteki, która nigdy nie pochodziła z systemu. Zapytaj loader, które obiekty kryptograficzne binarka naprawdę rozwiązuje:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Usuń lub przekeiruj kopię dostawcy, a potem uruchom tę samą kontrolę ponownie. Oczekiwana wersja musi być tą używaną, zanim wrócisz do profilu.

Przypięcie starszego klienta kupuje czas, nie rozwiązanie

Przytrzymanie poprzedniej wersji klienta przywraca tunel na czas trzymania. Zamraża też aktualizacje bezpieczeństwa tego pakietu i planuje to samo zerwanie przy następnej aktualizacji, więc traktuj to jako datowane obejście, a nie rozwiązanie.

Jeśli jednak je przypniesz, przytrzymaj pakiet jawnie, aby niepilnowana aktualizacja nie mogła cofnąć przypięcia, zapisz powód i datę przeglądu i ustaw przypomnienie na następne wydanie profilu od dostawcy. Warunkiem wartym obserwacji jest profil serwera negocjujący aktualny szyfr; gdy tylko istnieje, przypięcie nie ma już uzasadnienia. Niezapisane przypięcie staje się natomiast awarią, której nikt nie wyjaśni pół roku później, bo osoba, która je zastosowała, odeszła, a plik nic nie rejestruje.

Następnym razem, gdy VPN umrze po aktualizacji wydania, zadaj pięć pytań po kolei: która warstwa dała pierwszy błąd, czy polityka TLS odrzuciła certyfikat, czy szyfr da się negocjować w obu kierunkach, czy pakiet i jego wtyczka naprawdę się zainstalowały i którą bibliotekę ładuje proces. Dopiero gdy wszystkie pięć wrócą czyste, obniżenie wersji ma sens.