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. Он отправляет пакеты, чтобы держать сопоставление открытым; он не мешает машине заснуть и не может продолжать отправку, пока процесс приостановлен.

Запишите в заявке, что вы нашли: какая из трёх вещей была сломана, что её исправило и как вы это воспроизвели. Следующий человек, который в понедельник откроет крышку, будет вам благодарен, и ответ не придётся открывать заново с нуля.