Отстраняване на прекъсвания на 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 настройки и приемете това като местна повреда на връзката.

Ако направите само едно нещо, направете втора проверка. Тя решава дали останалата част от списъка изобщо се отнася за вас, и точно тази стъпка хората прескачат, след като вече са решили, че отговорът е енергоспестяване.

Подобни статии