Kill switch в Windows без дополнительного ПО: профили или маршруты?

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

Клиент умирает посреди загрузки, и значок в трее исчезает. Передача продолжается через домашнее подключение. Именно эта последовательность и есть причина существования kill switch, и Windows может приблизиться к нему без второго продукта.

Стоит знать два метода. Они отказывают в разных местах, и ни один не является полным ответом.

Метод первый: разрешить программу только в одном профиле

Брандмауэр Windows ограничивает правила профилями Domain, Private и Public. Трюк в том, чтобы дать туннельному адаптеру одну категорию, а физическому — другую. Затем вы пишете исходящее правило, которое разрешает защищённую программу в профиле туннеля и блокирует её везде остальном. Брандмауэр читает категорию, а не имя адаптера.

Сначала задайте VPN-подключению профиль Private, а физической сети — Public. Затем добавьте правило блокировки для программы, которое действует для нежелательных профилей. После этого подтвердите назначение с помощью Get-NetConnectionProfile, потому что правило следует именно за этим назначением.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory

New-NetFirewallRule -DisplayName 'Block browser off VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Block -Profile Public

New-NetFirewallRule -DisplayName 'Allow browser on VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Allow -Profile Private

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

Метод второй: удалить физический маршрут по умолчанию

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

route print -4
route delete 0.0.0.0 mask 0.0.0.0 192.168.50.1
route print -4 | findstr /c:"0.0.0.0"

Когда клиент умирает, маршрут VPN уходит вместе со своим адаптером. Машина уходит в офлайн вместо утечки, и именно это должен производить kill switch.

Две детали решают, проживёт ли это неделю. DHCP возвращает шлюз каждый раз, когда связь дрогнет. Физический адаптер со статическим адресом избегает этого сюрприза. Адрес самого VPN-сервера тоже должен оставаться достижимым. Без этого маршрута к хосту клиент никогда не сможет подключиться снова после обрыва, который запустил блокировку.

Метод третий: без шлюза, один постоянный маршрут к хосту

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

route -p add 198.51.100.44 mask 255.255.255.255 192.168.50.1 metric 1
route print -4 | findstr 198.51.100.44

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

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

Почему значок глобуса ничего не доказывает

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

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

Что записать после настоящего обрыва

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

taskkill /IM openvpn-gui.exe /F
ping -4 198.51.100.44
ping -6 2606:4700:4700::1111
route print -4 | findstr /c:"0.0.0.0"

Повторите последовательность после сна, после смены Wi-Fi и после перехода с кабеля на беспроводное соединение. Именно на этих переходах отказывают и метод профиля, и поведение DHCP. Правило, которое держится на столе, не обязательно держится в гостинице.

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

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