Kill Switch

Если совсем просто.

Ноутбук уснул, затем проснулся в другой сети. VPN ещё восстанавливается. Без блокировки приложение может продолжить прямой обмен; с корректным строгим режимом оно должно дождаться защищённого пути. Если интернет временно пропал именно из-за этой политики, отсутствие связи может быть ожидаемой защитой, а не поломкой Wi-Fi.

Как это работает.

Механизм использует сетевые ограничения операционной системы или правила клиента, разрешая нужный путь и запрещая обход. Должен сохраняться способ связаться с самим VPN-сервером. DNS, IPv6, локальные исключения и split tunneling усложняют политику. Поэтому поведение зависит от реализации, а не от одного универсального стандарта с таким названием.

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

Почему это важно.

Включите поддерживаемый режим и проведите безопасный тест с несекретной страницей. Проверьте потерю сети, восстановление, смену Wi-Fi и ручное отключение отдельно. Прежде чем тестировать удалённый компьютер, обеспечьте другой способ доступа: блокировка может оборвать вашу административную сессию. На Android различайте always-on и «Блокировать соединения без VPN»: удержание клиента и запрет обхода решают разные части задачи. Для каждого теста укажите, была ли потеря связи неожиданной или пользователь сам выключил туннель. Это важная часть результата. Без неё две честные проверки могут выглядеть противоречиво, хотя клиент просто применил разные документированные политики. Сопровождение функции начинается с понятного описания состояний, а не только с положения переключателя.

Узнать больше.

Продолжи с соседних понятий или загляни в документацию.