Проблема, которую решает kill switch
VPN-туннель — это сетевой интерфейс, через который маршрутизируется трафик. Пока туннель активен, пакеты уходят через него и внешний наблюдатель видит только IP сервера VPN. Но туннель может прерваться: потеря пакетов, таймаут keepalive, сбой на стороне сервера, переключение между сетями Wi-Fi и мобильными данными.
В момент обрыва операционная система возвращает маршрутизацию к шлюзу по умолчанию — реальному интерфейсу (eth0, wlan0, enp3s0). Если в этот момент приложение продолжает отправлять данные, они уходят в интернет напрямую, с настоящим IP-адресом устройства. Для пользователя, который рассчитывает на анонимность или обход геоограничений, это означает мгновенную деанонимизацию.
Kill switch — механизм, который блокирует исходящий трафик на уровне ОС или приложения, когда VPN-туннель неактивен. Вместо того чтобы позволить пакетам уйти через реальный интерфейс, система их отбрасывает.
Механика на уровне маршрутизации
Чтобы понять, как работает kill switch, нужно рассмотреть, что происходит с таблицей маршрутизации при подключении VPN.
Типичная последовательность:
- VPN-клиент поднимает туннельный интерфейс (например,
tun0для OpenVPN илиwg0для WireGuard).
- Назначает ему адрес из внутренней подсети VPN.
- Добавляет маршрут по умолчанию (
0.0.0.0/0), указывающий на туннельный интерфейс, либо заменяет существующий default route.
- Весь исходящий трафик теперь уходит через туннель.
При обрыве туннеля:
- Туннельный интерфейс исчезает или переходит в состояние down.
- Маршрут через него становится невалидным.
- Ядро ОС выбирает следующий доступный маршрут — через реальный сетевой интерфейс.
- Трафик начинает идти напрямую.
Kill switch вмешивается между шагами 3 и 4: он гарантирует, что даже при наличии валидного маршрута через реальный интерфейс пакеты не будут отправлены.
Два уровня реализации
Системный kill switch (firewall-based)
Работает на уровне сетевой подсистемы ОС. Правила межсетевого экрана настроены так, что исходящий трафик разрешён только через туннельный интерфейс. Если туннель отсутствует — трафик не проходит ни через один интерфейс.
Концептуально логика выглядит так:
- Разрешить исходящие пакеты, если интерфейс отправки — туннельный (wg0, tun0).
- Запретить исходящие пакеты на всех остальных интерфейсах, кроме loopback.
- Разрешить входящие пакеты, связанные с уже установленными соединениями (established/related).
Такой подход не зависит от конкретного приложения: блокируется весь трафик системы целиком. Даже если VPN-клиент аварийно завершится, правила firewall продолжают действовать.
На Linux это реализуется через iptables или nftables. На Windows — через Windows Firewall с правилами, привязанными к интерфейсу. На macOS — через pf (Packet Filter).
Прикладной kill switch (application-level)
VPN-клиент отслеживает состояние туннеля и при его падении блокирует сетевые вызовы конкретных приложений или всех процессов. Реализация зависит от клиента:
- Некоторые клиенты используют локальный прокси, через который идёт трафик. При обрыве туннеля прокси перестаёт принимать соединения.
- Другие мониторят состояние интерфейса и при его исчезновении добавляют временные правила firewall.
- Третьи просто завершают процесс или переводят его в режим ожидания.
Прикладной kill switch удобнее в настройке (можно выбрать, какие приложения защищать), но менее надёжен: если сам VPN-клиент упадёт, механизм блокировки может не сработать.
Kill switch и WireGuard
WireGuard создаёт стандартный сетевой интерфейс (
wg0, wg1 и т. д.), который конфигурируется обычными сетевыми утилитами. Это означает, что системный kill switch для WireGuard строится на тех же принципах, что и для любого другого туннельного интерфейса.Особенность WireGuard — параметр
AllowedIPs в конфигурации пира. Когда клиент указывает AllowedIPs = 0.0.0.0/0, это означает, что весь трафик должен маршрутизироваться через туннель. WireGuard добавляет соответствующий маршрут в таблицу маршрутизации. Но сам по себе этот параметр не является kill switch: если интерфейс wg0 исчезнет, маршрут станет невалидным, и ядро переключится на реальный интерфейс.Для полноценной защиты нужно дополнить конфигурацию правилами firewall, которые запрещают исходящий трафик через все интерфейсы, кроме
wg0.Отдельный аспект — network namespaces. WireGuard отправляет и принимает пакеты в том network namespace, где был создан интерфейс. Это позволяет изолировать контейнер или процесс: если WireGuard-интерфейс перемещён в namespace контейнера как единственный сетевой интерфейс, контейнер физически не может отправить трафик в обход туннеля. При обрыве туннеля контейнер теряет сетевой доступ полностью — это естественный kill switch на уровне изоляции.
Типичные сценарии утечки без kill switch
| Сценарий | Что происходит | Последствие |
|----------|---------------|-------------|
| Таймаут keepalive | Туннель не получает ответов, интерфейс переходит в down | Трафик уходит через реальный IP |
| Переключение Wi-Fi → LTE | Сетевой интерфейс меняется, туннель рвётся | Кратковременная утечка реального IP |
| Сбой VPN-сервера | Сервер перестаёт отвечать, туннель падает | Утечка до переподключения |
| Обновление VPN-клиента | Клиент перезапускается, туннель временно отсутствует | Утечка в окне перезапуска |
| OOM killer завершает процесс VPN | Туннельный интерфейс исчезает | Трафик идёт напрямую |
Как проверить, что kill switch работает
Проверка сводится к имитации обрыва туннеля и наблюдению за тем, уходит ли трафик наружу.
Метод 1: отключение туннельного интерфейса
Bash:
## Переводим туннель в down (для WireGuard)
ip link set wg0 down
После этого пытаемся выполнить запрос наружу:
Bash:
curl --max-time 5 https://ifconfig.me
Если kill switch работает, запрос не пройдёт — соединение будет отклонено или таймаут. Если запрос вернул ваш реальный IP, kill switch не активен.
Метод 2: удаление маршрута через туннель
Bash:
ip route del default dev wg0
Это имитирует ситуацию, когда маршрут через туннель исчез, но интерфейс формально ещё существует.
Метод 3: мониторинг в реальном времени
Запустите непрерывный запрос к сервису, возвращающему IP, и одновременно вызовите обрыв:
Bash:
while true; do curl -s --max-time 3 https://ifconfig.me; echo; sleep 1; done
Если в выводе появляется реальный IP хотя бы на одну итерацию — kill switch не сработал.
Ограничения и подводные камни
DNS-утечки. Kill switch блокирует IP-трафик, но если DNS-запросы настроены на системный резолвер (а не на DNS внутри туннеля), они могут уйти через реальный интерфейс ещё до того, как kill switch полностью активируется. Подробнее — в материале DNS leak: как VPN может скрыть IP, но выдать DNS-запросы, и как это проверить.
IPv6. Если kill switch настроен только для IPv4, а в системе активен IPv6, трафик может уходить через IPv6-интерфейс. Правила firewall должны покрывать оба семейства адресов.
Локальный трафик. Системный kill switch, блокирующий всё кроме туннеля, может нарушить работу локальных сервисов: DHCP, mDNS, обращение к локальным устройствам. Обычно loopback и link-local адреса исключают из блокировки.
Порядок правил firewall. Если правило разрешения трафика через реальный интерфейс стоит выше правила блокировки, kill switch не сработает. Порядок цепочек имеет значение.
Гонка при подключении. Между моментом поднятия туннеля и добавлением правил firewall существует окно, в которое трафик может уйти напрямую. Качественные реализации добавляют блокирующие правила до установки туннеля и снимают их только после подтверждения, что туннель активен.
Что выбрать
Для максимальной защиты — системный kill switch на уровне firewall. Он не зависит от VPN-клиента, работает даже при его падении и покрывает все приложения.
Для удобства — прикладной kill switch в составе VPN-клиента. Он проще в настройке, позволяет гибко выбирать защищаемые приложения, но менее устойчив к сбоям самого клиента.
Оптимальная стратегия: системный kill switch как базовый слой + прикладной как дополнительный механизм быстрого реагирования.
