Naprawianie zerwań VPN w czasie bezczynności: lista kontrolna oszczędzania energii Wi-Fi

Przejdź przez zerwania VPN w bezczynności po kolei: potwierdź czas, oddziel radio od tunelu, odczytaj rzeczywisty stan oszczędzania energii, następnie zmień jedno ustawienie i przetestuj ponownie.

Twój tunel pada, gdy laptop stoi przez chwilę nietknięty, i wraca w momencie, gdy dotkniesz touchpada. Ten wzorzec wskazuje, że łącze bezprzewodowe wchodzi w tryb oszczędzania energii, a nie że brama VPN odrzuca twoje dane logowania. Zajęty poranek na tym samym profilu jest dowodem: tunel żyje, dopóki płynie ruch, i pada, gdy radio cichnie. Przejdź przez poniższe kontrole po kolei, zatrzymaj się na pierwszej, która zawiedzie, i dopiero wtedy zmień jedno ustawienie.

Kontrola pierwsza: czy zerwanie idzie za bezczynnością?

Zacznij od udowodnienia korelacji, a nie od założenia jej. Zanotuj czas zegarowy ostatniego wysłanego pakietu, czas, w którym klient zgłosił spadek tunelu, oraz czy ekran wyłączył się w międzyczasie. Jeśli odstęp jest za każdym razem taki sam, masz problem na ścieżce bezczynności; jeśli zerwania zdarzają się losowo podczas aktywnego użytkowania, przejdź do kontroli piątej.

Tani test, którego wycofanie nic nie kosztuje: przez dwadzieścia minut wysyłaj równomierny ping o niskiej częstotliwości do swojej bramy i zostaw maszynę samą. Jeśli tunel wytrzyma cały czas, stały mały ruch maskuje objaw, zamiast go naprawiać, co wciąż jest przydatnym dowodem. Trzymam ten wynik pingu w terminalu roboczym i później porównuję go z logiem klienta, bo dwa zegary rzadko się zgadzają.

Kontrola druga: czy to tylko ruch VPN?

Zanim obwinisz tunel, sprawdź, czy samo łącze jest jeszcze użyteczne. Gdy tunel jest martwy, ale ekran nadal wyłączony, spróbuj dotrzeć do adresu punktu dostępowego i publicznego hosta po IP. Jeśli zwykły ping też zawodzi, radio lub punkt dostępowy cię rozłączyły, a klient VPN jest tylko widzem.

Jeśli zwykły ruch płynie, a tunel milczy, łącze jest zdrowe, a problem leży w timerach samego tunelu lub w tym, jak klient obsługuje wznowienie. To dwie różne naprawy, więc nie pomijaj tego kroku. Na laptopie z Wi-Fi i Ethernetem jednocześnie wyjmij kabel i powtórz test bezczynności: zerwanie bezczynności, które znika na kablowym Ethernecie, jest mocnym dowodem na rzecz warstwy bezprzewodowej.

Kontrola trzecia: odczytaj stan oszczędzania energii

Większość pulpitów daje ci pole wyboru, ale pole nie jest stanem, w którym znajduje się sterownik. Najpierw przeczytaj raport samego sterownika, potem decyduj. W Linuksie z mac80211 interfejs odpowiada wprost:

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

Drugie polecenie to test, a nie naprawa. Nie przetrwa rozłączenia, uśpienia ani restartu, co czyni je czystym sposobem sprawdzenia hipotezy bez pozostawiania trwałych zmian.

W Windows powercfg /q SCHEME_CURRENT wypisuje aktywny schemat, a poddrzewo karty bezprzewodowej pokazuje, czy karcie można nakazać oszczędzanie energii; ten sam wybór jest też w Menedżerze urządzeń na karcie zarządzania energią karty. W macOS oszczędzanie energii 802.11 dla każdego interfejsu nie jest ci udostępniane, więc zamiast tego spójrz na pmset -g zachowanie uśpienia i gotowości. Tam usterka zwykle okazuje się ścieżką uśpienia i wybudzania, a nie zachowaniem radia w bezczynności.

Kontrola czwarta: zmień jedną rzecz, potem przetestuj ponownie

Zmieniaj dokładnie jedną zmienną na przebieg i powtarzaj to samo obciążenie. Jeśli tunel wytrzyma teraz godzinę bezczynności przy wyłączonym oszczędzaniu energii, nauczyłeś się czegoś prawdziwego. Jeśli nadal pada, wycofaj zmianę przed testem następnego pomysłu, inaczej zostaniesz z trzema nakładającymi się ustawieniami i bez pojęcia, które ma znaczenie.

Utrzymywanie połączenia przy życiu to druga niezależna zmienna i jest ciągle mylona z oszczędzaniem energii. Wartość PersistentKeepalive = 25 WireGuarda utrzymuje mapowanie NAT w cieple;OpenVPN na obu końcach keepalive i ping-restart używa. Oba generują ruch w inaczej cichym tunelu, więc utrzymywanie przy życiu, które zdaje się naprawiać zerwanie, może ukrywać problem radia, a nie go rozwiązywać. Testuj je osobno, jedno po drugim:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

Kontrola piąta: gdy radio jest niewinne

Jeśli zerwania bezczynności utrzymują się przy wyłączonym oszczędzaniu energii i włączonym utrzymywaniu przy życiu, spójrz poza laptopa. Punkty dostępowe i domowe routery pozwalają wygasać wpisom NAT lub sesji bezczynności według własnego harmonogramu, a serwer VPN może zrzucić sesję bez ruchu.Roaming między punktami dostępowymi dzielącymi ten sam SSID również może zresetować łącze, choć klient tego wyraźnie nie mówi.

Potem porównaj z drugim urządzeniem w tej samej sieci, które robi ten sam test bezczynności. Dwa urządzenia padające w tym samym odstępie to historia ścieżki lub serwera; jedno padające urządzenie to lokalna historia sterownika lub zasilania. To porównanie kosztuje dziesięć minut i ratuje cię przed przepisywaniem złej konfiguracji.

Zanim zrobisz to na stałe

Zdecyduj, co jesteś gotów zatrzymać. Skrypt dla profilu, który wyłącza oszczędzanie energii tylko w sieciach, w których widziałeś zerwanie, jest obronny. Globalna zmiana wyłączająca wszystko, opłacona czasem pracy baterii w każdej sieci, zwykle nie jest.

  • Zapisz pierwotną wartość oszczędzania energii obok skryptu, aby można ją było przywrócić.
  • Powtarzaj test bezczynności po każdej aktualizacji sterownika lub klienta; wartości domyślne się zmieniają.
  • Trzymaj log pingu i log klienta razem, gdy zgłaszasz problem.
  • Jeśli drugi krok zawiódł, przestań zmieniać ustawienia VPN i potraktuj to jako lokalną usterkę łącza.

Jeśli zrobisz tylko jedną rzecz, zrób kontrolę drugą. To ona decyduje, czy reszta tej listy w ogóle cię dotyczy, i to jest krok, który ludzie pomijają, gdy już zdecydowali, że odpowiedzią jest oszczędzanie energii.

Powiązane artykuły