Что происходит, когда VPN отключается? Kill switch объяснён

Задача kill switch проста на словах: когда VPN-соединение падает, не дать трафику утечь из туннеля. Реализации у разных VPN-провайдеров сильно отличаются, и разница важна. Kill switch с многосекундным окном лика во время дропа VPN перечёркивает весь смысл иметь kill switch.

Это техническая версия. Что kill switch реально делает, два главных паттерна реализации, почему kernel-level важен и как протестировать, что твой работает.

Что значит «kill switch»

Когда VPN-клиент устанавливает туннель, твой трафик идёт через него. Когда туннель ломается — отказ сервера, смена сети, цикл сна/пробуждения, прерывание на уровне протокола — вопрос в том, что происходит с трафиком во время разрыва.

Три возможных поведения:

Трафик продолжает идти через реальное соединение. Реальный IP становится виден назначениям. Шифрование, которое должно было быть включено, выключено. Все, кто наблюдает сеть, видят, что ты делаешь. Это происходит без kill switch вообще.
App-level kill switch детектит дроп и останавливает трафик. Демон VPN-клиента замечает, что туннель упал, и принимает меры для блокировки трафика. У детектирования есть задержка (демон поллит; сетевой стек репортит дропы с задержкой; действие применяется со временем). Окно лика обычно 1–30 секунд.
Kernel-level kill switch блокирует весь трафик кроме VPN-туннеля изначально. Файрвольные правила на уровне ядра ОС блокируют всё, что не в VPN-туннеле. Когда VPN падает, правила всё ещё блокируют всё; новый трафик не выйдет до реконнекта VPN. Нет задержки детектирования, потому что нечего детектировать — правила блокируют по умолчанию и пускают только VPN-трафик.

Большинство провайдеров реализуют что-то. Вопрос — что именно.

Как падают VPN-соединения

Стоит понять, потому что это формирует, что kill switch должен обрабатывать. Падения случаются по разным причинам:

Серверные отказы. VPN-сервер падает, ребутается или у него флапает сетевой интерфейс. Восстановление: клиент реконнектится, возможно к другому серверу.

Смены сети на клиенте. Переключение с Wi-Fi на Ethernet. Смена Wi-Fi-сетей. Усыпление и пробуждение ноута. VPN-туннель ломается, потому что меняется базовая сеть; клиенту нужно переустановить.

Проблемы уровня протокола. Таймаут handshake WireGuard (peer не отвечает в течение 90 секунд после последнего handshake). Провал keep-alive у OpenVPN. Таймаут TLS-сессии у VLESS Reality.

Активное вмешательство. Сетевой оператор или DPI-система блокирует VPN посреди сессии. Соединение падает, и клиент не может переустановить, пока сеть не сменится или протокол не переключится.

Падения клиента. Процесс VPN-клиента умирает по любой причине.

Окна загрузки/выключения. У системы есть сетевой доступ до старта VPN-клиента (загрузка) и после его выключения. В эти окна трафик может утекать, даже если kill switch в остальном крепок.

Полный kill switch обрабатывает всё это. App-level реализация обрабатывает с задержкой детектирования на каждом событии. Kernel-level обрабатывает дефолтной блокировкой всего не в туннеле.

App-level kill switch: как работает

Большинство VPN-клиентов реализуют это:

Клиент устанавливает туннель.
Поллит состояние туннеля по таймеру (обычно 1–5 секунд).
Когда поллинг детектит упавший туннель, клиент говорит ОС остановить трафик — обычно меняя таблицу маршрутизации или системными вызовами для блокировки конкретных соединений.
Когда туннель реконнектится, клиент откатывает блок.

Окна лика:

Между дропом и детектом. Если интервал поллинга 5 секунд — окно до 5 секунд.
Между детектом и действием. OS-вызовы занимают время. Изменения таблицы маршрутизации распространяются. У системы есть время отправить пакеты не туда.
Между падением клиента и восстановлением OS-уровня. Если процесс VPN-клиента умер, ОС ничего не говорит блокировать трафик. Без других гарантий трафик течёт свободно, пока клиент не перезапустится.
На загрузке до старта клиента. Та же проблема: трафик может течь свободно до подъёма VPN-клиента.

Часть app-level реализаций крепче других — корректно восстанавливаются после падения, применяют блоки на уровне сетевого адаптера, а не таблицы маршрутизации, интегрируются с network-state нотификациями ОС. Kill switch у NordVPN, Network Lock у ExpressVPN, kill switch у Surfshark — разной степени продуманности. Но ни один не основан на kernel-level фильтрах через все платформы.

Kernel-level kill switch: как работает

Другой подход: установить файрвольные правила на уровне ядра ОС, блокирующие весь трафик кроме трафика к VPN-эндпоинту и трафика в VPN-туннеле. Правила переживают падения клиента, ребуты, сон/пробуждение.

На Windows это значит WFP-фильтры (Windows Filtering Platform). WFP — kernel-level подсистема фильтрации пакетов, которую Windows использует для встроенного файрвола и сторонних security-продуктов. Фильтры на уровне WFP применяются к каждому пакету, входящему или выходящему из сетевого стека, независимо от приложения.

На macOS эквивалент — pf (packet filter).

На Linux — iptables или nftables на уровне ядра.

Паттерн через все три:

VPN-клиент (или его установщик) регистрирует kernel-level правила, блокирующие весь трафик кроме:
- Трафика к серверным эндпоинтам VPN-провайдера (чтобы VPN мог подключиться)
- Трафика в VPN-туннеле (для реального трафика пользователя)
Правила переживают падения клиента, ребуты, сон/пробуждение.
Когда VPN-клиент устанавливает туннель, трафик течёт. Когда туннель падает, трафик останавливается, потому что правила всё ещё блокируют всё не в туннеле.
Нет окна детект-и-действие, потому что нечего детектировать — дефолтное состояние «заблокировано кроме туннеля».

Kill switch Fexyn на Windows — WFP-based. Правила WFP-фильтров устанавливаются helper-сервисом (SYSTEM-привилегированный сервис с правами на kernel-фильтры) и переживают загрузки. Когда пользователь стартует VPN-клиент, helper поднимает туннель, и трафик течёт. Когда туннель падает, WFP-правила всё ещё блокируют всё; трафик не выходит, пока туннель не вернётся.

Boot-time persistence

Сложнее проблема: что происходит во время загрузки до старта VPN-клиента?

Без boot-time persistence у системы есть интернет-доступ во время загрузки (для подключения к корпоративным сетям, скачивания обновлений Windows, синхронизации времени с NTP-серверами) до подъёма VPN-клиента. В этом окне всё, что автозапускается на загрузке, может общаться через нешифрованное соединение.

Boot-time persistent kill switch ставят WFP-правила, переживающие ребуты. Правила блокируют весь трафик во время загрузки, пока VPN-клиент не поднимется и не подымет туннель. VPN-клиент при старте сигналит WFP-правилам пускать туннельный трафик; до сигнала у системы нет интернет-доступа.

Это агрессивнее, чем большинство пользователей хотят — ноут реально не достигнет интернета на загрузке, пока не поднимется VPN. Но для пользователей с сильными требованиями к приватности (журналисты, активисты, отдельные корпоративные пользователи) boot-time persistence — единственный способ предотвратить лики окна загрузки.

Fexyn поддерживает boot-time persistence как настраиваемую опцию. Дефолт — выключено (потому что путает новых пользователей, когда ноут кажется «сломанным» на загрузке). Включение — один тогл в настройках.

Как протестировать kill switch

Честный тест:

Стартуй VPN. Убедись, что подключён (проверь IP на ipleak.net или похожем — должен показать exit IP VPN).
Открой торрент-клиент или любое приложение со стабильным трафиком. Заметь реальный IP на ipleak.net.
Отключи сетевой адаптер (или выдерни Ethernet, или выключи Wi-Fi). VPN падает, потому что сети нет.
Подожди 30 секунд. Попытки реконнекта VPN провалятся, потому что сети нет.
Включи сетевой адаптер обратно. Заметь, что происходит.

Что хочешь увидеть: трафик не начинает течь сразу, когда сеть возвращается. Трафик течёт только после реконнекта VPN. Запусти ipleak.net снова — IP должен быть VPN-выходом, не реальным.

Что не хочешь увидеть: трафик течёт сразу при возврате сети, реальный IP виден на ipleak.net, VPN реконнектится в фоне, но только после того, как часть трафика уже утекла.

Kernel-level kill switch проходит этот тест. App-level с быстрым циклом детектирования обычно проходит. App-level с медленным циклом — проваливается.

Почему это важно для конкретных кейсов

Для большинства пользователей — обычная приватность, occasional работа на публичном Wi-Fi, гео-обход для стриминга — app-level kill switch обычно ок. Окна лика — секунды, не минуты; трафик, который утекает, вряд ли достаточно чувствителен.

Для конкретных кейсов kernel-level важнее:

Торренты. Торрент-клиент, работающий часами, может пережить дропы VPN без замечания. Реальный IP, появляющийся в логах роя даже на пару секунд — достаточно, чтобы агенты правообладателей залогировали. Kernel-level kill switch предотвращает лик.

Журналистика, активизм, диссидентская работа. Коммуникации, требующие конфиденциальности по соображениям безопасности, не могут терпеть даже коротких ликов. Kernel-level + boot-time persistence — правильная конфигурация.

Compliance-driven использование (HIPAA, ABA 477R). VPN, падающий посреди сессии и раскрывающий клиентские данные через нешифрованное соединение, — compliance-постура, которую пытаешься предотвратить. Kernel-level kill switch — технический контроль, делающий compliance-клейм защитимым.

Корпоративные среды. Kill switch, переживающий циклы сна/пробуждения, важен для ноутов, которые ездят в сумках во время путешествий.

Какие провайдеры что используют

Картина в 2026:

Fexyn: WFP-based kernel-level на Windows (production) и Android (поставляется); macOS, Linux, iOS клиенты coming soon
Mullvad: kernel-level на Windows, macOS, Linux. Среди самых крепких реализаций.
NordVPN: app-level на большинстве платформ с разными улучшениями; kernel-level фичи в новых Windows-клиентах. Вариативно.
Network Lock у ExpressVPN: app-level с проприетарной реализацией; функционально крепкий на Windows и macOS, но не строго kernel-level fillter-based.
Surfshark: app-level kill switch.
ProtonVPN: kernel-level на большинстве платформ.
IVPN: kernel-level на большинстве платформ.
AirVPN: kernel-level.

Паттерн: провайдеры, фокусированные на технической приватности (Mullvad, ProtonVPN, IVPN, AirVPN, Fexyn), склоняются к kernel-level. Провайдеры на широком consumer-рынке (NordVPN, ExpressVPN, Surfshark) исторически использовали app-level с улучшениями со временем.

Часто спрашивают

Есть ли kill switch у моего VPN?

Почти каждый уважаемый VPN заявляет о наличии. Работает ли он, как надо — вопрос проверки, не предположения. Тест выше — практический ответ.

Почему не каждый VPN использует kernel-level kill switch?

Цена реализации. Kernel-level требует platform-specific код: WFP на Windows, pf на macOS, kernel networking на Linux. Каждая платформа требует отдельной инженерии. App-level работает на каждой платформе с одним кодом. Для VPN-провайдеров на широком consumer-рынке инвестиция в kernel-level исторически не была приоритетом.

Сломает ли boot-time persistence мой компьютер?

Не даст компьютеру достичь интернета во время загрузки до старта VPN. Для большинства это раздражает, но не сломано — VPN стартует, система достигает интернета. Для пользователей в корпоративных сетях, где загрузочные процессы нуждаются в интернет-доступе (присоединение к корпоративным доменам, синхронизация с корпоративными time-серверами, скачивание обновлений с внутренних зеркал), boot-time persistence может мешать. Тестируй до включения.

Что насчёт kill switch для конкретных приложений?

Часть VPN-клиентов позволяет настроить kill switch для конкретных приложений, а не всего трафика. Полезно, когда хочешь, чтобы часть трафика шла через VPN с защитой kill switch (рабочие приложения), а другая шла мимо (стриминг). Fexyn пока не поддерживает per-app kill switch; поставляем all-or-nothing подход. У Mullvad и ProtonVPN более гранулярные per-app опции.

Можно ли доверять kill switch, который не можешь протестировать?

Тестируй. Цена тестирования — минуты; цена нерабочего kill switch — что бы leak-трафик ни раскрыл. Любой kill switch, не тестируемый пользователем, — маркетинговый клейм, не верифицированная фича.

Попробуй Fexyn бесплатно 7 дней — WFP-based kernel-level kill switch на Windows с опциональной boot-time persistence.

Последняя ревизия 2026-05-09.