VPN мертвий після сну: тунель втрачено чи застосунок застарів?

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

Після пробудження можуть зламатися три речі

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

Другий — активація. Багато клієнтів перепідключаються самі; деякі ні, і профіль, який ніхто не просить повернутися, просто стоїть і виглядає налаштованим. Ця відмова тиха за задумом, бо ніщо не повідомило про помилку.

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

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

Перше: чи повернувся тунель?

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

ip -brief addr show
wg show
ip route show table all | head -20

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

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

Друге: чи просив хтось його повернутися?

Саме тут порівняння виправдовує себе. Профіль плагіна OpenVPN і власне підключення WireGuard обробляються NetworkManager по-різному, і довідка з налаштувань підключення прямо каже, що connection.autoconnect не активує профілі VPN; механізм підняття VPN разом із підключенням — це connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

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

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

Третє: чи тримає застосунок старий стан?

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

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

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

Зробіть порівняння відтворюваним

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

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

Постійний keepalive WireGuard входить у цю картину лише як keepalive зіставлення NAT. Він надсилає пакети, щоб тримати зіставлення відкритим; він не заважає машині заснути й не може продовжувати надсилання, доки процес призупинено.

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