Устранение обрывов 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 поведение сна и ожидания. Там сбой обычно оказывается путём сна и пробуждения, а не поведением радио в простое.

Проверка четвёртая: измените одно, потом проверьте снова

Меняйте ровно одну переменную за прогон и повторяйте ту же нагрузку. Если туннель теперь выдерживает час простоя с выключенным энергосбережением, вы узнали что-то настоящее. Если он всё ещё падает, откатите изменение до проверки следующей идеи, иначе останетесь с тремя перекрывающимися настройками и без понятия, какая важна.

Поддержание соединения — вторая независимая переменная, и её постоянно путают с энергосбережением. Значение PersistentKeepalive = 25 в WireGuard держит отображение NAT тёплым;OpenVPN на обоих концах keepalive и ping-restart использует. Оба создают трафик в иначе молчащем туннеле, поэтому поддержание соединения, которое как будто устраняет обрыв, может скрывать проблему радио, а не решать её. Проверяйте их по отдельности, одну за другой:

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

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

Если обрывы простоя сохраняются при выключенном энергосбережении и включённом поддержании соединения, смотрите за пределами ноутбука. Точки доступа и домашние маршрутизаторы дают истечь записям NAT или сеанса простоя по собственному расписанию, а сервер VPN может сбросить сеанс без трафика.Роуминг между точками доступа с одним и тем же SSID тоже может сбросить канал, даже если клиент не говорит об этом ясно.

Затем сравните со вторым устройством в той же сети, которое делает тот же тест простоя. Два устройства, падающие через один интервал, — это история пути или сервера; одно падающее устройство — локальная история драйвера или питания. Это сравнение стоит десять минут и спасает вас от переписывания неверной конфигурации.

Прежде чем сделать это постоянным

Решите, что вы готовы оставить. Скрипт для профиля, который выключает энергосбережение только в сетях, где вы видели обрыв, оправдан. Глобальная правка, выключающая всё ценой времени работы батареи в каждой сети, обычно нет.

  • Запишите исходное значение энергосбережения рядом со скриптом, чтобы его можно было восстановить.
  • Повторяйте тест простоя после каждого обновления драйвера или клиента; значения по умолчанию меняются.
  • Держите журнал ping и журнал клиента вместе, когда сообщаете о проблеме.
  • Если второй шаг не удался, прекратите менять настройки VPN и считайте это локальной неисправностью канала.

Если вы делаете только одну вещь, сделайте вторую проверку. Именно она решает, относится ли к вам остальной список, и именно этот шаг люди пропускают, когда уже решили, что ответ — энергосбережение.

Похожие статьи