Zawieszenie na dwie sekundy: VPN czy Wi-Fi?
Dwusekundowe zatrzymanie i nowa sesja VPN to dwa różne zdarzenia. Zanim zmienisz timer, umieść ścieżkę dostępu i tunel na osobnych osiach czasu.
Zawieszenie na dwie sekundy, które samo ustępuje, wygląda tak samo, niezależnie od tego, czy tunel ponownie wynegocjował połączenie, czy radio się zaciął. Możliwe też, że nic w ogóle nie padło, i tę możliwość warto sprawdzić najpierw. Krótki wybuch strat, ponowna negocjacja i zatrzymanie aplikacji odczuwane są przez osobę przy klawiaturze tak samo. Tylko jeden z trzech przypadków naprawia się przez zmianę konfiguracji tunelu.
Dwa zapisy, nie jeden
Zapisz, co stało się z połączeniem poniżej, a osobno, co zrobił sam tunel. Potem zestaw pauzę aplikacji z oboma zapisami. To niezależne serie zdarzeń, które czasem się pokrywają, a nazwanie wszystkich trzech rozłączeniem zakłada odpowiedź już na starcie.
Monitor sprawdzający raz na minutę nie może zobaczyć przerwy trwającej dwie sekundy. Zgłoszenie, że ten dzień był zdrowy, jest technicznie poprawne i praktycznie bezużyteczne. Umieść interwał próbkowania obok każdego cytowanego wyniku.
Co robiło łącze dostępowe, gdy aplikacja się zawiesiła
Interwał próbkowania i limit czasu określają, co monitor mógł w ogóle zaobserwować, więc zapisz oba obok wyniku. Zarejestrowany brak przerw niewiele znaczy, gdy instrument próbkuje co sześćdziesiąt sekund. Następnie sprawdź trzy miejsca ze znacznikami czasu: lokalny router, zatwierdzony host zewnętrzny osiągany zwykłą ścieżką i zasób za tunelem.
Najpierw potwierdź trasy, ponieważ cel publiczny sam może być routowany przez tunel i wtedy mierzy tunel, a nie ścieżkę dostępu. Dowody, które naprawdę datują przerwę, leżą warstwę niżej: zdarzenia łącza na routerze, zapisy resynchronizacji w modemie i zmieniony adres WAN. Kumulacyjny licznik błędów mówi, że coś poszło nie tak, ale nigdy kiedy. Skoreluj te zapisy z oknem incydentu, zamiast czytać je w izolacji.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showLicznik, który wzrósł wczoraj, niczego nie wyjaśnia w sprawie dzisiejszego zawieszenia. Ogranicz korelację do okna zgłoszonego przez użytkownika.
Poszukaj zapisu restartu
Utracony datagram UDP sam z siebie nie sprawia, że Community OpenVPN rozpoczyna nową negocjację TLS. Zachowanie restartu wynika z ping-restart, a obowiązująca wartość mogła zostać narzucona przez serwer; podręcznik dla 2.6 definiuje te timery. Dostarczanie urywa się na chwilę, próg nigdy nie zostaje przekroczony, a log pozostaje pusty. Dlatego w logu wokół pauzy szukaj linii restartu, nowego połączenia lub zmienionego identyfikatora sesji. Jeśli żaden z trzech elementów się nie pojawi, tunel prawdopodobnie nic nie zrobił, a timer nigdy nie był problemem.
Skracanie każdego keepalive sprawia, że wykrywanie wygląda szybciej, i przesuwa linię, na której drobne drgnięcie staje się ponownym połączeniem. Każde ponowne połączenie kosztuje jedną rundę uwierzytelniania i ponowną instalację tras. Rozciąganie timera nie kupuje niczego poza dłuższym oknem, w którym martwa ścieżka wciąż wygląda żywo. Oba są decyzjami strojenia z ceną, a nie darmowymi ulepszeniami.
Nieobecne zdarzenie też jest dowodem i właśnie ten rodzaj ludzie pomijają, bo nic w logu nie zwraca na nie uwagi. Zapisz wyszukiwanie, które wykonałeś, nie tylko jego wynik.
Niech porównanie zdecyduje, co naprawić
Gdy oba zapisy leżą obok siebie, przypisanie zwykle pisze się samo. Zdarzenie łącza routera na obu ścieżkach oznacza, że tematem jest połączenie dostępowe. Cichy tunel i użyteczna zwykła ścieżka oznaczają, że tematem jest negocjacja.
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
Każdy wiersz to trop, nie wyrok: punkty końcowe obniżają priorytet ICMP, a dwa cele niekoniecznie dzielą jedną ścieżkę. Utrzymuj zegary klienta, bramy i aplikacji zsynchronizowane, aby porównanie było w ogóle możliwe. Wiersz, który pasuje do dwóch kolumn, wymaga jeszcze jednej obserwacji, nie decyzji.
Raport, który przetrwa przegląd, odpowiada na cztery rzeczy: jak długo trwało zawieszenie, które ścieżki nadal odpowiadały, co tunel zapisał w tej sekundzie i jak często monitor próbkuje. Te cztery fakty pozwalają następnemu czytelnikowi odtworzyć obserwację, zamiast ufać streszczeniu. Procent dostępności ukrywa dokładnie ten interwał, na którym ci zależy, podobnie jak zdanie "VPN padł".