Dlaczego dodanie opt-verify nie naprawi błędu szyfrowania w OpenVPN

Znajdujesz sugestię dodania opt-verify, dodajesz linię, a błąd szyfrowania zostaje dokładnie tam, gdzie był. Ten wynik jest przewidywalny, bo opcja nigdy nie negocjowała szyfrowania. Było to sprawdzenie spójności opcji, przestarzałe w 2.6 i usunięte w 2.7, a profil, który się z nim nadal parsuje, niczego tym nie wymusił.

Warto wiedzieć, co linia robiła wcześniej, zanim uzna się ją za brakujący element. Historia wyjaśnia też, dlaczego teraz nie może pomóc.

Co opcja wcześniej wymuszała

Podręcznik wersji 2.6 oznacza opt-verify jako przestarzałe i opisuje wcześniejsze zachowanie: serwer odrzuca klientów, których zadeklarowane opcje nie zgadzają się z jego własnymi, porównując takie rzeczy jak typ urządzenia i MTU. To sprawdzenie zależy też od tego, czy sprawdzanie spójności opcji pozostaje włączone, więc serwer działający z disable-occ nigdy go nie miał. Zwróć uwagę, z czego zbudowane jest porównanie: z tekstu opisującego konfigurację drugiej strony. Nie mówi ono nic o tym, jakiego szyfrowania użyje kanał danych.

To pierwszy powód, dla którego flaga nie może naprawić błędu szyfrowania. Wybór szyfrowania reguluje polityka data-ciphers i to, co obsługują obie strony, a tekstowe sprawdzenie spójności ani nie rozszerza tej listy, ani nie wykonuje negocjacji. Drugi powód to zakres: sprawdzenie dotyczy tego, czy zadeklarowane opcje wyglądają na zgodne, a nie jakości powstałej ścieżki.

Co robi 2.7, gdy widzi tę linię

W wersji 2.7 opcji nie ma. Parser nadal rozpoznaje nazwę, dlatego stary profil ładuje się bez błędu składni, i zgłasza, że opcja została usunięta, zamiast ją po cichu pominąć. Rozpoznanie nazwy i wymuszenie zachowania to dwie różne rzeczy, a nadal dzieje się tylko to pierwsze. Uwagi o usunięciu podają powód: gdy parametrami można negocjować, dwie strony mogą legalnie mieć różne ciągi opcji, mimo że zgadzają się co do połączenia.

Profil, który się parsuje, nie jest więc dowodem, że wykonano jakiekolwiek sprawdzenie dopuszczenia. Jeśli jedynym sygnałem jest to, że klient się połączył, dowiedziałeś się, że składnia została zaakceptowana.

Gdzie naprawdę tkwi awaria

Zachowaj pierwszy konkretny błąd, zanim cokolwiek zmienisz, bo późniejsze komunikaty są zwykle jego konsekwencjami. Awaria negocjacji kanału danych należy do zatwierdzonej polityki szyfrowania i do możliwości, które obie strony faktycznie ogłaszają. Awaria wersji lub zestawu TLS należy do kanału sterującego. Odrzucenie certyfikatu wymaga tożsamości i łańcucha zaufania, a nie flagi zgodności.

Zidentyfikuj też silnik po obu stronach. Aplikacja desktopowa może zawierać inną kompilację niż binarka wiersza poleceń, której użyłeś do testów, a obsługa opcji różni się między nimi. Sprawdź dokumentację tego silnika, zamiast zakładać, że każdy program importujący profil zachowuje się tak samo.

Zastąp intencję, nie tylko linię

Jeśli starszy zarządzany serwer naprawdę polegał na sprawdzaniu spójności, zapisz, jakie ograniczenie wymuszał przed aktualizacją. Utrzymanie ignorowanej opcji w nowszym profilu nie może zachować tej polityki, a bezmyślne usuwanie linii też nie.

Nie odpowiadaj na starą sugestię, że wszystkie szyfry są wyłączone, włączając każdy historyczny algorytm.

Po zatwierdzonej poprawce sprawdź wynegocjowane wyniki na nowym połączeniu i przetestuj aplikację, której użytkownik naprawdę potrzebuje. Trzymaj wersję serwera i obowiązującą politykę obok tego wyniku, aby następna osoba widziała, co uzgodniono, a nie tylko co przyjęto.

Celem jest obsługiwane ograniczenie i działająca uwierzytelniona ścieżka, a nie stara flaga, która nadal się parsuje.