AES-256-GCM nie znaleziono: możliwości klienta czy negocjacja?

Profil OpenVPN, który działa gdzie indziej, zgłasza, że nie znaleziono AES-256-GCM albo że strony nie mają wspólnego szyfru, a pierwszym odruchem jest edycja profilu. Te dwa komunikaty opisują różne awarie. Jeden mówi, że lokalny program nie ma takiego algorytmu; drugi, że obie strony mają algorytmy, ale nie mają wspólnego wyboru. Edycja profilu nie naprawia żadnego z nich, dopóki nie wiesz, który masz.

Przeczytaj dokładny tekst błędu i program, który go wygenerował.

Ustal, który błąd masz

Komunikat o nieznalezionym szyfrze pochodzi z analizy opcji na lokalnej maszynie, zanim zostanie wysłany jakikolwiek pakiet. Oznacza, że plik wykonywalny przed tobą lub biblioteka, z którą jest połączony, nie oferuje tego algorytmu. Komunikat o braku wspólnego szyfru przychodzi później, podczas negocjacji, i oznacza, że obie strony obsługują szyfry, ale nie mogą uzgodnić jednego.

Różnica ma znaczenie, bo jedno jest problemem wersji oprogramowania, a drugie problemem konfiguracji. Pierwsze rozstrzyga numer wersji. Drugie rozstrzyga porównanie dwóch list.

Lokalny brak możliwości

Stare kompilacje społecznościowe są starsze od współczesnych ustawień domyślnych, a aplikacja desktopowa może przynosić własny silnik, inny niż zainstalowany obok pakiet wiersza poleceń. Sprawdzenia wykonuj na pliku wykonywalnym, który naprawdę uruchomił połączenie, a potem wybierz wspieraną kompilację zamiast uczyć stary program nowego algorytmu.

openvpn --version
openvpn --show-ciphers | grep -i gcm
openvpn --show-tls | head -5

Jeśli AES-256-GCM nie pojawia się na tej liście, żadna linia profilu go nie doda. Rozwiązaniem jest nowszy klient lub inna kompilacja, a ograniczenia starszej strony stają się osobnym pytaniem projektowym.

W klientach opartych na OpenVPN 3 silnik i akceptowane dyrektywy różnią się od linii społecznościowej 2.x, więc ten sam tekst profilu może zawieść z powodów niemających nic wspólnego z listą szyfrów.

Luka w negocjacji

Gdy obie strony wymieniają algorytm, pozostaje pytanie, którą listę oferuje każda ze stron. Społecznościowy OpenVPN zmienił nazwę dyrektywy negocjacji: ncp-ciphers w 2.4 stało się data-ciphers w 2.5, a w 2.6 starsza linia cipher służy głównie zgodności i wycofaniu, a nie określaniu wynegocjowanego zestawu.

Dlatego zmiana tylko starej linii cipher może pozostawić listę negocjacji nietkniętą. Stara linia nadal ma znaczenie dla wycofania, a to osobne zadanie. Mieszanie obu daje zmiany, które w widoczny sposób nic nie zmieniają.

openvpn --version | head -2
grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn

Porównaj listy obu końców i komunikat odmowy serwera. Jeśli część wspólna jest pusta, wyrównaj listy świadomie, zamiast kopiować wartość z artykułu pisanego dla innej wersji. Zbyt szeroka lista po cichu osłabia każde połączenie. Zbyt wąska lista wyklucza stronę, którą chciałeś zachować.

Utrzymuj zgodność jawnie

Wycofanie dla jednej starej strony to decyzja z kosztem: całe wdrożenie akceptuje słabszą opcję, aby jedno urządzenie mogło się połączyć. Zapisz to jako takie i ogranicz do strony, która tego potrzebuje.

Wynik rozstrzygają dwa warunki. Jeśli błąd jest lokalny, wymień kompilację. Jeśli błąd dotyczy negocjacji, wyrównaj listy po obu stronach i zapisz, które wersje wspierasz.

Następnie zgłoś dokładny błąd z załączonym wyjściem wersji i możliwości. Ta para oddziela brakujący algorytm od nieporozumienia i zatrzymuje kolejną rundę spekulacyjnych zmian, zanim się zacznie.