Zarówno w konfiguracji serwera, jak i klienta ustawiłem:
cipher none
auth none
Zgodnie z tą radą używam również portu UDP 1195.
Po uruchomieniu serwera i klienta otrzymuję następujące ostrzeżenia:
Tue Dec 4 12:58:25 2018 ******* WARNING *******: '--cipher none' was specified. This means NO encryption will be performed and tunnelled data WILL be transmitted in clear text over the network! PLEASE DO RECONSIDER THIS SETTING!
Tue Dec 4 12:58:25 2018 ******* WARNING *******: '--auth none' was specified. This means no authentication will be performed on received packets, meaning you CANNOT trust that the data received by the remote side have NOT been manipulated. PLEASE DO RECONSIDER THIS SETTING!
... co jest dobre, ale wciąż openvpn używa szyfrowania. Wiem to, ponieważ:
1) Gdy klient łączy się, pojawia się następujący komunikat:
Tue Dec 4 12:59:59 2018 client_abc/10.20.73.2:36752 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Dec 4 12:59:59 2018 client_abc/10.20.73.2:36752 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2) Mam duże obciążenie procesora po obu stronach
3) Widzę w Wireshark, że dane są szyfrowane
Co jeszcze jest wymagane do wyłączenia szyfrowania?
Odpowiedzi:
Wygląda na to, że masz włączone Negocjowalne parametry kryptograficzne (NCP). Powinieneś określić
Kiedy dwie instancje OpenVPN mają włączoną obsługę NCP (domyślnie dla najnowszych wersji), będą negocjować, którego szyfru użyć z zestawu szyfrów zdefiniowanych przez ncp-szyfry. Domyślna wartość to „AES-256-GCM: AES-128-GCM”, która wyjaśnia, dlaczego widzisz AES-256-GCM w swoim połączeniu.
źródło
Zakładając, że używasz openvpn 2.4. Sądzę, że musisz także ustawić
ncp-disable
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
Niektóre tło:
Openvpn wymagało ręcznego konfigurowania algorytmu szyfrowania na tę samą wartość na obu końcach. To jednak stanowiło problem, bardzo utrudniło aktualizację szyfrowania w istniejącej sieci VPN dla wielu użytkowników. W 2016 r. Opracowano atak o nazwie „sweet32”, który w niektórych okolicznościach umożliwia odzyskanie zwykłego tekstu. W praktyce nie był to łatwy atak i istniał sposób na złagodzenie go bez zmiany szyfru, ale wciąż był to niepokojący rozwój.
Openvpn 2.4 wprowadził nową funkcję, domyślnie włączoną do negocjacji parametrów kryptograficznych. Nie jestem pewien, czy była to reakcja na sweet32, czy wynik ogólnych obaw o konsekwencje bycia skutecznie zamkniętym w jednym pakiecie szyfrów.
Tak więc po włączeniu negocjacji parametrów kryptograficznych ustawienie „szyfrowania” skutecznie działa jako rezerwowy, którego można użyć, jeśli druga strona połączenia nie obsługuje negocjacji.
źródło