Поправка на прекини на VPN при мирување: контролна листа за штедење енергија на Wi-Fi

Поминете ги прекините на VPN при мирување по ред: потврдете го времето, одвојте го радиото од тунелот, прочитајте ја вистинската состојба на штедење енергија, потоа сменете едно поставување и тестирајте повторно.

Вашиот тунел умира откако лаптопот ќе остане извесно време недопрен, и се враќа во моментот кога ќе го допрете тачпадот. Овој образец укажува дека безжичната врска влегува во штедење енергија, а не дека VPN портата ги одбива вашите податоци за најава. Зафатено утро на истиот профил е доказот: тунелот живее додека тече сообраќај и паѓа штом радиото замолчи. Поминете ги проверките подолу по ред, застанете на првата што не успева и само тогаш сменете едно поставување.

Прва проверка: дали прекинот го следи мирувањето?

Започнете со докажување на корелацијата наместо со претпоставка. Запишете го ѕидниот часовник на последниот испратен пакет, времето кога клиентот пријавил дека тунелот паднал и дали екранот се исклучил во меѓувреме. Ако јазот е ист секој пат, имате проблем на патеката на мирување; ако прекините доаѓаат случајно за време на активна употреба, преминете на петтата проверка.

Евтин тест што не чини ништо да се врати: дваесет минути испраќајте рамномерен ping со низок ритам до вашата порта и оставете ја машината сама. Ако тунелот издржи цело време, постојаниот мал сообраќај го прикрива симптомот наместо да го поправа, што сепак е корисен доказ. Го држам тој излез од ping во терминл за белешки и потоа го споредувам со дневникот на клиентот, зашто двата часовници ретко се согласуваат.

Втора проверка: дали е само VPN сообраќај?

Пред да го обвините тунелот, откријте дали самата врска сѐ уште е употреблива. Додека тунелот е мртов, но екранот сѐ уште е исклучен, обидете се да ја достигнете адресата на пристапната точка и јавен домаќин преку IP. Ако и обичниот ping не успее, радиото или пристапната точка ве испуштиле, а VPN клиентот е само набљудувач.

Ако обичниот сообраќај тече додека тунелот молчи, врската е здрава и проблемот е во тајмерите на самиот тунел или во тоа како клиентот го обработува продолжувањето. Тоа се две различни поправки, затоа не го прескокнувајте овој чекор. На лаптоп со Wi-Fi и Ethernet истовремено, извлечете го кабелот и повторете го тестот на мирување: прекин при мирување што исчезнува на жичен Ethernet е силен доказ за безжичниот слој.

Трета проверка: прочитајте ја состојбата на штедење енергија

Повеќето работни површини ви даваат поле за штиклирање, но полето не е состојбата во која е драјверот. Прво прочитајте го сопствениот извештај на драјверот, потоа одлучете. На Linux со mac80211 интерфејсот одговара директно:

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

Втората наредба е тест, а не поправка. Таа не преживува исклучување, спиење или рестарт, што ја прави чист начин да се провери хипотезата без да се остават трајни промени.

На Windows powercfg /q SCHEME_CURRENT ја печати активната шема, а поддрвото на безжичниот адаптер покажува дали на адаптерот може да му се нареди да штеди енергија; истиот избор стои и во Device Manager на јазичето за управување со енергија на адаптерот. На macOS штедењето енергија 802.11 по интерфејс не ви се прикажува, затоа погледнете наместо тоа pmset -g за однесувањето при спиење и подготвеност. Таму дефектот обично излегува дека е патеката на спиење и будење, а не однесувањето при мирување на радиото.

Четврта проверка: сменете едно нешто, потоа тестирајте повторно

Сменете точно една променлива по извршување и повторете го истото оптоварување. Ако тунелот сега издржи еден час мирување со исклучено штедење енергија, научивте нешто вистинско. Ако сѐ уште паѓа, вратете ја промената пред да ја тестирате следната идеја, инаку ќе останете со три преклопени поставувања и без идеја кое е важно.

Одржувањето на врската жива е другата независна променлива и постојано се меша со штедењето енергија. WireGuard-овиот PersistentKeepalive = 25 држи NAT мапирање топло;OpenVPN на двата краја keepalive и ping-restart користи. Двете создаваат сообраќај на инаку тивок тунел, па одржувањето живо што навидум го поправа прекинот може да крие проблем со радиото наместо да го решава. Тестирајте ги одделно, едно по едно:

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

Петта проверка: кога радиото е невино

Ако прекините при мирување продолжат со исклучено штедење енергија и вклучено одржување живо, гледајте надвор од лаптопот. Пристапните точки и домашните рутери ги пуштаат да истечат NAT или сесиските записи при мирување по сопствен распоред, а VPN серверот може да отфрли сесија без сообраќај.Роамингот меѓу пристапни точки што делат ист SSID исто така може да ја ресетира врската, без клиентот тоа јасно да го каже.

Потоа споредете со втор уред на истата мрежа што го прави истиот тест на мирување. Два уреда што паѓаат во истиот интервал се приказна за патека или сервер; еден уред што паѓа е локална приказна за драјвер или енергија. Тоа споредување чини десет минути и ве спасува од препишување на погрешна конфигурација.

Пред да го направите трајно

Одлучете што сте подготвени да задржите. Скрипта по профил што го исклучува штедењето енергија само на мрежите каде што сте го виделе прекинот е одбранива. Глобално прилагодување што исклучува сѐ и се плаќа со траење на батеријата на секоја мрежа обично не е.

  • Запишете ја првобитната вредност на штедење енергија до скриптата за да може да се врати.
  • Повторете го тестот на мирување по секое ажурирање на драјвер или клиент; стандардните вредности се менуваат.
  • Држете го ping дневникот и дневникот на клиентот заедно кога го пријавувате проблемот.
  • Ако вториот чекор не успеа, престанете да менувате VPN поставувања и третирајте го како локален дефект на врската.

Ако правите само едно нешто, направете ја втората проверка. Таа одлучува дали остатокот од оваа листа воопшто се однесува на вас, и токму тој чекор луѓето го прескокнуваат откако веќе одлучиле дека одговорот е штедење енергија.

Поврзани статии