Jo tunnel stjert nei't de laptop in skoft ûnoantaat stiet, en hy komt werom op it stuit dat jo it trackpad oanreitsje. Dat patroan wiist derop dat de draadleaze ferbining yn enerzjybesparring giet, net dat de VPN-gateway jo oanmeldgegevens ôfwiist. In drokke moarn op itselde profyl is it bewiis: de tunnel hâldt it út salang't ferkear rint en falt út as de radio stil wurdt. Wurkje de kontrôles hjirûnder op folchoarder ôf, stop by de earste dy't mislearret, en feroarje pas dêrnei ien ynstelling.

Kontrôle ien: folget de ûnderbrekking de stilte?

Begjin mei it bewizen fan it ferbân ynstee fan it oan te nimmen. Skriuw de muorrekloktiid op fan it lêste pakket dat jo stjoerd hawwe, de tiid dat de klant rapporteare dat de tunnel del wie, en oft it skerm der tuskenyn út gie. As de tuskenromte elke kear itselde is, hawwe jo in probleem op it paad fan 'e stilte; as de ûnderbrekkingen tafallich by aktyf gebrûk komme, spring dan nei kontrôle fiif.

In goedkeape test dy't neat kostet om werom te draaien: stjoer tweintich minuten lang in lykmjittige ping mei lege faasje nei jo gateway en lit de masine gewurde. As de tunnel de hiele tiid oanhâldt, masket oanhâldend lyts ferkear it symptoom ynstee fan it te ferhelpen, wat noch altyd nuttich bewiis is. Ik bewarje dy ping-útkomst yn in kladterminal en ferlykje dy letter mei it klantloch, want de beide klokken binne selden iens.

Kontrôle twa: is it allinnich VPN-ferkear?

Foardat jo de tunnel de skuld jouwe, sykje út oft de ferbining sels noch brûkber is. Wylst de tunnel dea is mar it skerm noch út, besykje it adres fan it tagongspunt en in iepenbiere host fia IP te berikken. As de gewoane ping ek mislearret, hawwe de radio of it tagongspunt jo falle litten en is de VPN-klant mar in taskôger.

As gewoan ferkear rint wylst de tunnel stil is, is de ferbining sûn en sit it probleem yn 'e eigen timers fan 'e tunnel of yn hoe't de klant in ferfanging behannelet. Dat binne twa ferskillende reparaasjes, dus slaan jo dizze stap net oer. Op in laptop mei sawol Wi-Fi as Ethernet lûke jo de kabel derút en werhelje de stiltetest: in stilte-ûnderbrekking dy't ferdwynt op bekabeld Ethernet is sterk bewiis foar de draadleaze laach.

Kontrôle trije: lês de enerzjybesparringstastân

De measte buroblêden jouwe jo in oanfinkfakje, mar it fakje is net de tastân dêr't de stjoerder yn is. Lês earst it eigen rapport fan 'e stjoerder en beslút dan. Op Linux mei mac80211 antwurdet de ynterface 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

It twadde kommando is in test, gjin reparaasje. It oerlibbet gjin ferbining ferbrekken, sliep of werstart, wat it in skjinne manier makket om de hypoteze te kontrolearjen sûnder bliuwende feroarings efter te litten.

Op Windows powercfg /q SCHEME_CURRENT printet it aktive skema, en de substruktuer fan 'e draadleaze adapter lit sjen oft de adapter sein wurde kin enerzjy te besparjen; deselde kar stiet ek yn Device Manager op it ljepblêd foar enerzjybehear fan 'e adapter. Op macOS wurdt de 802.11-enerzjybesparring per ynterface jo net toand, sjoch dan ynstee pmset -g foar sliep- en standbygedrach. Dêr docht de flater him meastentiids foar as it sliep- en wekpaad en net as it stiltengedrach fan 'e radio.

Kontrôle fjouwer: feroarje ien ding, test dan opnij

Feroarje per run krekt ien fariabele en werhelje deselde belesting. As de tunnel no in oere stilte oerlibbet mei enerzjybesparring út, hawwe jo wat echts leard. As er noch hieltiten falt, set de feroaring dan werom foardat jo it folgjende idee testen, oars bliuwe jo efter mei trije oerlaapjende ynstellingen en gjin idee hokker der ta docht.

It libben hâlden fan 'e ferbining is de oare ûnôfhinklike fariabele en it wurdt hieltyd mei enerzjybesparring betiizge. De PersistentKeepalive = 25 fan WireGuard hâldt in NAT-oermapping waarm;OpenVPN brûkt keepalive en ping-restart oan beide úteinen. Beide meitsje ferkear op in oars stille tunnel, sadat in libben-hâlden dat de ûnderbrekking liket te ferhelpen earder in radioprobleem ferberget as oplost. Test se apart, ien foar ien:

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

Kontrôle fiif: as de radio ûnskuldich is

As stilte-ûnderbrekkingen trochgeane mei enerzjybesparring út en libben-hâlden oan, sjoch dan bûten de laptop. Tagongspunten en thúsrouters litte stilsteande NAT- of sesje-ynfieringen neffens har eigen skema ferrinne, en in VPN-tsjinner kin in sesje sûnder ferkear falle litte.Roaming tusken tagongspunten dy't ien SSID diele kin de ferbining ek weromsette, sûnder dat de klant it dúdlik seit.

Ferlykje dan mei in twadde apparaat op itselde netwurk dat deselde stiltetest docht. Twa apparaten dy't op itselde skoft falle is in ferhaal oer paad of tsjinner; ien apparaat dat falt is in lokaal ferhaal oer stjoerder of enerzjy. Dy ferliking kostet tsien minuten en rêdt jo fan it oerskriuwen fan 'e ferkearde konfiguraasje.

Foardat jo it permanint meitsje

Beslis wat jo hâlde wolle. In skript per profyl dat enerzjybesparring allinnich útskeakelet op 'e netwurken dêr't jo de ûnderbrekking seagen is ferdigenber. In globale oanpassing dy't alles útskeakelet en mei batterijlibben op elk netwurk betelle wurdt, meastentiids net.

  • Skriuw de oarspronklike enerzjybesparringswearde njonken it skript, sadat dy werombrocht wurde kin.
  • Werhelje de stiltetest nei elke stjoerder- of klantfernijing; standertwearden feroarje.
  • Hâld it ping-loch en it klantloch byinoar as jo it probleem rapportearje.
  • As stap twa mislearre, stop dan mei it feroarjen fan VPN-ynstellingen en behannelje it as in lokale ferbiningsfout.

As jo mar ien ding dogge, doch dan kontrôle twa. Dy beslist oft de rest fan dizze list hielendal op jo fan tapassing is, en it is de stap dy't minsken oerslaan as se al besletten hawwe dat it antwurd enerzjybesparring is.

Relatearre artikelen