Выпраўленне абрываў 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 і лічыце гэта лакальным збоем канала.

Калі вы зробіце толькі адну рэч, зрабіце другую праверку. Яна вырашае, ці тычыцца вас увогуле астатні спіс, і менавіта гэты крок людзі прапускаюць, калі ўжо вырашылі, што адказ — энергазберажэнне.

Падобныя артыкулы