Az alagút meghal, miután a laptop egy ideig érintetlenül áll, és abban a pillanatban visszatér, amikor megérinti az érintőpadot. Ez a minta arra utal, hogy a vezeték nélküli kapcsolat energiatakarékos módba lép, nem arra, hogy a VPN-átjáró elutasítja a hitelesítő adatait. Egy forgalmas reggel ugyanazon a profilon a bizonyíték: az alagút él, amíg a forgalom folyik, és kiesik, amint a rádió elhallgat. Járja végig az alábbi ellenőrzéseket sorrendben, álljon meg az elsőnél, amelyik elbukik, és csak utána módosítson egy beállítást.

Első ellenőrzés: követi a kiesés a tétlenséget?

Kezdje a korreláció bizonyításával a feltételezés helyett. Jegyezze fel az utolsó elküldött csomag falióra-idejét, azt az időpontot, amikor a kliens jelezte, hogy az alagút leállt, és hogy közben kikapcsolt-e a képernyő. Ha a rés minden alkalommal ugyanaz, a tétlenség útvonalán van a probléma; ha a kiesések aktív használat közben véletlenszerűen jönnek, ugorjon az ötödik ellenőrzésre.

Olcsó teszt, amelynek visszavonása semmibe sem kerül: húsz percen át küldjön egyenletes, alacsony frekvenciájú pinget az átjárójára, és hagyja magára a gépet. Ha az alagút végig kitart, az állandó kis forgalom elfedni látszik a tünetet ahelyett, hogy megszüntetné, ami így is hasznos bizonyíték. Ezt a ping-kimenetet egy piszkozatterminálban tartom, és utána összevetem a kliens naplójával, mert a két óra ritkán egyezik.

Második ellenőrzés: csak VPN-forgalom ez?

Mielőtt az alagutat okolná, derítse ki, hogy maga a kapcsolat még használható-e. Amíg az alagút halott, de a képernyő még ki van kapcsolva, próbálja elérni a hozzáférési pont címét és egy nyilvános gazdagépet IP-n keresztül. Ha a közönséges ping is elbukik, a rádió vagy a hozzáférési pont lerakta Önt, és a VPN-kliens csak szemlélő.

Ha a közönséges forgalom folyik, miközben az alagút hallgat, a kapcsolat egészséges, és a probléma az alagút saját időzítőiben vagy abban van, ahogyan a kliens a folytatást kezeli. Ez két különböző javítás, ezért ne hagyja ki ezt a lépést. Két csatlakozós, Wi-Fi és Ethernet gépen húzza ki a kábelt, és ismételje meg a tétlenségtesztet: a kábeles Etherneten eltűnő tétlenségi kiesés erős bizonyíték a vezeték nélküli réteg mellett.

Harmadik ellenőrzés: olvassa ki az energiatakarékossági állapotot

A legtöbb asztali környezet ad egy jelölőnégyzetet, de a négyzet nem az az állapot, amelyben az illesztőprogram van. Először az illesztőprogram saját jelentését olvassa el, aztán döntsön. A mac80211-et használó Linuxon az interfész közvetlenül válaszol:

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

A második parancs teszt, nem javítás. Nem éli túl a leválasztást, az alvást vagy az újraindítást, ami alkalmassá teszi arra, hogy tartós változtatások nélkül ellenőrizze a hipotézist.

Windowson powercfg /q SCHEME_CURRENT kiírja az aktív sémát, a vezeték nélküli adapter részfája pedig megmutatja, hogy utasítható-e az adapter energiatakarékosságra; ugyanez a választás a Device Managerben is megtalálható az adapter energiagazdálkodási lapján. macOS-en az interfészenkénti 802.11 energiatakarékosságot nem teszik elérhetővé Önnek, ezért nézze inkább pmset -g alvási és készenléti viselkedését. Ott a hiba általában az alvás és ébresztés útvonala, nem a rádió tétlenségi viselkedése.

Negyedik ellenőrzés: változtasson egy dolgot, majd teszteljen újra

Futásonként pontosan egy változót módosítson, és ismételje ugyanazt a terhelést. Ha az alagút most kibír egy óra tétlenséget kikapcsolt energiatakarékossággal, valami valósat tanult. Ha még mindig kiesik, lépjen vissza, mielőtt a következő ötletet teszteli, különben három átfedő beállítással marad, és fogalma sem lesz, melyik számít.

A kapcsolat életben tartása a másik független változó, és folyton összekeverik az energiatakarékossággal. A WireGuard PersistentKeepalive = 25 melegen tart egy NAT-leképezést;OpenVPN mindkét végén keepalive és ping-restart használ. Mindkettő forgalmat generál egy egyébként csendes alagúton, ezért az életben tartás, amely látszólag megszünteti a kiesést, inkább elrejthet egy rádióproblémát, mintsem megoldaná. Tesztelje őket külön, egyszerre egyet:

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

Ötödik ellenőrzés: amikor a rádió ártatlan

Ha a tétlenségi kiesések kikapcsolt energiatakarékosság és bekapcsolt életben tartás mellett is folytatódnak, nézzen a laptopon kívülre. A hozzáférési pontok és az otthoni routerek saját ütemtervük szerint járatják le a tétlen NAT- vagy munkamenet-bejegyzéseket, és a VPN-kiszolgáló eldobhat egy forgalom nélküli munkamenetet.Az azonos SSID-t megosztó hozzáférési pontok közötti barangolás szintén visszaállíthatja a kapcsolatot anélkül, hogy a kliens ezt világosan mondaná.

Ezután hasonlítsa össze egy második eszközzel ugyanazon a hálózaton, amely ugyanezt a tétlenségtesztet végzi. Két eszköz, amely ugyanabban az intervallumban esik ki, útvonal- vagy kiszolgálótörténet; egyetlen kieső eszköz helyi illesztőprogram- vagy energiátörténet. Ez az összehasonlítás tíz percet vesz igénybe, és megkíméli a rossz konfiguráció újraírásától.

Mielőtt véglegessé teszi

Döntse el, mit hajlandó megtartani. Profilonkénti szkript, amely csak azokon a hálózatokon kapcsolja ki az energiatakarékosságot, ahol látta a kiesést, védhető. Egy globális beállítás, amely mindent kikapcsol, és minden hálózaton az akkumulátor élettartamával fizet érte, általában nem az.

  • Jegyezze fel az eredeti energiatakarékossági értéket a szkript mellé, hogy visszaállítható legyen.
  • Minden illesztőprogram- vagy kliensfrissítés után ismételje meg a tétlenségtesztet; az alapértékek változnak.
  • Amikor jelenti a problémát, tartsa együtt a ping-naplót és a kliens naplóját.
  • Ha a második lépés elbukott, hagyja abba a VPN-beállítások módosítását, és kezelje helyi kapcsolathibaként.

Ha csak egy dolgot tesz, végezze el a második ellenőrzést. Ez dönti el, hogy a lista többi része egyáltalán vonatkozik-e Önre, és ezt a lépést hagyják ki az emberek, miután már eldöntötték, hogy a válasz az energiatakarékosság.

Kapcsolódó cikkek