Приложение VPN упало: аварийный выключатель ещё включён?

Начните там, где начинает пользователь: окно клиента исчезло, значок в лотке пропал, а браузер либо загружает, либо нет. Одно это наблюдение не скажет, пережила ли блокировка. Ответ зависит от того, какой компонент держит правила, умер ли этот компонент вместе с окном и держит ли платформа применение вне приложения. Идите от окна к процессу, затем к межсетевому экрану, затем к фактическому пути.

Не перезагружайте первым делом; перезагрузка обычно уничтожает доказательства.

Начните с того, что ещё работает

Откройте список процессов, прежде чем что-либо трогать. Настольный клиент обычно делится на процесс интерфейса и службу или демон, и сбой первого не обязательно останавливает второй. В Windows служба может ещё быть в списке, в Linux юнит может быть ещё активен, а в Android туннель принадлежит системе после выдачи согласия. Прочитайте эти три факта в таком порядке.

Если демон жив, туннель, вероятно, тоже жив, а пропавшее окно — только косметика.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Читайте блокировку у того, кто её применяет, а не в приложении

Если клиент реализует свой аварийный выключатель вставкой правил межсетевого экрана, эти правила принадлежат операционной системе и переживают процесс, который их создал. Тогда сбой оставит вас заблокированными без какого-либо интерфейса, чтобы это отключить, и это выглядит как сломанная сеть, а не как защита. Если же блокировка живёт внутри собственного пути пакетов клиента, убийство процесса снимает блокировку в тот же момент.

Android обходится с этим снова иначе: always-on VPN с lockdown — это настройка платформы, поэтому блокировка сохраняется независимо от процесса приложения, и система может перезапустить службу. Сверьтесь с документацией платформы насчёт точного поведения, вместо того чтобы предполагать, что оно совпадает с настольным клиентом.

Отличите штатный выход от сбоя

Обычный Quit запускает путь завершения клиента, который намеренно удаляет правила и закрывает туннель. Сбой пропускает этот путь и оставляет всё, что применяющий уже установил. Разница видна в отметках времени правил относительно выхода процесса и в том, существует ли ещё устаревший интерфейс туннеля без владельца.

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

Восстановите, не ломая другие средства контроля

Перезапустите клиент через его документированный рабочий процесс, затем проверьте обе половины требования: туннель передаёт трафик, и блокировка всё ещё применяется, когда должна. Полная очистка межсетевого экрана ради возврата связи удаляет и посторонние средства контроля, и такая сделка редко того стоит.

При повторном сбое соберите версию клиента, сборку платформы и ограниченные журналы, которые просит поставщик. Профиль клиента, закрытый ключ или полный журнал подключения другого аккаунта не нужны для отчёта о сбое, и их включение превращает обращение в проблему обработки данных.

Один сбой не доказывает утечку. Доказательство — это замеченный пакет, уходящий путём, который политика должна была предотвратить, зафиксированный в момент, когда клиент был выключен. Проверьте это намеренно, с безобидным получателем, и запишите, какой уровень применения устоял.