OpenVPN zgłasza, że ncp-disable jest nieznany: co go zastąpiło?

Klient odmawia uruchomienia z błędem opcji, który wskazuje ncp-disable, choć profil działał na poprzedniej maszynie. Ten komunikat nie oznacza, że opcja jest błędnie zapisana ani że szyfrowanie jest zepsute. Oznacza, że plik binarny przed tobą w ogóle nie zna tej dyrektywy, a są ku temu dwa bardzo różne powody. Który zachodzi, decyduje o tym, czy edytujesz profil, czy zmieniasz klienta.

Błąd może pochodzić z nowszego pliku binarnego

Błąd nieznanej opcji dotyczy parsera, a nie tunelu. OpenVPN 2.4 dodał negocjowalne parametry szyfrowania, 2.5 uznał przełącznik, który je wyłączał, za przestarzały, a 2.6 usunął go całkowicie. Dlatego profil napisany dla 2.3 lub 2.4 zawodzi na obecnym kliencie, nawet jeśli w pliku nic się nie zmieniło. Wersja, która się skarży, jest nowsza, nie starsza.

Ustal, który plik wykonywalny wygenerował komunikat, zanim cokolwiek zmienisz. Klient biurkowy ma własny silnik, a osobno zainstalowany plik binarny wiersza poleceń ma własną wersję. Oba mogą się nie zgadzać na tej samej maszynie.

openvpn --version rozstrzyga to dla testowanego pliku binarnego. Klient GUI może nie pokazywać tego polecenia; wtedy przeczytaj jego ekran informacyjny lub wersję dołączonej biblioteki.

Czym opcja naprawdę sterowała

Dyrektywa wyłączała negocjację parametrów kryptograficznych, więc oba końce wracały do starszego zachowania wyboru sterowanego ustawieniem cipher. Nigdy nie wyłączyła szyfrowania i nigdy nie zamieniła tunelu w zwykły tekst. Czytanie jej jako przełącznika bezpieczeństwa to pierwszy zły krok i prowadzi do zmian, które pogarszają połączenie zamiast je poprawiać.

Gdy negocjacja istnieje, równoważne pytanie brzmi, jakich szyfrów każda strona chce używać. To pytanie o politykę, a polityka mieszka w data-ciphers od wersji 2.5.

Starsza nazwa ncp-ciphers należy do 2.4. Mieszanie obu nazw między stronami to częste źródło jednostronnych niepowodzeń negocjacji. Profil zawierający obie to profil edytowany przez dwie osoby w różnym czasie.

Zastąp politykę, nie pisownię

Ustaw data-ciphers po obu stronach z zamierzonym wspólnym wyborem i utrzymuj listę na tyle krótką, by recenzent mógł ją przemyśleć. Zmiana jednej dowolnej linii niczego nie dowodzi; wynik zależy od przecięcia obu list oraz od tego, co obsługuje stos TLS. Potwierdź zgodę stron, czytając wynik negocjacji, a nie konfigurację. Następnie zapisz obie listy w rejestrze wdrożenia, aby kolejna zmiana zaczynała się od znanego stanu.

Aktualizuj profil przez osobę, która go posiada. Dodanie opcji ignorowania, by ukryć przestarzałą dyrektywę, pozostawia pytanie o politykę bez odpowiedzi.

Jeśli starsza strona naprawdę potrzebuje obsługi zgodności, ogranicz ją do tego wdrożenia. Przywracanie przestarzałego zachowania globalnie nie jest warunkiem połączenia nowoczesnych stron. Wyjątek powinien nazywać stronę, dla której istnieje.

Dwie linie, które wyglądają jak lista szyfrów, ale nią nie są

Układanie dwóch linii szyfru w stos również nie przywraca negocjacji, a wynikiem jest profil, który wygląda jak lista, choć zachowuje się jak pojedyncza wartość. Linia z AES-256-CBC i następna z CBC to częsta próba. CBC samo w sobie nazywa tryb, a nie algorytm, więc parser może je przyjąć w jednym miejscu i odrzucić w następnym. Powtórzone dyrektywy cipher ustawiają tę samą opcję dwa razy zamiast gromadzić kandydatów.

Sprawdzaj akceptowane nazwy za pomocą openvpn --show-ciphers na docelowym pliku binarnym, zamiast kopiować listę z poradnika pisanego dla innej gałęzi. Lista zmienia się między wydaniami. Nazwa ważna w jednej gałęzi nie musi być ważna w drugiej.

Jeśli celem było porównanie wydajności, zapisz algorytmy i obciążenie. Przejście na CBC nie jest pomiarem braku szyfrowania.

Sprawdź, co połączenie naprawdę wynegocjowało

Nawiąż nowe połączenie i odczytaj wiersz kanału danych w logu, który nazywa używany szyfr. Zestaw kanału sterującego jest ustalany osobno, więc dozwolona lista w pliku pokazuje tylko, co zaproponowano. Gdy obie strony wybrały coś, czego się nie spodziewałeś, patrz na listy, a nie na interfejs tunelu. Potwierdź wynik na drugim połączeniu po każdej zmianie, ponieważ jeden restart może ponownie użyć sesji z pamięci podręcznej.

Przechowuj wynegocjowany wynik w rejestrze wdrożenia obok wersji profilu. To jest fakt, który odpowiada na następne pytanie, który szyfr naprawdę chroni ruch.