Stary profil .ovpn nie działa na Ubuntu 24.04: które linie usunąć

Ubuntu 24.04 dostarcza OpenVPN 2.6, a profil wyeksportowany dla 2.4 pada na usuniętych opcjach. Usuń keysize i ncp-disable, a następnie popraw ns-cert-type.

Profil pobiera się, importuje, a potem zatrzymuje w wierszu 12 pliku z komunikatem Unrecognized option, który wymienia keysize. Na koncie nic się nie zmieniło, a serwer nadal akceptuje innych klientów. Zmienił się sam klient: Ubuntu 24.04 instaluje OpenVPN 2.6, podczas gdy eksport powstał dla wersji 2.4. Naprawa to krótka seria usunięć, a kolejność ma znaczenie, bo każda przestarzała opcja przerywa parsowanie, zanim następna zostanie w ogóle odczytana.

Przeczytaj wiersz błędu, zanim dotkniesz pliku

OpenVPN podaje plik i wiersz, na którym zatrzymało się parsowanie, więc w jednym uruchomieniu naprawisz tylko jeden problem. Uruchom profil z terminala, a nie z apletu pulpitu, bo aplet zwykle połyka stderr, a numer wiersza to jedyny wiarygodny wskaźnik, jaki dostaniesz: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Popraw ten wiersz, uruchom ponownie i spodziewaj się, że następny błąd wskaże inną opcję.

Błąd parsowania zawsze pojawia się przed jakimkolwiek uzgadnianiem TLS, więc komunikat wspominający certyfikat przeszedł już etap składni. To rozróżnienie powstrzymuje cię przed edytowaniem pliku, który zawodzi tylko na uwierzytelnianiu. Czytaj pierwsze słowo komunikatu, a nie jego środek.

Trzy klasy awarii, trzy różne naprawy

Stare eksporty zawodzą na trzy rozpoznawalne sposoby, a składanie ich w jeden problem jest powodem, dla którego ludzie reinstalują pakiety, które nigdy nie były zepsute. Brzmienie komunikatu mówi, w której klasie jesteś, zanim otworzysz plik.

  • Błędy parsowania podają plik i wiersz i zatrzymują się, zanim pojawi się jakikolwiek ruch.
  • Błędy negocjacji łączą się, a następnie zgłaszają, że obie strony nie mogły uzgodnić wspólnego szyfru lub akceptowalnego kanału danych.
  • Błędy uwierzytelniania dochodzą najdalej i podają certyfikat, użytkownika lub odrzucone poświadczenie.

Edycja profilu naprawia tylko pierwszą klasę. Negocjacja wymaga decyzji na obu końcach tunelu, a odrzucone poświadczenie nie jest w ogóle problemem składni. Jeśli twój komunikat wspomina wspólny szyfr lub kanał danych, poniższe usunięcia nic nie zmienią.

Usuń opcje, które 2.6 wycofało, w tej kolejności

Każda z tych linii samodzielnie zatrzymuje parsowanie, więc klient zgłasza je pojedynczo. Przechodź w dół listy i uruchamiaj ponownie po każdym usunięciu.

Najpierw usuń keysize, bo nie ma nowoczesnego odpowiednika, a jego obecność zwykle oznacza szyfr, którego obecny klient i tak odmawia. Następnie usuń ncp-disable, który sterował negocjacją szyfrów, został wycofany w 2.5 i zniknął w 2.6. Zastąp ns-cert-type server przez remote-cert-tls server, który wyraża ten sam zamiar poprzez obsługiwane sprawdzenie.Historia zmian 2.6 wymienia pozostałe usunięcia obok ich zamienników, więc wszystko, co parser nadal odrzuca, ma udokumentowaną odpowiedź.

Zachowaj kopię oryginalnego profilu przed pierwszą edycją. Dostawcy rzeczywiście generują eksporty ponownie, a diff z nietkniętym plikiem to najszybszy sposób oddzielenia twoich zmian od ich zmian. Jeśli usunięcie pozwala klientowi wystartować, ale tunel nadal zawodzi,przeszedłeś do klasy negocjacji a pozostałe linie nie są przyczyną. Umieść wersję klienta w nazwie pliku, żeby następna osoba wiedziała, której wersji dotyczą edycje.

Utrzymuj BF-CBC tylko jako ograniczony fallback

Niektórzy dostawcy nadal kończą na BF-CBC, którego OpenVPN 2.6 nie negocjuje bez pomocy, bo ten szyfr ma blok 64-bitowy. Wąska naprawa to lista fallbacków plus dostawca legacy OpenSSL, a nie degradacja całego klienta.

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

Pierwsza linia ładuje dostawcę legacy, żeby OpenSSL nadal mógł utworzyć ten szyfr, druga zachowuje nowoczesną negocjację dla partnerów, którzy ją obsługują, a trzecia działa tylko wtedy, gdy serwer nie oferuje nic lepszego. To świadome osłabienie tunelu, więc zapisz obok pliku, dlaczego istnieje. Poproś dostawcę jednocześnie o ponownie wygenerowany eksport, bo fallback jest mostem, a nie celem.

Nie sięgaj po --compat-mode jako uniwersalną odpowiedź. Zmienia on kilka zachowań naraz, w tym domyślne ustawienia negocjacji i renegocjacji, więc nigdy nie dowiesz się, która zmiana miała znaczenie. Wybierz trzy jawne linie powyżej, bo każda podaje własny efekt.

Zweryfikuj z profilem, który klient faktycznie ładuje

Zaimportowane połączenia są często kopiowane do katalogu systemowego, więc edycja pliku w folderze pobranych może nic nie zmienić. Znajdź kopię, która działa: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Następnie uruchom tunel i przeczytaj wiersz logu, który podaje faktycznie wybrany szyfr kanału danych. Połączenie, które kończy uzgadnianie na fallbacku, mówi ci, że serwer nigdy nie zaproponował nic nowoczesnego.

Testuj z sieci innej niż ta, której oczekuje dostawca, żeby portal przechwytujący lub filtrowana sieć gościnna nie udawały awarii profilu. Zapisuj wersję klienta przy każdym zgłoszeniu do pomocy.

Gdy tunel działa, wyślij jedno żądanie, które musi go przekroczyć, i jedno, które nie może, a potem potwierdź, że odpowiedź resolvera zmieniła się tak, jak oczekiwałeś. Jeśli profil się teraz parsuje, ale połączenie nadal zawodzi, zostawiłeś problem składni za sobą, a tekst błędu wskaże nową klasę. Trzymaj edytowany plik w kontroli wersji obok notatki podającej wersję OpenVPN, której dotyczy.

Powiązane artykuły