Dlaczego Twoja VPN wraca do sprawności dłużej niż trwa awaria

Wi-Fi wróciło trzydzieści sekund temu, a VPN nadal nie działa, więc klient wygląda na zepsuty. Często po prostu realizuje własny harmonogram ponowień, a ten harmonogram nie wie, że sieć właśnie wróciła. Ta luka to cała historia: czas odzyskania to awaria plus każde oczekiwanie, na które klient już się zgodził. Skrócenie każdego licznika jest jedną odpowiedzią, a zrozumienie, który licznik ma znaczenie, drugą.

Trzy warunki decydują, czy dostrajanie pomoże: który etap jest wolny, czy błąd da się w ogóle powtórzyć i jak klient dowiaduje się, że sieć wróciła.

Trzy oczekiwania, które wyglądają jak jedno

Rozwiązywanie punktu końcowego, negocjacja IKE lub TLS, retransmisja pakietów i rozpoczęcie nowej próby to osobne zdarzenia z osobnymi licznikami. strongSwan dokumentuje odstęp retransmisji dla IKE, a OpenVPN ma własne sterowanie ponowieniami o innej semantyce. Skopiowanie liczby z jednego do drugiego zakłada, że mechanizmy są takie same, a nie są. Przeczytaj sekwencję logu, zanim zdecydujesz, na który interwał patrzysz.

Cicha minuta w logu nie oznacza wcale zamrożonego procesu. To może być wykładniczy backoff robiący dokładnie to, do czego go ustawiono.

Który etap jest naprawdę wolny?

Jeśli log pokazuje próby kończące się błędem uwierzytelniania, żadna zmiana licznika nie pomoże, bo dane logowania są błędne. Jeśli próby w ogóle nie są podejmowane, klient jest w swoim oknie oczekiwania i rozwiązaniem jest harmonogram. Jeśli próby są podejmowane i kończą się przekroczeniem czasu, problemem jest osiągalność lub brakujący nasłuch, a szybsze ponawianie tylko zapełnia log. Każdy z tych trzech stanów ma innego właściciela i tylko jeden z nich jest problemem z czasem.

Sklasyfikuj awarię, zanim dotkniesz liczby.

Kiedy skrócenie licznika pomaga, a kiedy nie

Obniż górny limit ponowień, gdy dominującym kosztem jest czekanie po krótkiej, częstej awarii, jak laptop przemieszczający się między punktami dostępowymi. Zostaw go w spokoju, gdy awarie są długie lub rzadkie, bo agresywne ponawianie dodaje obciążenie dokładnie w momencie, gdy koncentrator najmniej może odpowiedzieć. W obu przypadkach zmień jeden parametr, zapisz go i zmierz kolejne odzyskanie, zamiast zakładać, że się poprawiło.

Bardzo niski limit czasu skopiowany do każdego profilu to zwykły stan końcowy dostrajania bez pomiarów.

Sprawdź gotowość, zanim obwinisz klienta

Klient często nie widzi, że sieć jest użyteczna, dopóki coś tego nie spróbuje. Portal uwierzytelniający, odnowienie DHCP lub zmiana trasy mogą zostawić go czekającego według harmonogramu ustawionego przed tym wszystkim. Obserwuj zmianę stanu sieci systemu operacyjnego i następną próbę klienta na tym samym zegarze, a zobaczysz, czyje to oczekiwanie. Szybka wersja to zapisanie znacznika czasu zdarzenia sieci gotowej i znacznika czasu pierwszej próby po nim.

Potwierdź też, że bezpośredni ruch jest nadal blokowany podczas oczekiwania, bo szybsze ponowne połączenie, które przecieka ruch, nie jest poprawą.

Co zapisać

Zapisz, który licznik się zmienił, z jakiej wartości na jaką, i jak wyglądało potem odzyskanie. Zanotuj też wersję klienta, bo wartości domyślne zmieniają się między wydaniami, a nieudokumentowany bardzo niski limit czasu zdezorientuje następną osobę czytającą profil.

Ten zapis zamienia następną aktualizację oprogramowania w porównanie, a nie eksperyment.