Jak OpenVPN data-ciphers wybiera szyfr kanału danych

Tunel wstaje, dziennik pokazuje szyfr, a przegląd profilu trwa dalej. Potem przychodzi aktualizacja u jednego partnera i ten sam profil zawodzi z komunikatem o braku wspólnego szyfru, co wysyła ludzi na poszukiwanie dyrektywy do usunięcia. Warto zrozumieć, że data-ciphers opisuje negocjację, a nie ustawienie. Jedna strona oferuje listę, druga wybiera z niej, a wynikiem jest jeden algorytm, który obie obsługują. Przeczytanie tej wymiany wyjaśnia większość takich awarii, zanim zmienisz jedną linię.

Dwa kanały, dwie konfiguracje

Jedna OpenVPN sesja ma kanał sterujący i kanał danych. Kanał sterujący prowadzi uścisk dłoni TLS, który uwierzytelnia partnerów i negocjuje klucze. Kanał danych szyfruje pakiety przenoszące Twój ruch.

data-ciphers konfiguruje ten drugi. Kanał sterujący ma własne opcje, a kontrole tożsamości profilu to trzecia, osobna sprawa. Zmiana jednego nie naprawia drugiego, dlatego profil może wyglądać poprawnie i mimo to zawodzić na konkretnym etapie.

Trzymaj te trzy w osobnych przegródkach, gdy czytasz plik konfiguracyjny.

Odczytaj negocjację z dziennika

Dziennik klienta podaje oba wyniki, gdy połączenie się udaje. Jedna linia opisuje kanał sterujący i jego szczegóły TLS, a inna wybrany szyfr kanału danych.

Przeczytaj obie, bo odpowiadają na różne pytania. Awaria kanału sterującego zatrzymuje połączenie, zanim jakikolwiek szyfr danych zacznie mieć znaczenie. Niezgodność kanału danych pojawia się po udanym uścisku dłoni, z komunikatem o braku wspólnego szyfru.

Następnie porównaj oferowane listy po obu stronach. Nazwa, której wersja jednego partnera lub jego zaplecze kryptograficzne nie dostarcza, nie może zostać wybrana, niezależnie od tego, jak wcześnie pojawia się na liście drugiego partnera.

Jak naprawdę przebiega wybór

Serwer wypycha swoją listę data-ciphers do klienta podczas uścisku dłoni, a klient wybiera pierwszy wpis na tej liście, który również obsługuje. Kolejność należy więc do konfiguracji serwera, a nie klienta.

Ten szczegół wyjaśnia pewną klasę mylących wyników. Zmiana kolejności listy klienta nic nie zmienia, dopóki decyduje lista serwera. Dodanie szyfru, którego klient nie może dostarczyć, też nic nie zmienia, bo klient musi móc użyć wybranego wpisu.

Nowsze wersje zmieniły listę domyślną i zmieniły nazwę opcji, która ją wcześniej przechowywała, więc dwaj różni partnerzy mogą się nie zgadzać, choć nikt nie edytuje profilu. Sprawdź wersję po każdej stronie, zanim uznasz to za literówkę.

Lista nie jest w abstrakcji rankingiem siły. To zbiór kandydatów, a wybrany jest pierwszym wzajemnie obsługiwanym wpisem w kolejności serwera. Dlatego dwie różnie wyglądające listy mogą wynegocjować ten sam szyfr. Dlatego też dwie identycznie wyglądające listy mogą zawieść.

Starsze strony potrzebują świadomej rezerwy

Partner, który w ogóle nie może negocjować, bo jest starszy od mechanizmu lub ma go wyłączonego, potrzebuje udokumentowanego układu zgodności. Opcja rezerwowa istnieje dokładnie dla tego przypadku i dotyczy partnerów, którzy nie biorą udziału w negocjacji.

To nie to samo, co włączenie każdego starego szyfru, żeby komunikat zniknął. Szeroka lista osłabia sesję dla każdego partnera, także tych, którzy wynegocjowaliby coś mocnego.

Skoordynuj obie strony, zamiast edytować niepowiązane nazwy algorytmów. Jeśli aktualizacja serwera usunęła starą opcję, poprawka należy do planu wersji, a nie do pośpiesznych działań u klienta.

Zachowaj weryfikację nietkniętą

Niezgodność kanału danych nie jest powodem, by akceptować niezweryfikowany serwer. Weryfikacja certyfikatu, oczekiwana nazwa serwera i ustawienia ochrony kanału sterującego są oddzielone od wyboru szyfru i powinny przetrwać każdą zmianę zgodności.

Zapisz razem wynegocjowany szyfr danych, wersję klienta i wersję serwera, aby następne porównanie zaczynało się od faktów, a nie od pliku profilu.

Po obsługiwanej poprawce przetestuj połączenie początkowe i ponowną negocjację, bo sesja, która powstaje raz, nadal może zawieść przy odnawianiu kluczy.

Jeśli tunel powstaje, a witryny nadal zawodzą, szyfr nie jest już podejrzanym. Kontynuuj z routingiem i DNS. Kolejność pracy: przeczytaj obie linie dziennika, porównaj obie listy, sprawdź wersje, dodaj rezerwę tylko partnerowi, który jej potrzebuje, a potem ponownie przetestuj ścieżkę odnawiania.