Tunel zomiera po tom, čo notebook chvíľu leží nedotknutý, a vracia sa v momente, keď sa dotknete touchpadu. Tento vzorec ukazuje na to, že bezdrôtové spojenie prechádza do úspory energie, nie na to, že by brána VPN odmietala vaše prihlasovacie údaje. Nabité dopoludnie na tom istom profile je dôkaz: tunel prežíva, kým tečie prevádzka, a padá, len čo rádio stíchne. Prejdite kontroly nižšie po poradí, zastavte sa pri prvej, ktorá zlyhá, a až potom zmeňte jedno nastavenie.

Kontrola prvá: sleduje výpadok nečinnosť?

Začnite tým, že koreláciu preukážete, namiesto toho, aby ste ju predpokladali. Zapíšte čas posledného odoslaného paketu, čas, keď klient ohlásil pád tunela, a či sa medzitým vyplo zobrazenie. Ak je medzera vždy rovnaká, máte problém na ceste nečinnosti; ak výpadky prichádzajú náhodne počas aktívneho používania, prejdite na kontrolu piatu.

Lacný test, ktorého vrátenie nič nestojí: dvadsať minút posielajte na svoju bránu pravidelný ping s nízkou frekvenciou a nechajte stroj na pokoji. Ak tunel vydrží celý čas, neustála malá prevádzka symptóm skôr maskuje, než opravuje, čo je stále užitočný dôkaz. Výstup toho pingu držím v pomocnom termináli a potom ho porovnávam s klientskym záznamom, pretože dvoje hodín sa málokedy zhodne.

Kontrola druhá: je to len prevádzka VPN?

Predtým, než obviníte tunel, zistite, či je samotné spojenie ešte použiteľné. Kým je tunel mŕtvy, ale zobrazenie ešte zhasnuté, skúste dosiahnuť adresu prístupového bodu a verejného hostiteľa cez IP. Ak zlyhá aj obyčajný ping, rádio alebo prístupový bod vás zhodili a klient VPN je len divák.

Ak obyčajná prevádzka tečie, kým tunel mlčí, spojenie je zdravé a problém je vo vlastných časovačoch tunela alebo v tom, ako klient zvláda obnovenie. To sú dve rôzne opravy, takže tento krok nepreskakujte. Na notebooku s Wi-Fi aj Ethernetom odpojte kábel a zopakujte test nečinnosti: výpadok nečinnosti, ktorý na káblovom Ethernete zmizne, je silný dôkaz v prospech bezdrôtovej vrstvy.

Kontrola tretia: prečítajte stav úspory energie

Väčšina pracovných plôch vám dá zaškrtávacie políčko, ale políčko nie je stav, v ktorom sa nachádza ovládač. Najprv si prečítajte vlastnú správu ovládača, potom rozhodujte. Na Linuxe s mac80211 rozhranie odpovedá priamo:

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

Druhý príkaz je test, nie oprava. Neprežije odpojenie, spánok ani reštart, čo z neho robí čistý spôsob, ako hypotézu overiť bez zanechania trvalých zmien.

Na Windows powercfg /q SCHEME_CURRENT vypíše aktívnu schému a podstrom bezdrôtového adaptéra ukáže, či možno adaptéru prikázať úsporu energie; tá istá voľba je aj v Správcovi zariadení na karte správy napájania adaptéra. Na macOS vám úspora energie 802.11 pre jednotlivé rozhrania nie je sprístupnená, takže sa namiesto toho pozrite na pmset -g správanie spánku a pohotovostného režimu. Tam sa porucha zvyčajne ukáže ako cesta spánku a prebudenia, nie ako správanie rádia pri nečinnosti.

Kontrola štvrtá: zmeňte jednu vec a znova otestujte

Meňte presne jednu premennú na beh a opakujte rovnakú záťaž. Ak tunel teraz vydrží hodinu nečinnosti s vypnutou úsporou energie, naučili ste sa niečo skutočné. Ak stále padá, vráťte zmenu pred testovaním ďalšieho nápadu, inak skončíte s tromi prekrývajúcimi sa nastaveniami a bez tušenia, ktoré je dôležité.

Udržiavanie spojenia je druhá nezávislá premenná a neustále sa zamieňa s úsporou energie. WireGuardov PersistentKeepalive = 25 drží NAT záznam teplý;OpenVPN na oboch koncoch keepalive a ping-restart používa. Oba generujú prevádzku v inak tichom tuneli, takže udržiavanie spojenia, ktoré výpadok zdanlivo opravuje, môže skrývať problém rádia, namiesto toho aby ho riešilo. Testujte ich oddelene, jedno po druhom:

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

Kontrola piata: keď je rádio nevinné

Ak výpadky nečinnosti pretrvávajú s vypnutou úsporou energie a zapnutým udržiavaním spojenia, dívejte sa mimo notebooku. Prístupové body a domáce routery nechávajú vypršať NAT alebo relačné záznamy nečinnosti podľa vlastného plánu a server VPN môže zahodiť reláciu bez prevádzky.Roaming medzi prístupovými bodmi s rovnakým SSID môže tiež resetovať spojenie bez toho, aby to klient jasne povedal.

Potom to porovnajte s druhým zariadením v tej istej sieti, ktoré robí ten istý test nečinnosti. Dve zariadenia padajúce v rovnakom intervale sú príbeh cesty alebo servera; jedno padajúce zariadenie je lokálny príbeh ovládača alebo napájania. To porovnanie stojí desať minút a ušetrí vám prepisovanie nesprávnej konfigurácie.

Skôr než to urobíte trvalým

Rozhodnite sa, čo ste ochotní si nechať. Skript pre jednotlivé profily, ktorý vypína úsporu energie len v sieťach, kde ste výpadok videli, je obhájiteľný. Globálna úprava, ktorá vypne všetko za cenu výdrže batérie v každej sieti, zvyčajne nie.

  • Zapíšte pôvodnú hodnotu úspory energie vedľa skriptu, aby sa dala obnoviť.
  • Po každej aktualizácii ovládača alebo klienta zopakujte test nečinnosti; predvolené hodnoty sa menia.
  • Keď problém hlásite, držte ping log a klientsky log pohromade.
  • Ak druhý krok zlyhal, prestaňte meniť nastavenia VPN a berte to ako lokálnu poruchu spojenia.

Ak urobíte len jednu vec, urobte kontrolu druhú. Tá rozhoduje, či sa vás zvyšok tohto zoznamu vôbec týka, a je to krok, ktorý ľudia preskočia, keď už raz rozhodli, že odpoveďou je úspora energie.

Súvisiace články