Řešení výpadků VPN při nečinnosti: kontrolní seznam pro úsporu energie Wi-Fi

Projděte výpadky VPN při nečinnosti popořadě: potvrďte časování, oddělte rádio od tunelu, přečtěte skutečný stav úspory energie, pak změňte jedno nastavení a znovu otestujte.

Tunel umírá poté, co notebook chvíli leží nedotčený, a vrací se ve chvíli, kdy se dotknete trackpadu. Tento vzorec ukazuje na bezdrátové spojení, které přechází do úspory energie, ne na to, že by brána VPN odmítala vaše přihlašovací údaje. Nabité dopoledne na stejném profilu je vodítko: tunel přežívá, dokud teče provoz, a padá, jakmile rádio ztichne. Projděte kontroly níže popořadě, zastavte se u první, která selže, a teprve pak změňte nastavení.

Kontrola první: sleduje výpadek nečinnost?

Začněte tím, že korelaci prokážete, místo abyste ji předpokládali. Zapište čas posledního odeslaného paketu, čas, kdy klient ohlásil pád tunelu, a zda se mezitím vypnul displej. Pokud je mezera pokaždé stejná, máte problém na cestě nečinnosti; pokud výpadky přicházejí náhodně během aktivního používání, přejděte ke kontrole páté.

Levný test, jehož vrácení nic nestojí: po dvacet minut posílejte na svou bránu pravidelný ping nízké frekvence a nechte stroj na pokoji. Pokud tunel vydrží celou dobu, neustálý malý provoz symptom spíš maskuje, než opravuje, což je pořád užitečný důkaz. Výstup toho pingu držím v pomocném terminálu a potom ho porovnávám s klientským záznamem, protože dvoje hodiny se málokdy shodnou.

Kontrola druhá: je to jen provoz VPN?

Než obviníte tunel, zjistěte, zda je samotné spojení ještě použitelné. Dokud je tunel mrtvý, ale displej ještě zhasnutý, zkuste dosáhnout adresy přístupového bodu a veřejného hostitele přes IP. Pokud selže i obyčejný ping, rádio nebo přístupový bod vás shodily a klient VPN je jen divák.

Pokud obyčejný provoz teče, zatímco tunel mlčí, spojení je zdravé a problém je ve vlastních časovačích tunelu nebo v tom, jak klient zvládá probuzení. To jsou dvě různé opravy, takže tento krok nepřeskakujte. Na notebooku s Wi-Fi i Ethernetem odpojte kabel a zopakujte test nečinnosti: výpadek nečinnosti, který na kabelovém Ethernetu zmizí, je silný důkaz pro bezdrátovou vrstvu.

Kontrola třetí: přečtěte stav úspory energie

Většina desktopů vám dá zaškrtávací políčko, ale políčko není stav, ve kterém se ovladač nachází. Nejprve si přečtěte vlastní zprávu ovladače, pak rozhodujte. Na Linuxu s mac80211 rozhraní odpovídá přímo:

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

Druhý příkaz je test, ne oprava. Nepřežije odpojení, spánek ani restart, což z něj dělá čistý způsob, jak hypotézu ověřit, aniž byste po sobě nechali trvalé změny.

Na Windows powercfg /q SCHEME_CURRENT vypíše aktivní schéma a podstrom bezdrátového adaptéru ukáže, zda lze adaptéru nařídit úsporu energie; stejná volba je i ve Správci zařízení na kartě správy napájení adaptéru. Na macOS vám úspora energie 802.11 pro jednotlivá rozhraní není zpřístupněna, takže se místo toho podívejte na pmset -g na chování spánku a pohotovostního režimu. Tam se závada obvykle ukáže na cestě spánku a probuzení, ne v chování rádia při nečinnosti.

Kontrola čtvrtá: změňte jednu věc a znovu otestujte

Měňte přesně jednu proměnnou na běh a opakujte stejnou zátěž. Pokud tunel teď vydrží hodinu nečinnosti s vypnutou úsporou energie, naučili jste se něco skutečného. Pokud stále padá, vraťte změnu zpět, než otestujete další nápad, jinak skončíte se třemi překrývajícími se nastaveními a bez tušení, které je důležité.

Udržování spojení je druhá nezávislá proměnná a neustále se plete s úsporou energie. WireGuardův PersistentKeepalive = 25 drží NAT záznam teplý;OpenVPN používá keepalive a ping-restart na obou koncích. Oba generují provoz v jinak tichém tunelu, takže udržování spojení, které výpadek zdánlivě opravuje, může skrývat problém rádia, místo aby ho řešilo. Testujte je odděleně, jedno po druhém:

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

Kontrola pátá: když je rádio nevinné

Pokud výpadky nečinnosti přetrvávají s vypnutou úsporou energie a zapnutým udržováním spojení, dívejte se mimo notebook. Přístupové body a domácí routery nechávají vypršet NAT nebo relační záznamy nečinnosti podle svého vlastního plánu a server VPN může zahodit relaci bez provozu.Roaming mezi přístupovými body se stejnou SSID může také resetovat spojení, aniž by to klient jasně řekl.

Potom to porovnejte s druhým zařízením ve stejné síti, které dělá stejný test nečinnosti. Dvě zařízení padající ve stejném intervalu jsou příběh cesty nebo serveru; jedno padající zařízení je lokální příběh ovladače nebo napájení. To srovnání stojí deset minut a ušetří vám přepisování špatné konfigurace.

Než to uděláte trvalým

Rozhodněte, co jste ochotni si nechat. Skript pro jednotlivé profily, který vypíná úsporu energie jen v sítích, kde jste výpadek viděli, je obhajitelný. Globální úprava, která vypne všechno za cenu výdrže baterie v každé síti, obvykle ne.

  • Zapište původní hodnotu úspory energie vedle skriptu, aby se dala obnovit.
  • Po každé aktualizaci ovladače nebo klienta zopakujte test nečinnosti; výchozí hodnoty se mění.
  • Když problém hlásíte, držte ping log a klientský log pohromadě.
  • Pokud druhý krok selhal, přestaňte měnit nastavení VPN a berte to jako místní závadu spojení.

Pokud uděláte jen jednu věc, udělejte kontrolu druhou. Ta rozhoduje, zda se vás zbytek seznamu vůbec týká, a je to krok, který lidé přeskočí, jakmile už jednou rozhodli, že odpovědí je úspora energie.

Související články