VPN pada przy dużych wysyłkach: najpierw przeczytaj kolejkę

Tunel jest stabilny przez cały dzień, a potem pada za każdym razem, gdy zaczyna się duża wysyłka. Żądania interaktywne zatrzymują się pierwsze, klient zgłasza przekroczenie czasu, a połączenie wraca, gdy transfer się kończy. Ten wzorzec wskazuje na kolejkę i przetwarzanie, a nie na awarię zdalnego serwera, bo serwer nigdy nie dostał szansy odpowiedzieć na czas. Zadanie polega na odtworzeniu tego pod kontrolowanym obciążeniem i odczytaniu właściwych liczników.

Zmieniaj jedną zmienną na przebieg i trzymaj punkt końcowy na stałe.

Zbuduj powtarzalne porównanie obciążenia

Zapisz linię bazową, gdy łącze jest bezczynne: czas rundy, kilka żądań aplikacji i własny dziennik zdarzeń tunelu. Potem rozpocznij wysyłkę o znanym rozmiarze i powtórz dokładnie te pomiary, gdy trwa. Trzymaj punkt końcowy, klienta i cel testu bez zmian, bo zmiana dwóch z nich naraz niczego nie mówi.

Zauważ, które zdarzenie pojawia się pierwsze. Rosnący czas rundy przed jakimkolwiek błędem sugeruje kolejkę; twarde przekroczenie czasu przy stabilnym opóźnieniu sugeruje coś innego, na przykład rotację kluczy albo działanie na koncie. Oba wzorce prowadzą do innych kolejnych kroków. Zapisz obserwację, zanim cokolwiek zmienisz.

Zapisz wynik ze znacznikami czasu, aby przebieg pod obciążeniem i bezczynny można było porównać linia po linii.

Czytaj kolejkę, nie prędkość

Łącza konsumenckie buforują pakiety w sprzęcie dostawcy, a pełna kolejka wyjściowa opóźnia wszystko, także małe pakiety kontrolne, które utrzymują tunel przy życiu. Test prędkości pokazujący wysoką liczbę mówi niewiele o tym opóźnieniu, dlatego test w spoczynku przechodzi, a przeciążone łącze zawodzi.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

Porównaj liczby opóźnienia pod obciążeniem z tymi w spoczynku. Skok z dziesiątek milisekund do setek bez utraty pakietów to kolejka; utrata przy stabilnym opóźnieniu wskazuje na inną usterkę.

Sprawdź urządzenie i ścieżkę kontrolną

Szyfrowanie i przekazywanie kosztują czas procesora, a mały router lub dławiony termicznie laptop może gubić pakiety, gdy jest zajęty. Obserwuj całkowite obciążenie, a nie procent jednego procesu, bo przekazywanie w jądrze i obsługa przerwań nie pojawiają się tam, gdzie ludzie zwykle patrzą.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

Przekroczenie czasu po stronie klienta może też zbiec się z zaplanowaną rotacją kluczy albo ze zdarzeniem polityki sesji. Czytaj własny dziennik klienta pod kątem kolejności zdarzeń, a nie tylko komunikat błędu aplikacji.

Zmień jedną rzecz i powtórz

Gdzie platforma to wspiera, ogranicz szybkość wysyłania albo zaklasyfikuj ruch masowy poniżej interaktywnego, aby kolejka nigdy się nie zapełniła. Potem powtórz ten sam nakład pracy i porównaj te same trzy liczby co wcześniej. Zmiana, która poprawia test prędkości, ale zostawia przekroczenie czasu, niczego nie naprawiła.

Podnoszenie limitów czasu wszędzie i osłabianie szyfrowania to dwie zmiany, które usuwają objaw bez zidentyfikowania granicy, która zawiodła. Żadna z nich nie jest naprawą. Obie przenoszą awarię później, gdzie trudniej ją przypisać.

Zakończ, testując nowe żądanie i zachowanie ponownego połączenia, na którym użytkownik naprawdę polega. Stabilność pod obciążeniem, które wywołało skargę, to jedyny wynik wart zapisania.