Усунення обривів 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 і вважайте це локальною несправністю каналу.

Якщо ви робите лише одну річ, зробіть другу перевірку. Саме вона вирішує, чи стосується вас решта цього списку, і саме цей крок люди пропускають, коли вже вирішили, що відповідь — енергозбереження.

Схожі статті