P_CONTROL_HARD_RESET_CLIENT_V2 w logu: czy to błąd?

Linia powtarza się co kilka sekund i wygląda jak przyczyna wszystkiego: pakiet o nazwie control hard reset, przychodzący od klienta, który nigdzie nie dociera. To nie jest błąd. To pierwsza wiadomość nowej sesji, a powtarzanie jest objawem czegoś innego, co zawodzi dalej. Oddzielenie tego, co mówi etykieta, od tego, co zrobiło połączenie, to cała diagnoza.

Opkod nazywa pozycję w protokole

OpenVPN multipleksuje kilka rodzajów pakietów na jednym gnieździe, a opkod mówi odbiorcy, który rodzaj trzyma. Pakiety hard-reset otwierają sesję, pakiety sterujące niosą materiał uzgadniania, potwierdzenia potwierdzają odbiór, a pakiety danych niosą ładunek tunelu. Odczyt pierwszego bajtu pokazuje, gdzie w tej wymianie należy pakiet, a definicje pakietów w kodzie źródłowym nazywają każdą rodzinę wprost.

To wszystko, co mówi. Pakiet oznaczony jako początkowy reset klienta dowodzi, że pakiet dotarł do twojego punktu obserwacji i że partner chce rozpocząć sesję. Nie dowodzi, że klient zaufał twojemu certyfikatowi, że jego dane logowania zostały przyjęte ani że kanał danych kiedykolwiek stał się użyteczny.

Przyrostek V2 to znacznik generacji protokołu dla tej rodziny pakietów, nie wersja produktu i nie ustawienie, które instalujesz. Nic w nazwie nie odnosi się do resetowania tunelu, restartu usługi ani czyszczenia pamięci podręcznej.

Co klient naprawdę robi w tej chwili

Klient otwiera identyfikator sesji, do którego obie strony dołączą dalszy ruch sterujący. Gdy ochrona kanału sterującego jest skonfigurowana, ten pierwszy pakiet już niesie HMAC, który pozwala odbiorcy zdecydować, czy warto angażować siły w resztę wymiany. Odbiorca, który nie może go zweryfikować, po cichu odrzuca pakiet, dlatego błędny klucz współdzielony wygląda jak klient mówiący w pustkę.

Nic widocznego dla użytkownika jeszcze się nie stało. Żaden certyfikat nie został zweryfikowany, żadna nazwa użytkownika nie została podana i żaden adres tunelu nie został przydzielony. Reset to wstęp do uzgadniania, więc każdy osąd połączenia w tym momencie jest przedwczesny.

W bezczynnej pętli ponownego łączenia interesującym szczegółem jest odstęp. Klient, który ponawia w stałym cyklu bez postępu, jest zwykle odrzucany, zanim zdoła ruszyć dalej, a przyczyna jest w logu partnera, nie w nazwie pakietu.

Gdzie kryje się prawdziwa awaria po resecie

Przeczytaj oba logi obok siebie i znajdź pierwsze zdarzenie, które nie jest resetem. Po stronie klienta niepowodzenie weryfikacji certyfikatu jest raportowane z konkretnym powodem: wygasły certyfikat, niezgodność nazwy lub nieznany wystawca. Po stronie serwera odrzucenie danych logowania jest raportowane jako niepowodzenie uwierzytelniania z własnym powodem. Oba są znacznie bardziej konkretne niż powtarzane spojrzenie serwera na nowe próby.

Dopasuj jedną próbę po znaczniku czasu, zamiast czytać każdy log osobno, ponieważ ta sama awaria pojawia się w obu miejscach z innym sformułowaniem i inną wagą. Partner, który się poddaje, zwykle podaje powód.

Jeśli żadna strona nie zgłasza odrzucenia, a wymiana nadal staje, granicą jest osiągalność, nie zaufanie. Zapora odrzucająca kierunek powrotny, urządzenie tłumaczące adresy sieciowe, którego mapowanie wygasa, lub problem z MTU, który zabija większe pakiety uzgadniania, wszystkie dają zatrzymaną wymianę bez żadnego błędu uwierzytelniania.

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

To wyszukiwanie nie jest samo w sobie diagnozą, ale przenosi cię ze słownika protokołu do rzeczywistej klasy awarii w jednym kroku.

Dlaczego wyłączanie weryfikacji to zły odruch

Gdy reset nadal się pojawia, najszybciej wyglądającym rozwiązaniem jest wyłączenie weryfikacji certyfikatów albo rezygnacja z ochrony kanału sterującego, żeby coś się połączyło. To zamienia awarię diagnozowalną na niediagnozowalną i zostawia wdrożenie przyjmujące partnerów, których odrzucanie było jego celem.

Zmień zamiast tego granicę, która naprawdę zawiodła. Problem zaufania należy do urzędu certyfikacji i profilu, który się na niego powołuje. Problem czasu należy do zegara. Problem danych logowania należy do backendu uwierzytelniania, który je odrzucił, a nieosiągalny partner należy do ścieżki między dwoma hostami.

Opkod jest przydatny w rozmowie ze wsparciem do jednej rzeczy: mówi, że partner zaszedł dość daleko, by spróbować. To, co stało się potem, jest tym, co musisz wiedzieć, i jest zapisane w tym logu, który odnotowuje pierwsze konkretne odrzucenie. Zacznij tam, a linia resetu przestaje wyglądać jak przyczyna i zaczyna wyglądać jak znacznik czasu.