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

Документация клиента — единственное надёжное место, где можно узнать, что есть что.

Четыре элемента управления, возможно четыре поведения

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

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

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

Считывайте состояние до и после каждого действия

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

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

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

Ручное отключение — не сбой

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

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

Выберите то недоступное состояние, которое действительно нужно

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

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

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

Похожие статьи