VPN ciągle się rozłącza? Przejdź przez to w tej kolejności

Zanim przeinstalujesz klienta, zapisz trzy rzeczy: jak długo tunel był aktywny, co klient powiedział przy rozłączeniu i czy maszyna w tym czasie spała albo zmieniła sieć. Ta notatka to jedyny dowód, jaki później będziesz mieć, a reinstalacja zwykle go usuwa. Rozłączenie w powtarzalnym interwale to timer albo wygaśnięcie stanu; rozłączenie w losowym momencie to problem ścieżki. Poniższa kolejność powstrzymuje cię przed zmianą trzech rzeczy naraz i brakiem wiedzy.

Krok pierwszy: zapisz interwał i treść błędu

Zacznij od własnego logu klienta, a nie od panelu dostawcy. W kliencie Linux log usługi oraz bieżący stan tunelu pokrywają większość:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Zapisz znaczniki czasu ostatniego udanego uzgadniania i moment, w którym ruch się zatrzymał, nie tylko moment zmiany koloru ikony. Klient GUI, który zgłasza rozłączenie po fakcie, może raportować stan, do którego jądro doszło kilka sekund wcześniej.

Zachowaj brzmienie błędu. Przekroczenie czasu, odrzucenie uwierzytelnienia i błąd adaptera lub sterownika wskazują na trzy różne warstwy, a większość zmarnowanego wysiłku w tym problemie wynika z traktowania ich jako jednej. Skopiuj wiersz dosłownie do notatki.

Krok drugi: zmień jedną zmienną, nie profil

Zostaw urządzenie i profil bez zmian i przenieś maszynę do innej sieci dostępu, na przykład hotspotu telefonu. To najtańszy test oddzielający klienta od ścieżki. Uruchom go wystarczająco długo, aby objąć pierwotny interwał awarii; dwie stabilne minuty niczego nie dowodzą w sprawie rozłączenia w trzydziestej minucie.

Laptop z portem Ethernet daje drugie porównanie, które całkowicie usuwa Wi-Fi z obrazu. Jeśli tunel utrzymuje się na obu wariantach, pierwotna sieć dostępu zasługuje na uwagę: roaming między punktami dostępowymi, domowy router z wygasającą tablicą translacji albo łącze nadrzędne resetujące długotrwałe przepływy.

Zapisz, którą zmienną zmieniłeś. Porównanie liczy się tylko wtedy, gdy wszystko inne pozostało takie samo, a to obejmuje punkt końcowy serwera i porę dnia.

Krok trzeci: przyporządkuj interwał do warstwy

Długość dobrej sesji to najbardziej informatywna pojedyncza liczba, jaką masz. Odczytaj ją względem tej listy, zanim dotkniesz timerów:

• Rozłączenie po uśpieniu lub wznowieniu: stan tunelu przetrwał wstrzymanie, ale interfejs nie. Sprawdź zachowanie ponownego łączenia klienta przy wznowieniu i to, czy usługa restartuje tunel, czy czeka na ruch.
• Rozłączenie tylko przy bezczynności: coś pośrodku pozwoliło przepływowi wygasnąć. Właśnie do tego przypadku istnieją keepalive.
• Rozłączenie przy stałym wieku sesji: zdarzenie ponownego uwierzytelnienia lub odnowienia klucza, a nie awaria ścieżki. Wyraźne odrzucenie w logu dokładnie w tym interwale jest sygnałem.
• Rozłączenie podczas dużych transferów lub dużych stron: podejrzewaj MTU i fragmentację, a nie timer bezczynności.

W przypadku bezczynności ustawienia zależą od protokołu i oba końce się liczą. keepalive 10 60 OpenVPN na serwerze wysyła ping co 10 sekund i restartuje połączenie po 60 sekundach bez niego; klienci WireGuard za NAT używają PersistentKeepalive = 25 w bloku peera. OpenVPN renegocjuje też kanał danych według timera, reneg-sec, który domyślnie wynosi 3600 sekund w 2.x.

Nie kopiuj agresywnych wartości z poradnika innego dostawcy. Krótki limit czasu na łączu mobilnym z utratami powoduje właśnie te rozłączenia, którym miał zapobiegać, a wartości przysłane przez serwer nadpisują to, co ustawisz w profilu klienta.

Krok czwarty: porównaj jedną obsługiwaną alternatywę

Jeśli operator publikuje zarówno profil UDP, jak i TCP, uruchom to samo urządzenie i sieć przeciwko drugiemu. Użyj faktycznie pasującego pliku, zamiast edytować transport w skopiowanym profilu. Stabilny profil TCP na ścieżce, na której UDP jest resetowany, zawęża problem do tej ścieżki; nie dowodzi, że TCP jest lepszym transportem wszędzie.

Ta sama logika dotyczy punktów końcowych. Wypróbuj inny serwer i trzymaj pierwotny wynik obok. Jeśli tylko jedno wyjście resetuje sesje, to dowód o tym punkcie końcowym, a nie powód do przebudowy każdego adaptera w laptopie.

Po każdej zmianie powtórz pierwotny wyzwalacz i potwierdź, dokąd ruch naprawdę trafia. Odzyskany dostęp do internetu to nie ten sam wynik co ruch wewnątrz tunelu, a klient, który po cichu wrócił na trasę bezpośrednią, wygląda zdrowo z przeglądarki.

Zweryfikuj poprawkę i zachowaj możliwość wycofania

Poprawkę weryfikuje się, odtwarzając pierwotny wyzwalacz, a nie udanym połączeniem. Zostaw tunel bezczynny dłużej niż stary interwał awarii, raz go wstrzymaj i wznów, a potem sprawdź wiek uzgadniania i adres wyjściowy:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Zachowaj poprzedni profil i poprzednie wartości timerów, dopóki nowe zachowanie nie przetrwa całego dnia pracy. Jeśli rozłączenia wrócą, przywróć kopię zapasową, a następnie stosuj zmiany jedna po drugiej, aby druga próba zaczynała się od znanego stanu.

Jeśli log pozostaje czysty, a tunel nadal rozłącza się w powtarzalnym interwale, następnym przystankiem jest strona serwera dla tej sesji. Zabierz identyfikator sesji klienta i dokładny czas rozłączenia, bo właśnie ta para czyni log serwera przeszukiwalnym. Opcje łącza protokołu są opisane w podręczniku OpenVPN 2.6 gdy potrzebujesz dokładnego znaczenia wartości.