OpenVPN: uzgadnianie TLS nie powiodło się – na której gałęzi jesteś?

Wiersz mówiący, że uzgadnianie TLS nie powiodło się, jest końcem historii, a nie jej początkiem. Liczy się zdarzenie bezpośrednio przed nim, bo ono nazywa, który z czterech bardzo różnych błędów masz. Limit czasu, niezgodność kanału sterującego, odrzucenie certyfikatu i błąd po negocjacji dają ten sam nagłówek. Wybierz gałąź na podstawie dowodów, a poprawka przestanie być domysłem.

Przeczytaj ostatnie zdarzenie przed błędem

Przewiń w górę zamiast czytać ostatni wiersz. Zdarzenie przed rozłączeniem zwykle nazywa etap: brak odpowiedzi, błąd podczas wymiany pakietów sterujących, wynik weryfikacji albo udana negocjacja, po której następuje wynik uwierzytelnienia. Każde z nich należy do innego właściciela. Ten jeden wiersz decyduje, która sekcja poniżej ma zastosowanie.

Zapisz tekst błędu wraz z wersją klienta, punktem końcowym i transportem. Klucze, hasła i nieocenzurowane profile trzymaj poza wszystkim, co publikujesz.

Dokładny pierwszy błąd jest wart więcej niż długi wyciąg z logu. Nazywa etap, a etap nazywa właściciela.

Gałąź pierwsza: nic nie wróciło

Jeśli klient wysłał swój pierwszy pakiet i nie otrzymał nic użytecznego, problem leży na ścieżce lub po stronie nasłuchu. Potwierdź, że profil odpowiada opcji, którą operator naprawdę oferuje: adres, port i UDP lub TCP. Następnie sprawdź, czy punkt końcowy jest w ogóle osiągalny z tej sieci. Zanotuj, która z tych dwóch kontroli zawiodła, zanim przejdziesz dalej.

Przeglądarka ładująca stronę pod tą samą nazwą hosta dowodzi tylko, że odpowiedziała usługa sieciowa. Nawet zaakceptowane połączenie TCP nic nie mówi o tym, czy OpenVPN zakończył negocjację.

Jeśli profil działa w innej zaufanej sieci, zachowaj to porównanie. Lokalizuje ono ograniczenie na ścieżce lub na pośredniku.

Gałąź druga: kanał sterujący się nie zgadza

Gdy wymiana się zaczyna, a potem zatrzymuje, pierwszym podejrzanym są ustawienia kanału sterującego. tls-auth i tls-crypt muszą odpowiadać wdrożeniu, a materiał z innego serwera nie da użytecznej wymiany. Ten błąd występuje przed jakimkolwiek logowaniem do konta. Profil skopiowany ze starszego serwera jest zwykłym źródłem.

Reset hasła nie zastępuje tych ustawień, a pożyczanie klucza z innej usługi nie jest poprawką zgodności. Uzyskaj profil przez zweryfikowany kanał operatora i zapisz oczekiwaną wersję klienta.

Zapisz konkretny błąd negocjacji, zamiast włączać stos starszych algorytmów, żeby zobaczyć, co się utrzyma. To przechwycony tekst błędu pozwala operatorowi sprawdzić swoją stronę.

Gałąź trzecia: certyfikat został odrzucony

Wyraźny błąd weryfikacji nazywa certyfikat, którego nie lubi. Sprawdź najpierw zegar urządzenia, potem przeczytaj, który obiekt zawiódł: certyfikat serwera, certyfikat klienta albo wystawca w łańcuchu. Wygaśnięcie, niezaufany wystawca i nieoczekiwana tożsamość to trzy różne komunikaty.

Trzymaj weryfikację włączoną, dopóki nie zdobędziesz poprawionego materiału. Zaakceptowanie niepowiązanego certyfikatu usuwa błąd, nie dowodząc, że dotarłeś do zamierzonego serwera.

Zanotuj, czy błąd podąża za siecią, czy za profilem. Błąd certyfikatu pojawiający się wszędzie nie jest problemem ścieżki.

Gałąź czwarta: negocjacja się skończyła i coś innego zawiodło

Gdy wymiana tożsamości się powiedzie, pozostały błąd należy do uwierzytelnienia lub routingu. Wyraźne odrzucenie konta to kwestia uwierzytelnienia, a podłączony tunel z nieosiągalnymi stronami to kwestia routingu lub DNS. Dalsze podmienianie opcji TLS w tym momencie psuje etap, który już działał.

Zgłaszając problem, powiedz, czy zawodzi każda sieć, czy działa inny profil i czy serwer odnotował próbę. Cisza po stronie serwera i odmowa z jego strony stoją na różnych granicach.