Fexyn
Fexyn
All posts

Что реально делает kill switch VPN (и почему большинство

Fexyn Team··5 min read

Kill switch у VPN — это фича, которая блокирует весь трафик, когда соединение падает, чтобы твой настоящий IP не утёк, пока клиент переподключается. Каждый VPN говорит, что у него такой есть. Большинство — бесполезны.

Проблема в том, где живёт kill switch. Если он живёт в самом приложении VPN — он может реагировать только после того, как приложение заметит падение. Это userland-код, который проигрывает гонку ОС, уже отправившей твои пакеты.

Окно в 200 мс, о котором никто не говорит

Вот что происходит, когда VPN-туннель падает без kernel-level kill switch:

  1. Удалённый endpoint перестаёт отвечать. Может, сервер ребутнулся. Может, сеть поменялась. Может, маршрутизация дрогнула.
  2. Клиент не замечает где-то от 200 мс до нескольких секунд. Большинство клиентов используют heartbeat. WireGuard пингует каждые 25 секунд по умолчанию. У OpenVPN keepalive настраивается, но обычно 10–60 секунд.
  3. В этом окне твоя ОС всё ещё считает, что туннель работает. Она продолжает роутить трафик в туннельный интерфейс.
  4. Туннельный интерфейс дропает пакеты — но в некоторых конфигурациях fallback-маршрутизация подхватывает, и пакеты уходят через настоящий интерфейс. Твой браузер продолжает слать запросы. Почтовик продолжает поллить. IM-клиенты держат свои TCP-сессии живыми.
  5. Сервера назначения логируют твой настоящий IP. Стриминговый сервис обновляет запись сессии. Провайдер видит cleartext DNS-запрос, который должен был обрабатываться в туннеле.

К моменту, когда VPN-клиент проснётся и сработает userland kill switch, утечка уже случилась.

Это и есть большинство kill switch'ей. Они активируются постфактум.

Где живёт настоящий kill switch

Kernel-level kill switch сидит в сетевом стеке ОС, не в процессе VPN-клиента. На Windows — это Windows Filtering Platform, тот же файрвол-API, который использует Windows Defender. На macOS — Network Extension framework. На Linux — правила nftables/iptables с PF_INET hooks.

Три свойства делают это рабочим:

Активируется до завершения handshake. Когда ты жмёшь Connect, kill switch ставит фильтры первым делом. Handshake идёт через дырку, которую kill switch вырезает для конкретного VPN-endpoint. Если handshake падает — наружу не уходит ничего.

Переживает падение клиента. Если процесс VPN-приложения умирает — kill switch продолжает блокировать. Userland kill switch'и умирают вместе со своим приложением — Windows радостно восстанавливает обычную маршрутизацию в момент закрытия приложения.

Переживает смену сети, sleep, resume. Переход с Wi-Fi на ethernet, закрытие крышки, гибернация, переключение хотспотов — для in-app kill switch'а это отдельные state-переходы, которые надо обрабатывать. WFP-правила — ниже всего этого. Они просто остаются на месте, пока что-то с привилегиями явно их не уберёт.

Как Fexyn это реализует

Windows-клиент Fexyn разделён на две части: UI с правами пользователя и SYSTEM-level helper service. Только helper владеет WFP-фильтрами. Когда ты жмёшь Connect:

  1. Helper ставит WFP-фильтры, которые блокируют весь исходящий трафик кроме (а) loopback, (б) конкретного VPN endpoint:port, и (в) DHCP/DNS до локального шлюза для целей handshake.
  2. VPN-handshake идёт через эту вырезанную дырку.
  3. Когда туннель поднялся, таблица маршрутизации шлёт всё в туннельный интерфейс. WFP-фильтры остаются на месте; они просто не видят большую часть трафика, потому что туннель — путь наименьшего сопротивления.
  4. Если туннель падает — таблица маршрутизации теряет туннельный маршрут. Трафик откатывается на дефолтный интерфейс. WFP-фильтры его блокируют. Браузер показывает «нет интернета». Настоящий IP остаётся скрыт.
  5. Когда helper успешно переподключается, новый endpoint туннеля может отличаться. Helper обновляет вырезанную дырку, и трафик снова течёт.

Пользователь ничего не выключает. UI никогда не запрашивает админа. Kill switch никогда не зависит от того, жив ли UI.

Как это выглядит на практике

Открой Wireshark и устрой принудительное падение VPN (выдерни сеть, переключись между Wi-Fi, suspend и resume). С userland kill switch'ом ты увидишь, как пакеты продолжают течь по нижележащему интерфейсу какое-то время после падения — обычно от 200 мс до нескольких секунд. С WFP kill switch ты не увидишь ничего, пока туннель не переподключится или ты явно не отключишь kill switch.

Второе — это то, чего ты хочешь.

Чем kill switch не является

Kill switch решает одну конкретную проблему: утечки трафика во время переходных состояний туннеля. Он не:

  • Защищает скомпрометированный endpoint. Если ноут заражён — малварь видит трафик до того, как его увидит ядро.
  • Сам по себе не останавливает DNS-утечки. Защита от DNS-утечек — отдельный слой (NRPT-правила на Windows, force-DNS-through-tunnel в конфиге протокола). Один kill switch криво настроенный DNS не починит.
  • Не предотвращает WebRTC-утечки. Браузерный WebRTC работает выше сетевого уровня; браузер знает твой настоящий IP независимо от того, что видит сеть. Совсем другой фикс.

На что смотреть

Если оцениваешь kill switch у VPN, вопросы такие:

  1. Активируется ли он до завершения handshake или только после?
  2. Переживает ли он падение VPN-клиента?
  3. Это правило файрвола на уровне ядра или userland reconnect-loop?
  4. Разрешает ли он loopback, чтобы локальные dev-серверы продолжали работать?

Честные ответы обычно есть в продуктовой документации, не в маркетинге. Маркетинг всегда скажет «kill switch» без указания, какого вида.

У Fexyn:

  • WFP-based, kernel level
  • Активируется до handshake
  • Переживает падение helper service, sleep, resume, смену сети
  • Разрешает loopback (127.0.0.0/8 и ::1) и link-local

Связанное чтение

Попробуй Fexyn бесплатно 7 дней. Kill switch включён по умолчанию — его не нужно включать.

Что реально делает kill switch VPN (и почему большинство | Fexyn VPN