Usunięcie key-method z profilu OpenVPN niczego nie zmienia

Profil, który działał latami, nagle odmawia uruchomienia, a komunikat wymienia dyrektywę, której nikt nie pamięta dodawać: key-method. Następny wynik wyszukiwania sugeruje dodanie key-method 2 dla zgodności, co jest radą z innej epoki. Parser, który odrzucił tę linię, jest bieżący i w ogóle nie ma takiej opcji. Usunięcie linii naprawia uruchamianie i niczego nie zmienia w tym, jak obie strony chronią sesję.

Właśnie ta luka między tym, co zawiera profil, a tym, co protokół rzeczywiście robi, jest całym tematem, i wyjaśnia kilka innych zmian, które ludzie robią jednocześnie. Wyjaśnia też, dlaczego te zmiany zwykle przychodzą w jednym pakiecie.

Objawem jest błąd parsowania, a nie niepowodzenie uzgadniania

Opcje są czytane, zanim zostanie wysłany jakikolwiek pakiet. Profil z nieznaną dyrektywą zawodzi na tym etapie, więc proces nigdy nie dociera do sieci i nigdy nie tworzy błędu uzgadniania. Sformułowanie zwykle wskazuje opcję i plik, co czyni to jednym z najłatwiejszych do przypisania niepowodzeń. Nie bierze w nim udziału żaden pakiet, trasa ani zapora.

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

Jeśli komunikat wymienia dyrektywę, diagnoza jest zakończona: plik zawiera coś, czego ta kompilacja nie akceptuje. Jeśli komunikat wymienia zamiast tego ścieżkę pliku, problemem jest brakujący include lub klucz, co jest inną częścią tego samego etapu uruchamiania.

Nie należy wnioskować, że klient lub serwer potrzebuje starszego trybu protokołu. Błąd parsowania to problem słownictwa między twoim plikiem a plikiem binarnym, a plik binarny w tym przypadku po prostu wyrzucił jedno słowo ze swojego słownictwa.

Dyrektywa i format transmisji to dwie różne rzeczy

Stara opcja key-method wybierała sposób ramkowania wymiany kluczy TLS, a nowoczesna wymiana to metoda wielopakietowa, której ta opcja kiedyś wymagała. Opcja zniknęła, bo niczego już nie wybierała; format, który nazywała, stał się jedynym. Usunięcie linii pozostawia więc sesję z tym samym ramkowaniem co wcześniej. Zmiana tekstu nie może tego zmienić w żadnym kierunku.

Dlatego przywracanie starego pliku binarnego, aby „odtworzyć” metodę 2, jest niewłaściwą naprawą. Nie przywraca niczego poza starszym parserem ze starszymi wartościami domyślnymi i kosztuje cię poprawki, które przyszły później. Ta sama logika dotyczy osłabiania sprawdzania certyfikatu lub listy szyfrów w nadziei, że połączenie wróci.

Przydatnym sprawdzeniem jest wersja i sparsowana konfiguracja, a nie obecność tego słowa w pliku:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

Co usunąć i z którego pliku

Edytuj plik, który uruchomiony proces faktycznie czyta, i tylko ten plik. W systemach pakietowych jest to zwykle profil w katalogu klienta lub serwera wskazanym przez jednostkę, a nie kopia w twoim katalogu domowym trzymana dla odniesienia. Wygenerowany profil może być też odtworzony z szablonu, więc zmiana wprowadzona tylko w kopii wdrożonej wróci po następnym uruchomieniu przygotowania.

Usuń przestarzałą linię, a punkt końcowy, certyfikaty, politykę szyfrów i ustawienia kanału sterującego zostaw w spokoju. To wspierane opcje, których proces potrzebuje, i nie mają one związku z błędem parsowania. Jeśli ten sam profil zawiera inne dyrektywy, których nie rozpoznajesz, sprawdź każdą z nich względem uruchomionej wersji, zamiast usuwać ich grupę, aż proces wystartuje.

Następnie uruchom zamierzony egzemplarz i przeczytaj jego dane wyjściowe przy starcie. Czysty start z obecnym nasłuchiwaczem jest potwierdzeniem, że ten etap się zakończył; test klienta później odpowiada na inne pytanie.

Odrzucony profil i odrzucony klient wyglądają podobnie

Dwa niepowodzenia tworzą podobne wątki wsparcia i wymagają innych dowodów. Serwer, który odrzuca własną konfigurację, nigdy nie startuje, więc żaden klient nie może się z nim połączyć. Serwer, który startuje dobrze i odrzuca jednego klienta, działa, a jego dziennik zawiera powód: problem z certyfikatem, wypchnięta opcja, której klient nie akceptuje, niezgodność szyfru.

Usunięta opcja nie jest diagnozą drugiego przypadku, a sięganie po nią marnuje tę samą godzinę dwa razy. Jeśli dziennik klienta pokazuje odrzucenie przez serwer, przeczytaj to odrzucenie; jeśli pokazuje błąd lokalny, plikiem do zbadania jest profil klienta. Sięganie po dyrektywę, której już nie ma, opóźnia oba dochodzenia o tyle samo.

Pytania o zgodność, na które ta linia nigdy nie odpowiedziała

Profile krążące z tą dyrektywą zwykle niosą historię o konkretnej platformie, a historia przeżywa techniczny powód. Klient mobilny lub desktopowy nadal potrzebuje kompletnego wspieranego profilu: zaufanego łańcucha certyfikatów, szyfru danych akceptowanego przez obie strony, trybu kanału sterującego implementowanego przez obie strony i żadnych dyrektyw odrzucanych przez kompilację klienta. Nic z tego nie zależy od obecności starej linii key-method.

Kompresja to osobne pytanie polityki o tym samym kształcie. Usunięcie linii key-method nic nie mówi o tym, czy dyrektywa kompresji jest wspierana lub akceptowalna we wdrożeniu, a obie decyzje należy podjąć niezależnie. Usuwanie kilku ustawień istotnych dla bezpieczeństwa naraz, aż coś się połączy, to droga, na której działający profil staje się profilem niewyjaśnionym.

Prowadź krótką notatkę o tym, co usunąłeś i dlaczego: opcja, wersja, która ją odrzuciła, i polecenie, które pokazało błąd. Następna osoba, która odziedziczy profil, będzie potrzebować dokładnie tych trzech faktów, a zapisanie ich teraz jest tańsze niż późniejsze odtwarzanie.