VPN-uitval bij inactiviteit oplossen: een checklist voor Wi-Fi-energiebeheer

Je tunnel sterft nadat de laptop een tijdje onberoerd heeft gestaan, en hij komt terug op het moment dat je de trackpad aanraakt. Dat patroon wijst erop dat de draadloze verbinding in energiebesparing gaat, niet dat de VPN-gateway je inloggegevens weigert. Een drukke ochtend op hetzelfde profiel is het bewijs: de tunnel overleeft zolang er verkeer stroomt en valt weg zodra de radio stil wordt. Werk de controles hieronder op volgorde af, stop bij de eerste die mislukt, en wijzig pas daarna één instelling.

Controle één: volgt de uitval de inactiviteit?

Begin met het bewijzen van de correlatie in plaats van haar aan te nemen. Noteer de kloktijd van het laatste pakket dat je hebt verzonden, het tijdstip waarop de client meldde dat de tunnel neerlag, en of het scherm tussendoor uitging. Als de tussenpoos elke keer gelijk is, heb je een probleem op het inactiviteitspad; als de uitval tijdens actief gebruik willekeurig optreedt, ga dan naar controle vijf.

Een goedkope test die niets kost om ongedaan te maken: stuur twintig minuten lang een gelijkmatige ping met laag tempo naar je gateway en laat de machine met rust. Als de tunnel de hele tijd standhoudt, maskeert constant klein verkeer het symptoom in plaats van het te verhelpen, wat nog steeds bruikbaar bewijs is. Ik bewaar die ping-uitvoer in een kladterminal en vergelijk hem daarna met het clientlog, omdat de twee klokken zelden overeenkomen.

Controle twee: is het alleen VPN-verkeer?

Voordat je de tunnel de schuld geeft, zoek uit of de verbinding zelf nog bruikbaar is. Terwijl de tunnel dood is maar het scherm nog uit, probeer het adres van het toegangspunt en een publieke host via IP te bereiken. Als de gewone ping ook mislukt, hebben de radio of het toegangspunt je laten vallen en is de VPN-client slechts toeschouwer.

Als gewoon verkeer stroomt terwijl de tunnel zwijgt, is de verbinding gezond en zit het probleem in de timers van de tunnel zelf of in hoe de client een hervatting afhandelt. Dat zijn twee verschillende oplossingen, dus sla deze stap niet over. Op een laptop met zowel Wi-Fi als Ethernet trek je de kabel eruit en herhaal je de inactiviteitstest: uitval die op bekabeld Ethernet verdwijnt, is sterk bewijs voor de draadloze laag.

Controle drie: lees de energiebesparingstand

De meeste desktops geven je een selectievakje, maar het vakje is niet de toestand waarin de driver verkeert. Lees eerst het rapport van de driver zelf en beslis dan. Op Linux met mac80211 antwoordt de interface direct:

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

De tweede opdracht is een test, geen oplossing. Hij overleeft geen verbinding verbreken, slaap of herstart, wat hem een schone manier maakt om de hypothese te toetsen zonder blijvende wijzigingen achter te laten.

Op Windows powercfg /q SCHEME_CURRENT drukt het actieve schema af, en de subboom van de draadloze adapter laat zien of de adapter kan worden opgedragen energie te besparen; dezelfde keuze staat ook in Apparaatbeheer op het tabblad energiebeheer van de adapter. Op macOS wordt energiebesparing 802.11 per interface niet aan je getoond, dus kijk in plaats daarvan naar pmset -g voor slaap- en stand-bygedrag. Daar blijkt de storing meestal het slaap- en wekpad te zijn en niet het inactiviteitsgedrag van de radio.

Controle vier: wijzig één ding en test opnieuw

Wijzig per run precies één variabele en herhaal dezelfde belasting. Als de tunnel nu een uur inactiviteit doorstaat met energiebesparing uit, heb je iets echts geleerd. Als hij nog steeds wegvalt, draai de wijziging terug voordat je het volgende idee test, anders blijf je achter met drie overlappende instellingen en geen idee welke ertoe doet.

De verbinding in leven houden is de andere onafhankelijke variabele en wordt voortdurend verward met energiebesparing. WireGuards PersistentKeepalive = 25 houdt een NAT-mapping warm;OpenVPN gebruikt keepalive en ping-restart aan beide uiteinden. Beide genereren verkeer op een verder stille tunnel, dus een keepalive die de uitval lijkt te verhelpen kan een radioprobleem verbergen in plaats van oplossen. Test ze apart, één tegelijk:

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

Controle vijf: wanneer de radio onschuldig is

Als uitval bij inactiviteit aanhoudt met energiebesparing uit en keepalive aan, kijk dan buiten de laptop. Toegangspunten en thuisrouters laten NAT- of sessie-items bij inactiviteit volgens hun eigen schema verlopen, en een VPN-server kan een sessie zonder verkeer laten vallen.Roaming tussen toegangspunten die hetzelfde SSID delen kan de verbinding ook resetten zonder dat de client dat duidelijk zegt.

Vergelijk daarna met een tweede apparaat op hetzelfde netwerk dat dezelfde inactiviteitstest doet. Twee apparaten die met hetzelfde interval wegvallen zijn een verhaal over pad of server; één apparaat dat wegvalt is een lokaal verhaal over driver of energie. Die vergelijking kost tien minuten en bespaart je het herschrijven van de verkeerde configuratie.

Voordat je het permanent maakt

Bepaal wat je bereid bent te houden. Een script per profiel dat energiebesparing alleen uitschakelt op de netwerken waar je de uitval hebt gezien, is verdedigbaar. Een wereldwijde aanpassing die alles uitschakelt en met accuduur op elk netwerk wordt betaald, meestal niet.

• Noteer de oorspronkelijke energiebesparingswaarde naast het script zodat die hersteld kan worden.
• Herhaal de inactiviteitstest na elke driver- of clientupdate; standaardwaarden veranderen.
• Houd het ping-log en het clientlog bij elkaar wanneer je het probleem meldt.
• Als stap twee is mislukt, stop dan met het wijzigen van VPN-instellingen en behandel het als een lokaal verbindingsprobleem.

Als je maar één ding doet, doe dan controle twee. Die bepaalt of de rest van deze lijst überhaupt op jou van toepassing is, en dat is de stap die mensen overslaan zodra ze al hebben besloten dat het antwoord energiebesparing is.