Как включить kill switch WireGuard в Windows

Что именно делает kill switch WireGuard в Windows

Kill switch нужен для ситуации, когда пользователь ожидает полный VPN-туннель и не хочет, чтобы трафик незаметно вернулся на обычный интернет-интерфейс при сбое VPN. В WireGuard for Windows это не отдельная универсальная кнопка в стиле некоторых коммерческих клиентов. Официальная документация WireGuard for Windows описывает специальное поведение: если у интерфейса только один peer и его AllowedIPs содержат default route для IPv4 или IPv6, клиент может установить ограничивающие правила Windows Firewall. При таком режиме разрешается WireGuard-трафик и необходимый служебный трафик, а остальное блокируется согласно описанной сетевой логике. Поэтому нельзя оценивать защиту только по надписи Active: смысл kill switch проявляется именно тогда, когда туннель перестаёт пропускать данные. Если же вы сознательно используете split tunneling, жёсткая блокировка всего трафика противоречит самой идее разделения маршрутов.

Важно: Kill switch имеет смысл только при понятной модели: «весь выбранный трафик обязан идти через VPN или не идти вообще». Для локальных ресурсов и split tunnel правила должны проектироваться отдельно.

Как включить встроенную защиту от утечки трафика

1. Сохраните копию рабочей конфигурации WireGuard, чтобы можно было быстро вернуться к исходным AllowedIPs.
2. Убедитесь, что интерфейс использует один peer для полного туннеля. Для IPv4 в классическом варианте peer охватывает 0.0.0.0/0; при необходимости полного IPv6-туннеля добавляют ::/0.
3. Если конфигурация задаёт DNS, проверьте, что это нужный резолвер и он доступен в туннеле. При строгом режиме ошибочный DNS может выглядеть как полная потеря интернета.
4. Активируйте туннель и сначала убедитесь, что обычный доступ работает через VPN: есть handshake, растут RX/TX, нужные сайты открываются.
5. Зафиксируйте внешний IP при активном VPN и проверьте DNS-путь тем способом, который вы обычно используете. Это базовая точка сравнения.
6. Не деактивируя интерфейс вручную, создайте безопасный тест отказа: временно сделайте Endpoint недоступным со своей стороны или используйте тестовую конфигурацию. При работающем kill switch обычный интернет не должен тихо переключиться на физический интерфейс.
7. Верните Endpoint и убедитесь, что соединение восстановилось. Если доступ не возвращается, восстановите исходную конфигурацию и проверьте, не конфликтуют ли правила с другим VPN, firewall-продуктом или управлением устройства.

Совет: Тестируйте отказ на нерабочей задаче: открытый звонок, загрузка или удалённая сессия могут оборваться именно потому, что kill switch делает свою работу.

Почему 0.0.0.0/1 + 128.0.0.0/1 — не то же самое

С точки зрения маршрутизации две половины IPv4-пространства 0.0.0.0/1 и 128.0.0.0/1 вместе охватывают почти тот же адресный диапазон, что и 0.0.0.0/0. Но WireGuard for Windows специально различает эти конфигурации. В официальной документации указано, что разбиение default route на две половины позволяет получить похожую маршрутизацию, не активируя встроенную kill-switch семантику, связанную с `/0`. Это важный edge case: внешне интернет может стабильно идти через VPN, поэтому пользователь считает, что защита от утечки включена, хотя при падении туннеля Windows сможет использовать обычный маршрут. Аналогично для IPv6 недостаточно думать только об IPv4. Если система имеет рабочую IPv6-связность, а VPN покрывает исключительно IPv4, часть приложений может использовать IPv6 вне ожидаемого туннеля. Настройка должна соответствовать тому, какой стек вы реально хотите защищать.

Что проверить в конфигурации и в тесте

• AllowedIPs = 0.0.0.0/0 — признак полного IPv4-маршрута; для полного IPv6 отдельно нужен ::/0.
• Один peer — условие специальной kill-switch логики, описанной WireGuard for Windows.
• DNS — должен оставаться доступным при активном туннеле; иначе блокировка может быть ошибочно принята за сбой маршрутизации.
• Тест при рабочем сервере — подтверждает, что туннель вообще исправен до проверки аварии.
• Тест при недоступном Endpoint — обычный интернет не должен незаметно обходить VPN.
• IPv6 — проверьте отдельно, если провайдер и Windows его используют; защита одного IPv4 не равна защите всех соединений.

Совет: Для диагностики полезно выполнить два независимых теста: сначала штатный полный туннель, затем отказ Endpoint. Если первый уже не работает, оценивать kill switch рано.

Когда жёсткий kill switch ломает нужные локальные функции

Строгая блокировка может неожиданно отрезать принтер, NAS, Chromecast-подобные устройства, локальную веб-панель роутера и другие сервисы, которые находятся рядом, а не за VPN. Это не обязательно ошибка WireGuard: правило защиты специально не даёт пакетам уходить обычным путём. Перед включением определите, должен ли локальный LAN быть доступен параллельно полному VPN. Если да, готовая «универсальная» конфигурация может не соответствовать задаче, и нужны осознанные исключения или другая схема маршрутизации и firewall. В корпоративной среде такие исключения должен проектировать администратор, поскольку каждое из них расширяет путь обхода туннеля. Не пытайтесь чинить доступ отключением Windows Firewall целиком: встроенная kill-switch логика сама опирается на платформенные механизмы фильтрации, а полное отключение защиты меняет условия теста. Также учитывайте второй VPN-клиент: два продукта, одновременно управляющие маршрутами и фильтрами, способны давать результат, который трудно интерпретировать.

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

Чем штатное отключение отличается от реальной аварии

Нажатие Deactivate не всегда является лучшим тестом утечки, потому что клиент штатно удаляет интерфейс и связанные с ним правила. Для проверки именно аварийной модели важнее посмотреть, что происходит, когда туннель остаётся настроенным, но peer перестаёт быть достижим. Делайте такой тест контролируемо и без критичной работы. Если защита задумана как «VPN или ничего», после потери связи приложение не должно незаметно продолжить передачу через обычный шлюз. После восстановления обязательно повторно проверьте внешний IP и DNS, чтобы убедиться, что система вернулась к ожидаемой схеме.

Контрольный список без утечки

• Конфигурация полного туннеля использует ожидаемые `/0` маршруты, а не две половины только ради обхода kill switch.
• Рабочий туннель имеет handshake и двусторонний трафик.
• Внешний IP при активном VPN соответствует ожидаемому выходу VPN.
• При тестовом отказе сервера браузер и другие приложения не переходят на обычный интернет.
• IPv6 протестирован отдельно либо осознанно отключён/маршрутизирован согласно вашей схеме.
• DNS не уходит неожиданно на сторонний резолвер вне выбранной модели.
• Локальные исключения, если они нужны, минимальны и задокументированы.

Что учитывать

С точки зрения маршрутизации две половины IPv4-пространства 0.0.0.0/1 и 128.0.0.0/1 вместе охватывают почти тот же адресный диапазон, что и 0.0.0.0/0. Но WireGuard for Windows специально различает эти конфигурации. В официальной документации указано, что разбиение default route на две половины позволяет получить похожую маршрутизацию, не активируя встроенную kill-switch семантику, связанную с `/0`. Это важный edge case: внешне интернет может стабильно идти через VPN, поэтому пользователь…

Источники и проверка

Инструкция составлена редакцией N1RO на 2026-09-20. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.

• WireGuard for Windows: enterprise network quirks / kill-switch routing behavior