VPN обривається, коли екран гасне: блокування, згасання чи сон?

Коли хтось каже, що VPN помер, коли екран потемнів, перше корисне питання — яка з трьох подій насправді сталася: сеанс заблокувався, панель вимкнулася чи вся машина пішла в сон. Це різні механізми на різних таймерах, і лише один із них може повністю завадити плануванню процесу. Пройдіть перевірки нижче по порядку. Зупиніться на першій, яка відповідає на питання, бо кожна наступна відповідає на щось інше.

Перша перевірка: відділіть блокування від згасання і від сну

Блокування змінює, кому дозволено користуватися сеансом; композитор продовжує малювати, мережевий стек продовжує працювати, а клієнт VPN нічого не помічає. Згасання екрана вимикає панель після періоду бездіяльності й залишає машину цілком бадьорою. Сон зупиняє процесори, тобто жоден процес у просторі користувача не планується, тому жодне підтримання з'єднання не спрацює, яким би коротким ви не задали інтервал.

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

Друга перевірка: зведіть події живлення та мережі на одну шкалу часу

Читайте журнал за обмежене вікно, а не за все завантаження, і включіть як менеджер входу, так і власника з'єднання:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

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

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

Третя перевірка: якщо машина заснула, вирішіть, чи так було задумано

Щойно перехід у сон з'являється на шкалі часу, питання змінюється з «чому VPN зламався» на «чи мала машина спати взагалі». На ноутбуці відповідь часто так, і обрив тунелю — очікувана поведінка, з якої клієнт має відновитися після пробудження. На робочій станції, яка має залишатися доступною, змінювати треба політику сну. Щоб вирішити, на яку з цих двох машин ви дивитеся, потрібне одне питання, і це не те питання, на яке журнал може відповісти за вас.

Змініть її через елементи керування, що належать сеансу входу, або через механізм, який підтримує адміністратор, якщо вимога стосується всієї машини. Редагування налаштування менеджера дисплея, коли ви ввійшли під іншим обліковим записом, — не та сама дія, і воно виглядатиме робочим до початку наступного сеансу. Повне вимкнення керування живленням — широка перша реакція, яка коштує часу роботи від батареї та приховує справжнє питання політики.

Четверта перевірка: якщо машина залишилася бадьорою, подивіться на мережу та клієнт

У бадьорої машини, що втратила тунель, є одна з трьох історій: мережа доступу впала, клієнт VPN зупинився або перезапустився, або бік сервера дав асоціації спливти, поки клієнт продовжував вважати, що з'єднаний. Порівняйте позначки часу події ланки з подією тунелю і будьте точними щодо того, яка була першою.

Потім перевірте шлях відновлення окремо від початкового сеансу. Новий запит через відновлений тунель може вдатися, поки довготривалий сеанс застосунку, відкритий до обриву, залишається зламаним, бо застосунок тримає застарілий сокет або адресу з кешу. Це проблема застосунку, а не доказ того, що тунель не повернувся.

Що містить корисний звіт

Запишіть послідовність із позначками часу та власниками: коли сеанс заблокувався, коли екран потемнів, чи було зафіксовано запит на сон, коли ланка впала й повернулася, коли тунель змінив стан і що насправді зробив застосунок. Кожен пункт має власника, тож кожен пункт можна передати потрібній людині замість того, щоб він став загальною скаргою на Linux.

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