Tunel umre, potem ko prenosnik nekaj časa stoji nedotaknjen, in se vrne v trenutku, ko se dotaknete sledilne ploščice. Ta vzorec kaže, da brezžična povezava prehaja v varčevanje z energijo, ne pa da VPN prehod zavrača vaše poverilnice. Zasedeno jutro na istem profilu je dokaz: tunel preživi, dokler teče promet, in pade, ko radio utihne. Pojdite skozi spodnje kontrole po vrsti, ustavite se pri prvi, ki ne uspe, in šele nato spremenite eno nastavitev.

Prva kontrola: ali prekinitev sledi mirovanju?

Začnite z dokazovanjem korelacije, ne s predpostavko. Zapišite stenski čas zadnjega poslanega paketa, čas, ko je odjemalec sporočil padec tunela, in ali se je zaslon medtem ugasnil. Če je vrzel vsakič enaka, imate težavo na poti mirovanja; če se prekinitve pojavljajo naključno med aktivno uporabo, pojdite na peto kontrolo.

Poceni preizkus, katerega razveljavitev nič ne stane: dvajset minut pošiljajte enakomeren ping z nizko frekvenco na svoj prehod in pustite stroj pri miru. Če tunel zdrži vso obdobje, stalni majhen promet simptom prikriva, namesto da bi ga odpravil, kar je še vedno koristen dokaz. Izpis tega pinga hranim v osnutkovem terminalu in ga pozneje primerjam z dnevnikom odjemalca, ker se dve uri redko ujemata.

Druga kontrola: ali gre samo za promet VPN?

Preden obtožite tunel, ugotovite, ali je povezava sama še uporabna. Medtem ko je tunel mrtev, zaslon pa še ugasnjen, poskusite doseči naslov dostopovne točke in javnega gostitelja prek IP. Če tudi običajni ping ne uspe, sta vas radio ali dostopovna točka spustila, odjemalec VPN pa je le opazovalec.

Če običajen promet teče, medtem ko tunel molči, je povezava zdrava in težava je v časovnikih samega tunela ali v tem, kako odjemalec obravnava nadaljevanje. To sta dve različni popravki, zato tega koraka ne preskočite. Na prenosniku z Wi-Fi in Ethernetom hkrati izvlecite kabel in ponovite preizkus mirovanja: prekinitev mirovanja, ki izgine na žičnem Ethernetu, je močan dokaz za brezžični sloj.

Tretja kontrola: preberite stanje varčevanja z energijo

Večina namizij vam ponudi potrditveno polje, a polje ni stanje, v katerem je gonilnik. Najprej preberite poročilo samega gonilnika, šele nato se odločite. V Linuxu z mac80211 vmesnik odgovori neposredno:

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

Drugi ukaz je preizkus, ne popravek. Ne preživi odklopa, spanja ali ponovnega zagona, kar ga naredi za čist način preverjanja hipoteze brez puščanja trajnih sprememb.

V Windows powercfg /q SCHEME_CURRENT izpiše aktivno shemo, poddrevo brezžičnega vmesnika pa pokaže, ali je vmesniku mogoče ukazati varčevanje z energijo; ista izbira je tudi v Upravitelju naprav na zavihku za upravljanje porabe vmesnika. V macOS varčevanje z energijo 802.11 za posamezni vmesnik ni razkrito, zato namesto tega poglejte pmset -g vedenje spanja in pripravljenosti. Tam se okvara običajno izkaže za pot spanja in prebujanja, ne za vedenje radia v mirovanju.

Četrta kontrola: spremenite eno stvar, nato znova preizkusite

Na vsak zagon spremenite natanko eno spremenljivko in ponovite isto obremenitev. Če tunel zdaj zdrži eno uro mirovanja z izklopljenim varčevanjem z energijo, ste se naučili nekaj resničnega. Če še vedno pada, spremembo povrnite pred preizkusom naslednje ideje, sicer vam ostanejo tri prekrivajoče se nastavitve in brez pojma, katera je pomembna.

Ohranjanje povezave žive je druga neodvisna spremenljivka in se nenehno zamenjuje z varčevanjem z energijo. WireGuardov PersistentKeepalive = 25 drži preslikavo NAT toplo;OpenVPN na obeh koncih keepalive in ping-restart uporablja. Oba ustvarjata promet v sicer tihem tunelu, zato lahko ohranjanje povezave, ki se zdi da odpravi prekinitev, skriva težavo radia, namesto da bi jo rešilo. Preizkusite ju ločeno, eno za drugim:

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

Peta kontrola: ko je radio nedolžen

Če se prekinitve mirovanja nadaljujejo z izklopljenim varčevanjem z energijo in vklopljenim ohranjanjem povezave, poglejte izven prenosnika. Dostopovne točke in domači usmerjevalniki pustijo, da vnosi NAT ali seje mirovanja potečejo po njihovem lastnem urniku, strežnik VPN pa lahko spusti sejo brez prometa.Gostovanje med dostopovnimi točkami, ki si delijo isti SSID, lahko prav tako ponastavi povezavo, ne da bi odjemalec to jasno povedal.

Nato primerjajte z drugo napravo v istem omrežju, ki izvaja isti preizkus mirovanja. Dve napravi, ki padeta v istem intervalu, sta zgodba o poti ali strežniku; ena naprava, ki pade, je lokalna zgodba o gonilniku ali napajanju. Ta primerjava stane deset minut in vas reši pred prepisovanjem napačne konfiguracije.

Preden to naredite trajno

Odločite se, kaj ste pripravljeni obdržati. Skript za posamezni profil, ki izklopi varčevanje z energijo le v omrežjih, kjer ste videli prekinitev, je zagovorljiv. Globalna prilagoditev, ki izklopi vse in je plačana z življenjsko dobo baterije v vsakem omrežju, običajno ni.

  • Zapišite prvotno vrednost varčevanja z energijo poleg skripta, da jo je mogoče obnoviti.
  • Ponovite preizkus mirovanja po vsaki posodobitvi gonilnika ali odjemalca; privzete vrednosti se spreminjajo.
  • Ko prijavite težavo, imejte dnevnik pinga in dnevnik odjemalca skupaj.
  • Če drugi korak ni uspel, prenehajte spreminjati nastavitve VPN in to obravnavajte kot lokalno okvaro povezave.

Če naredite samo eno stvar, naredite drugo kontrolo. Ta odloči, ali vas preostanek tega seznama sploh zadeva, in to je korak, ki ga ljudje preskočijo, ko so se že odločili, da je odgovor varčevanje z energijo.

Sorodni članki