Sześćdziesięciosekundowy limit czasu TLS: która strona naprawdę się zatrzymała?

Klient poddaje się po sześćdziesięciu sekundach z komunikatem o negocjacji kluczy, a laptop nie ma zdania na temat przyczyny. To zdanie opisuje cierpliwość klienta, nie zachowanie serwera. Powodują je trzy zupełnie różne sytuacje: pakiet nigdy nie dotarł do właściwej usługi, usługa odrzuciła go, zanim cokolwiek zalogowała, albo usługa go odrzuciła i powiedziała o tym gdzieś, gdzie klient tego nie widzi. Właśnie skorelowanie jednej próby na obu końcach je rozdziela.

Nadaj jednej próbie tożsamość, której możesz szukać

Zapisz godzinę rozpoczęcia wraz ze strefą czasową, nazwę profilu, cel, który klient faktycznie rozwiązał, port oraz to, czy połączenie jest UDP czy TCP. Jeśli profil zawiera kilka zdalnych wpisów, zanotuj, który wybrała ta próba, ponieważ ponowna próba mogła przejść do następnego wpisu bez zmiany pliku, który czytasz.

Weź punkt końcowy z aktywnego dziennika, a nie z pobrania, które pamiętasz. Profil wskazujący na adres prywatny jest całkowicie poprawny i całkowicie bezużyteczny z sieci, która nie potrafi tam routować, a ten przypadek wygląda identycznie jak wyłączony serwer.

Następnie poproś operatora o to samo okno na docelowej instancji. Różnica zegarów jest wystarczająco częsta, że przesunięcie o kilka minut może sprawić, iż pasujące zdarzenie będzie wyglądać na nieobecne, więc zapisz przesunięcie, zamiast wnioskować, że zdarzenia nie było.

Cztery obserwacje, cztery różne następne kroki

To, co serwer rejestruje, decyduje o gałęzi. Brak jakiejkolwiek próby wskazuje na adresowanie, transport lub ścieżkę do usługi. Przychodzące pakiety, które znikają przed zwykłą wymianą, wskazują na wymagania kanału kontrolnego rzeczywistej usługi. Nazwane odrzucenie wskazuje na obiekt, który nazywa. Odpowiedzi, które opuszczają serwer, ale nigdy nie docierają do klienta, wskazują na ścieżkę powrotną.

Pusty dziennik aplikacji jest słabszym dowodem, niż wygląda. Logowanie zaczyna się w pewnym punkcie wymiany, a pakiety odrzucone przed tym punktem nie zostawiają śladu w pliku, który czytasz. Tam, gdzie jest to dozwolone, operator może użyć obserwacji usługi i sieci, aby sprawdzić, czy cokolwiek dotarło.

Trzymaj cztery wyniki osobno w notatkach. Pokusa jest scalenie ich w „serwer nie odpowiada”, a to właśnie to zdanie wysyła ludzi do zmiany szyfrów, gdy prawdziwym problemem jest reguła zapory. Notatka, która zapisuje tylko słowo limit czasu, wyrzuciła rozróżnienie, za które właśnie zapłaciłeś.

Napraw etap, który nazywa dowód

Ukończone połączenie TCP dowodzi tylko, że coś przyjęło gniazdo. Nie dowodzi, że nasłuchującym jest skonfigurowana przez ciebie usługa OpenVPN, a serwer WWW pod tą samą nazwą hosta doskonale odpowiada przeglądarce, choć jest nieistotny dla tunelu.

Jeśli serwer zgłasza wygasłą listę unieważnień, to znacznie bardziej konkretny fakt niż ostateczny limit czasu klienta, a poprawka należy do organu certyfikacji, nie do sieci. Jeśli oba końce nie zgadzają się co do ochrony kanału kontrolnego lub wspólnego materiału, zresetowanie hasła niczego nie zmienia, ponieważ odrzucenie następuje przed sprawdzeniem jakiegokolwiek poświadczenia.

Zmień jedną rzecz, którą dowody naprawdę potwierdzają, a następnie powtórz ten sam profil wobec tego samego punktu końcowego. Zachowaj pierwsze nowe zdarzenie, jeśli połączenie pójdzie dalej, ponieważ to zdarzenie jest kolejnym etapem dochodzenia, a nie nowym problemem.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

Co naprawdę zmienia wydłużenie okna

Sześćdziesiąt sekund to okno uścisku dłoni klienta, a społecznościowe odniesienie klienta dokumentuje opcję, która je reguluje. Podniesienie go sprawia, że klient czeka dłużej, zanim się podda. Nie sprawia, że nieobecna usługa się pojawi, i nie czyni odrzuconego pakietu akceptowalnym.

Dłuższe okno ma uzasadnione zastosowanie na wolnym łączu lub mocno obciążonym serwerze i warto je wypróbować, gdy masz dowody, że wymiana postępuje wolno, a nie że w ogóle nie zachodzi. Wypróbowanie go najpierw tylko opóźnia tę samą diagnozę o kolejną minutę i utrudnia czytanie osi czasu. Jeśli oś czasu pokazuje wymianę, która postępuje, a potem się zatrzymuje, okno jest objawem obciążenia, a nie osiągalności.