VPN-Ofbréch am Idle behiewen: eng Checkliste fir d'WLAN-Energiespueren

Ären Tunnel stierft, nodeems den Laptop eng Zäit onberouert do stet, an hie kënnt zréck an deem Moment wou Dir den Touchpad beréiert. Dëst Muster weist drop hin, datt d'Funkverbindung an den Energiespuermodus geet, an net datt de VPN-Gateway Är Umeldungsdaten ofleent. En ofgelaangene Moien op dem selwechte Profil ass de Beweis: den Tunnel lieft soulaang Traffic fléisst a fält, soubal de Funk roueg gëtt. Gitt déi Kontrollen hei drënner an der Rei duerch, stoppt bei der éischter déi feelt, a ännert erscht duerno eng Astellung.

Kontroll eent: follegt de Fofall dem Idle?

Fänkt domat un, d'Korrelatioun ze beweisen amplaz se unzehuelen. Notéiert d'Äerzäit vum leschte Pak, deen Dir geschéckt hutt, d'Zäit wou de Client gemellt huet, datt den Tunnel erof ass, an ob de Bildschierm tëschentdeem ausgaang ass. Wann den Ofstand all Kéier deeselwechte ass, hutt Dir e Problem um Idle-Pad; wann d'Fofäll wärend aktiver Notzung zoufälleg geschéien, spréngt op d'Kontroll fënnef.

En bëllegen Test, deen näischt kascht fir zréckzehuelen: schéckt zwanzeg Minutte laang e gläichméissege Ping mat niddereger Rat op Äre Gateway an loosst d'Maschinn eleng. Wann den Tunnel déi ganzen Zäit hält, iwwerdeckt stännege klengen Traffic d'Symptom, amplaz et ze behiewen, wat nach ëmmer en nëtzlech Beweis ass. Ech halen dee Ping-Ausdrock an engem Brouillon-Terminal a vergläichen en duerno mam Client-Log, well déi zwou Aueren seelen iwwerenee kommen.

Kontroll zwee: ass et just VPN-Traffic?

Ier Dir den Tunnel beschëllegt, fannt eraus, ob d'Verbindung selwer nach brauchbar ass. Wärend den Tunnel dout ass, awer de Bildschierm nach aus, probéiert d'Adress vum Access Point an en ëffentlechen Host iwwer IP z'erreechen. Wann de gewéinleche Ping och feelt, huet de Funk oder den Access Point Iech fale gelooss, an de VPN-Client ass just Zouschauer.

Wann gewéinlechen Traffic fléisst, während den Tunnel schweigt, ass d'Verbindung gesond an de Problem sëtzt an den Timere vum Tunnel selwer oder doran, wéi de Client eng Fortsetzung behandelt. Dat sinn zwee verschidde Korrekturen, also spréngt dëse Schrëtt net. Op engem Laptop mat Wi-Fi an Ethernet gläichzäiteg zitt de Kabel eraus a widderhëlt den Idle-Test: en Idle-Fofall, deen op Kabel-Ethernet verschwënnt, ass e staarkt Beweis fir déi drahtlos Schicht.

Kontroll dräi: liest den Energiespuermodus

Déi meescht Desktoppe ginn Iech eng Këscht, awer d'Këscht ass net den Zoustand an deem den Treiber ass. Liest fir d'éischt de Bericht vum Treiber selwer, a entscheet dann. Ënner Linux mat mac80211 äntwert d'Interface direkt:

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

Déi zweet Kommando ass en Test, keng Korrektur. Si iwwerlieft weder eng Trennung nach Schlof oder Neistart, wat se zu engem proppere Wee mécht, d'Hypothees ze préiwen ouni permanent Ännerungen ze hannerloossen.

Ënner Windows powercfg /q SCHEME_CURRENT dréckt de aktive Schema, an den Ënnerbaum vum drahtlosen Adapter weist, ob dem Adapter ka gesot ginn Energie ze spueren; déiselwecht Wiel ass och am Device Manager op dem Adapter sengem Energieverwaltungstab. Ënner macOS gëtt Iech den 802.11-Energiespueren pro Interface net gewisen, also kuckt amplaz pmset -g op d'Schlof- an Standby-Verhalen. Do erweist sech de Feeler meeschtens als de Schlof- an Erweckungspad an net als Idle-Verhalen vum Funk.

Kontroll véier: ännert eng Saach, testet dann nach eng Kéier

Ännert pro Laf genee eng Variabel a widderhëlt déi selwecht Laascht. Wann den Tunnel elo eng Stonn Idle iwwersteet mam Energiespueren aus, hutt Dir eppes Richteges geléiert. Wann en nach ëmmer fällt, setzt d'Ännerung zréck ier Dir déi nächst Iddi test, soss bleift Dir mat dräi iwwerlappenden Astellungen a keng Ahnung wéi eng zielt.

De Verbindung liewen halen ass déi aner onofhängeg Variabel an et gëtt stänneg mam Energiespueren verwiesselt. De WireGuard PersistentKeepalive = 25 hält eng NAT-Mappung waarm;OpenVPN op béide Säiten keepalive an ping-restart benotzt. Béid generéieren Traffic op engem soss rouegen Tunnel, also kann e Liewen-Halen, dat de Fofall ze behiewen schéngt, e Funkproblem verstoppen amplaz et ze léisen. Test se getrennt, eng no der anerer:

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

Kontroll fënnef: wann de Funk onschoolleg ass

Wann Idle-Fofäll weiderbestinn mam Energiespueren aus an dem Liewen-Halen un, kuckt baussent dem Laptop. Access Points an Haus-Routere loossen Idle-NAT- oder Sessiouns-Andräg no hirem eegene Plang oflafen, an e VPN-Server kann eng Sessioun ouni Traffic fale loossen.Roaming tëschent Access Points déi eng eenzeg SSID deelen kann d'Verbindung och zrécksetzen, ouni datt de Client et kloer seet.

Vergläicht dann mat engem zweete Gerät am selwechten Netz, deen deeselwechten Idle-Test mécht. Zwee Geräter déi am selwechten Intervall falen sinn eng Geschicht iwwer Pad oder Server; ee Gerät dat fällt ass eng lokal Geschicht iwwer Treiber oder Energie. Dee Verglach kascht zéng Minutten a spuert Iech, déi falsch Konfiguratioun nei ze schreiwen.

Ier Dir et permanent maacht

Entscheet wat Dir bereet sidd ze behalen. E Skript pro Profil, dat den Energiespueren nëmmen op de Netzwierker auszitt wou Dir de Fofall gesinn hutt, ass verdeedegbar. Eng global Ännerung déi alles auszitt an déi een op all Netzwierk mat Batterieliewen bezilt, ass et meeschtens net.

• Schreift den ursprénglechen Energiespuerväert nieft d'Skript, sou datt en ka restauréiert ginn.
• Widderhëlt den Idle-Test no all Treiber- oder Client-Update; Standardwäerter änneren sech.
• Halt de Ping-Log an de Client-Log beieneen wann Dir de Problem mellt.
• Wann den zweete Schrëtt gefeelt huet, stoppt d'VPN-Astellunge z'änneren an behandelt et als lokale Verbindungsfeeler.

Wann Dir nëmmen eng Saach maacht, maacht d'Kontroll zwee. Si entscheet, ob de Rescht vun dëser Lëscht iwwerhaapt op Iech zoutrëfft, an et ass dee Schrëtt deen d'Leit iwwersprangen, nodeems se sech schonns entscheet hunn, datt d'Äntwert Energiespueren ass.