VPN знікае, калі экран гасне: блакаванне, зацямненне ці сон?
Заблакаваная сесія, зацемнены экран і машына ў сне — гэта тры розныя падзеі. Звярніце іх з дапамогай journalctl, перш чым вінаваціць механізм падтрымання VPN.
Калі хтосьці кажа, што VPN памёр, калі экран пацямнеў, першае карыснае пытанне — якая з трох падзей адбылася насамрэч: сесія заблакавалася, панэль адключылася ці ўся машына заснула. Гэта асобныя механізмы на асобных таймерах, і толькі адзін з іх можа цалкам спыніць планаванне працэсу. Прайдзіце праверкі ніжэй па парадку. Спыніцеся на першай, якая адказвае на пытанне, бо кожная наступная адказвае на нешта іншае.
Праверка першая: аддзяліце блакаванне ад зацямнення і ад сну
Блакаванне змяняе, каму дазволена карыстацца сесіяй; кампазітар працягвае маляваць, сеткавы стек працягвае працаваць, а кліент VPN нічога не заўважае. Зацямненне экрана выключае панэль пасля перыяду бяздзеяння і пакідае машыну цалкам буднай. Сон спыняе працэсары, а значыць, ніводзін працэс прасторы карыстальніка не плануецца, таму ніякае падтрыманне не можа спрацаваць, якім бы кароткім вы ні зрабілі інтэрвал.
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
Менавіта таму «экран пацямнеў» — не дыягназ. Камп’ютар, настроены на зацямненне праз пяць хвілін і на сон праз трыццаць, пакажа цёмны экран на шостай хвіліне з цалкам здаровым тунэлем. Збой на трыццатай хвіліне — іншая падзея з іншым рашэннем, і абедзве выглядаюць аднолькава з другога канца пакоя.
Праверка другая: звядзіце падзеі сілкавання і сеткі на адну шкалу часу
Чытайце журнал за абмежаваны прамежак, а не за ўсё загружанне, і ўключыце як мэнэджар уваходу, так і ўладальніка злучэння:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --listПершая каманда паказвае запыты на сон, аднаўленне і пераходы сеткі, якія за імі ішлі. Другая паказвае, што цяпер трымае блакавальны замак, і гэта кажа вам, ці нешта наўмысна блакуе сон і якая гэта праграма. Папраўце назвы юнітаў, калі ўладальнік вашага злучэння — не NetworkManager, і памятайце, што чытанне юніта іншага карыстальніка або сістэмнага журнала залежыць ад лакальнай палітыкі.
Адсутная радок — не адмоўны вынік. Калі журнал выбранага юніта не бачны вашаму ўліковаму запісу, адсутнасць запісу пра сон нічога не даказвае, і выснова «яно ніколі не спала» з пустога фільтра — гэта тое, як людзі тыдзень наладжваюць падтрыманне.
Праверка трэцяя: калі яно заснула, вырашыце, ці так было задумана
Як толькі пераход у сон з’яўляецца на шкале часу, пытанне змяняецца з «чаму VPN зламаўся» на «ці павінна была машына спаць наогул». На ноўтбуку адказ часта так, і перапынак тунэля — чаканыя паводзіны, якія кліент павінен аднавіць пры абуджэнні. На працоўнай станцыі, якая павінна заставацца даступнай, змяняць трэба палітыку сну. Каб вызначыць, на якую з гэтых дзвюх машын вы глядзіце, патрэбна адно пытанне, і гэта не тое пытанне, на якое журнал можа адказаць за вас.
Змяніце яго праз сродкі кіравання, якія належаць увайшоўшай сесіі, або праз механізм, які падтрымлівае адміністратар, калі патрабаванне дзейнічае для ўсёй машыны. Рэдагаванне налады дыспетчара экрана, калі вы ўвайшлі пад іншым уліковым запісам, — не тое ж дзеянне, і яно будзе выглядаць як спрацавалае да пачатку наступнай сесіі. Поўнае адключэнне кіравання сілкаваннем — шырокая першая рэакцыя, якая каштуе часу працы ад батарэі і хавае сапраўднае пытанне палітыкі.
Праверка чацвёртая: калі яно засталося будным, паглядзіце на сетку і кліент
Будная машына, якая страціла тунэль, мае адну з трох гісторый: сетка доступу ўпала, кліент VPN спыніўся або перазапусціўся, або бок сервера скасаваў асацыяцыю, пакуль кліент працягваў верыць, што злучаны. Параўнайце адзнакі часу асноўнай падзеі звяна з падзеяй тунэля і дакладна вызначце, што было першым.
Затым праверце шлях аднаўлення асобна ад першапачатковай сесіі. Новы запыт праз адноўлены тунэль можа атрымацца, пакуль доўгатэрміновая сесія праграмы, адкрытая да перапынку, застаецца зламанай, бо праграма трымае састарэлы сокет або закешаваны адрас. Гэта праблема праграмы, а не доказ таго, што тунэль не вярнуўся.
Што ўтрымлівае карысная справаздача
Запішыце паслядоўнасць з адзнакамі часу і ўладальнікамі: калі сесія заблакавалася, калі экран пацямнеў, ці быў запісаны запыт на сон, калі звяно ўпала і вярнулася, калі тунэль змяніў стан і што праграма насамрэч зрабіла. Кожны пункт мае ўладальніка, таму кожны пункт можна перадаць патрэбнаму чалавеку замест таго, каб ён стаў агульнай скаргай на Linux.
Калі якога-небудзь з гэтых радкоў няма, гэта наступнае, што трэба вымераць, а не наступнае, што трэба змяніць. Шкала часу з прагалам больш інфарматыўная, чым змена налад па здагадцы.