Содержание статьи

Вступление: зачем вообще нужен VPN kill switch в 2026 году

Цели и реальность: что мы защищаем на практике

Простой вопрос, но с острым подтекстом: что именно вы готовы потерять за одну секунду без VPN? IP-адрес, историю запросов, данные приложений? В 2026 году, когда приложения синхронизируют все подряд, а браузеры держат десятки фоновых соединений, единственный надежный предохранитель — это VPN kill switch. Он делает жесткую вещь: когда туннель падает, весь трафик без исключения блокируется. Без «может быть», без «наверное выдержит». Гасим все, кроме трафика через защищенный интерфейс. Звучит просто? На самом деле под капотом — хитрый танец ядра ОС, таблиц маршрутов, маркировок пакетов, драйверов и правил фаервола.

Почему это критично именно сейчас

Сегодня риски выросли. Домашние камеры, облачная почта, суперчувствительные мессенджеры, кошельки с криптовалютой — все это подключается само и постоянно. Туннель дрогнул на секундочку — и прилетела утечка DNS, или API-эндпоинт отправил реальный IP. Да, одна секунда. Мы видели кейсы: обновление сетевого драйвера в Windows 11 24H2, микролаги в Wi‑Fi, смена сети у ноута — и готово. Kill switch не обсуждает, он действует: обрубает. И удерживает штурвал, пока туннель не стабилизируется.

Коротко и по делу: что делает kill switch

Kill switch — это не кнопка «выключить интернет». Это набор правил, встроенных в сетевой стек и фаервол системы, которые обеспечивают: только пакеты, идущие через VPN-интерфейс (tun, tap, utun, wg, ikev2), могут выйти в сеть; пакеты в обход — дропаются на ранних хуках. Плюс контроль DNS: резолвинг идет через VPN, а локальные резольверы вне туннеля — под запретом. И да, все это должно жить не в «приложении на кнопках», а на уровне ядра ОС. Иначе гонка условий, и приватность — коту под хвост.

Как работает kill switch на уровне ядра: анатомия сетевого стека

Маршрутизация, сокеты и хуки: где именно перехватывают пакеты

В ядре ОС пакеты проходят несколько стадий: создание сокета приложением, выбор маршрута, применение правил фаервола, обработка интерфейсом, отправка. Kill switch эффектно вставляет «заслон» сразу в двух местах: в таблицах маршрутизации (чтобы весь «дефолт» смотрел в туннель) и в фаерволе (чтобы все, что не помечено как «через VPN», немедленно дропать). Такой двойной захват защищает от гонок: если маршрут мигнул, фаервол подстрахует; если фаервол еще не подхватил интерфейс — маршрут не даст трафику уйти наружу.

Слой ядра на Windows: WFP и фильтры NDIS

На Windows роль «мяса» берет на себя Windows Filtering Platform (WFP). VPN-клиент ставит callout-драйвер или пользуется системными слоями, фильтрует на уровнях транспортного и сетевого стека, маркирует трафик VPN-интерфейса и отсекает все иное. Дополнительно настраиваются профили брандмауэра: правило «блокировать исходящие, кроме интерфейса VPN». На уровне NIC-стека могут подключаться NDIS LWF-драйверы, но в 2026 основной тренд — WFP без лишних драйверов, чтобы не ломать совместимость с Windows 11 24H2 и HVCI.

Linux: netfilter, nftables и cgroup-bpf

В Linux kill switch обычно строят на netfilter. Современная рекомендация — nftables (ядра 5.10+ и, по-хорошему, 6.x): создаем цепочки output/forward, указываем политику drop, разрешаем только пакеты с меткой или через конкретный интерфейс (например, wg0). Дополнительно — policy routing: трафик с fwmark идет по отдельной таблице маршрутизации, default — через туннель, остальное в черную дыру. Для продвинутых конфигураций — cgroup-bpf (BPF_CGROUP_INET_EGRESS): фильтрация на уровне процессов, чтобы, например, ssh вашего админа мог выйти за рамки kill switch для дебага, а все остальное — нет. Гибко и быстро.

macOS: Network Extension и PF

На macOS мы опираемся на Network Extension (NE) и системный Packet Filter (PF). Клиент на NE получает контроль над туннелем (utun-интерфейс), а PF через якоря (anchors) реализует ограничительную политику: блок всех исходящих, кроме интерфейса utunX и разрешенных сервисов на туннеле. DNS закрепляется через NEAppProxyProvider или через системные настройки резолвера, чтобы запросы шли по VPN. В macOS 14+ Apple подтянула стабильность NE, и в 2026 большинство зрелых клиентов держат устойчивые правила PF без коллизий при смене сетей.

Маршрутизация и таблицы: простой способ сломать или спасти приватность

Default route как нервный центр

Классическая ошибка: у вас два дефолтных маршрута — в физическую сеть и в туннель. ОС выбирает «лучший» по метрике. При переподключении, при смене Wi‑Fi, при возобновлении из сна метрики могут поплыть. Итог — часть пакетов выйдет мимо VPN, особенно быстрые DNS-запросы. Правильный kill switch всегда делает так, чтобы дефолтный маршрут указывал на VPN, а все остальное — drop. И чтобы добавление физического интерфейса не возвращало прежний маршрут по умолчанию.

Policy routing и fwmark: хирургия по Linux

В Linux рецепт прост и надежен. Маркируем пакеты от приложений, которые должны идти через туннель (или все пакеты, если стратегия тотальная), создаем отдельную таблицу маршрутизации с дефолтом на туннель, в основной таблице дефолт отсутствует или ведет в blackhole. Даже если интерфейс упадет, трафик без туннеля не найдет выход. Это «железобетонная» схема, особенно в связке с nftables, где можно изящно описывать условия: интерфейс, группа процессов, uid, порты, домены (через sets и maps).

Windows: метрики и интерфейсные профили

Windows любит «самостоятельность». Поэтому мы фиксируем метрики интерфейсов: VPN получает самую низкую метрику, физические — выше. Устанавливаем правила брандмауэра: исходящие разрешены только через интерфейс VPN (по InterfaceAlias или InterfaceType). Если туннель упал — брандмауэр режет все, кроме, возможно, локальных адресов 127.0.0.0/8 и link-local, чтобы сохранить стабильность ОС. В 2026 многие клиенты внедрили автоматическую коррекцию метрик и восстановление правил после перезагрузки службы BFE (Base Filtering Engine), что раньше было ахиллесовой пятой.

macOS: sticky routes и PF anchors

На macOS надежно работает схема с PF: создаем якорь, политика по умолчанию блокирующая, разрешаем только правила, где интерфейс — utunX. Sticky-маршруты для VPN пропишутся через NE автоматически, а PF не даст уйти никакому «фонарику» в обход. Важно: после сна и переключения сетей обновляйте номер utun-интерфейса, так как он может измениться. Грамотные клиенты делают это сами, ловя события через NE.

Правила фаервола: как именно строится блокировка

Linux: nftables вместо iptables

В 2026 iptables жив, но методичка устарела. Мы делаем так: создаем таблицу inet vpn, цепи input, forward, output. Политика output — drop. Разрешаем: established,related; интерфейс wg0 (или tun0); dns через wg0; опционально — локалхост. Можно добавить rule: если interface != wg0, drop, иначе accept. Плюс, чтобы подстраховаться, в таблице route в nftables можно гибко жонглировать направлением трафика при down-состоянии интерфейса, но чаще достаточно строгого output.

Windows: AdvFirewall и WFP

Сценарий: создаем правило исходящего трафика Block All, затем исключение Allow VPN Interface. На уровне GUI это долго и скучно, поэтому мы используем PowerShell. Добавляем правило New-NetFirewallRule с параметрами Direction=Outbound, Action=Block для всех профилей, далее точечные Allow по InterfaceAlias. Современные клиенты идут дальше: устанавливают WFP callout, который дропает пакеты до попадания в стек TCP, а еще маркирует VPN-пакеты, гарантируя обход случайных allow-правил. Это быстрее и надежнее, чем полагаться на пользовательские правила.

macOS: PF с анкорами и states

PF рулит: set block-policy drop, set skip on lo0, anchor vpn-killswitch, где в якоре allow out on utunX from any to any keep state, а также блок оного для всех интерфейсов, отличных от utun. Стейтфул-обработка делает поведение приятным для приложений. Плюс защита DNS: блокировать udp/53 на всех интерфейсах, кроме utun. Если вы используете DoH внутри туннеля — отлично, блокируйте 53 вообще глобально, оставьте tcp/443 через утун.

DNS: отдельный фронт

DNS — самый коварный канал утечки. Правило простое: резолвинг либо через VPN, либо никак. В Linux переназначаем resolv.conf на локальный резолвер, который слушает только на tun-интерфейсе, или используем systemd-resolved с роутингом доменов. В Windows — включаем «Block outside DNS» (у OpenVPN есть флаг), плюс брандмауэр режет udp/53 вне VPN. На macOS через NE задаем scoped DNS, в PF рубим 53 вне utun. И да, проверяйте DoH-клиенты (браузеры умеют хитрить): пусть используют системный стек или DoH-эндпоинт, доступный только через туннель.

Как VPN-клиенты реализуют kill switch: практический разбор

WireGuard: маркировки и AllowedIPs

WireGuard быстр, прост и честен. В связке с wg-quick kill switch достигается двумя идеями: AllowedIPs охватывает весь трафик (0.0.0.0/0, ::/0), а таблицы маршрутизации и fwmark вынуждают трафик идти в wg-интерфейс. В случае падения интерфейса политики nftables дропают выход. При желании можно включить Table=off и настроить policy routing вручную: гибко и предсказуемо. Для мобильных — пересоздание интерфейса на лету, с сохранением правил drop — must have.

OpenVPN: блокировка вне туннеля и маршруты

OpenVPN давно в теме. На Windows параметр block-outside-dns закрывает брешь с DNS, а client-config-dir и route-pre-down скрипты помогают корректно менять маршруты. В Linux хороший тон — связка с nftables: drop всего, кроме tun0. В macOS — PF плюс запуск через launchd с атомарной установкой правил. При активном reconnect OpenVPN важно, чтобы до поднятия TUN-дескриптора действовала блокировка. Поэтому продвинутые клиенты сначала включают «полный аборт» трафика, затем поднимают туннель, затем открывают трафик через интерфейс.

IKEv2/IPsec: системные стеки и селекторы

IKEv2 на Windows и macOS опирается на системные стеки IPsec. Здесь kill switch часто строится на уровне ОС: ограничение исходящих по интерфейсу виртуального адаптера, запрет 0.0.0.0/0 наружу, а маршруты для исключений (split-tunnel) прописываются явно. Если политика — no-split, то проще: все через туннель, остальные интерфейсы под глобальным блоком. На Linux strongSwan позволяет связать политики xfrm с nftables и policy routing — в результате трафик, не попавший в селекторы, просто сгорает.

Гибридные клиенты 2026: eBPF, NE и WFP

Тренд 2026 — меньше «хака», больше интеграции: на Linux — eBPF для фильтрации на уровне cgroup, на macOS — Network Extension с аккуратным PF-конфигом и мониторингом событий, на Windows — WFP без пользовательских трюков. Плюс телеметрия состояния: если интерфейс flapping, клиент не дергает маршруты каждую миллисекунду, а использует задержки и транзакции, чтобы не возникало окон утечек.

Пошаговая настройка: Windows, Linux, macOS

Windows 11: брандмауэр и маршруты

Базовый план: сначала включаем общий блок исходящего трафика, затем добавляем исключения для VPN-интерфейса. Через PowerShell это выглядит так: создаем правило блокировки исходящего по всем профилям; добавляем разрешение для InterfaceAlias вашего VPN (например, «WireGuard Tunnel» или «Ethernet 5» в зависимости от драйвера); настраиваем приоритеты интерфейсов — Set-NetIPInterface с AutomaticMetric Disabled и вручную задаем InterfaceMetric для VPN ниже. Итог: даже если служба VPN упадет, трафик не уйдет, потому что общий блок активен. Полезная мелочь — отдельное правило для loopback, иначе некоторые приложения «обидятся».

Linux (nftables + policy routing)

Ход: создаем таблицу inet vpn, цепь output с policy drop. Разрешаем: oifname «wg0» или «tun0», established, локалхост. Отдельно — помечаем трафик через fwmark (например, 0x1), добавляем ip rule lookup 100 для fwmark 0x1, а в таблице 100 дефолт — на VPN. В основной таблице дефолта нет или стоит blackhole. Дальше — опционально: cgroup-bpf для белых списков сервисов администрирования. Проверка — ping, curl с bind к интерфейсу, а также системный трафик (NTP, time sync) — все должно идти через туннель.

macOS (PF + NE)

Действуем так: запускаем VPN-клиент на Network Extension, определяем utunX интерфейс. В /etc/pf.conf создаем anchor «vpn-killswitch», включаем block drop по умолчанию, skip on lo0. В якоре прописываем правила allow only on utunX. Активируем pfctl с загрузкой якоря. В клиенте задаем scoped DNS — чтобы резолвинг не выскакивал наружу. После сна ловим события и обновляем utunX в правилах, если номер изменился. Практика показывает, что при таком подходе утечек нет даже при резких переключениях Wi‑Fi.

Учет приложений и исключений

Иногда нужно сделать исключения: обновления ОС, корпоративные агенты, VoIP вне VPN. Делайте это осознанно. В Linux выделяйте cgroup с отдельной политикой. В Windows — WFP callout или правила по AppPath и сервисы. В macOS — NEFilterDataProvider с App Rules. И держите полный лог: кто вышел наружу и зачем. Kill switch остается жестким по умолчанию, исключения — точечны и контролируемы.

Проверка и тесты: как убедиться, что kill switch реально работает

Быстрые проверки IP и DNS

1) Отключите VPN и посмотрите: есть ли интернет. Должно быть «нет». 2) Включите VPN и откройте страницу определения IP: должен быть адрес провайдера VPN. 3) Разорвите туннель принудительно: стопните службу, выключите интерфейс. Интернет должен исчезнуть. 4) Проверьте DNS: запустите резолвинг доменов и убедитесь, что запросы идут через интерфейс VPN. Если открывается сеть при падении — значит, заслон где-то пропускает.

Просмотр маршрутов и интерфейсов

Windows: route print, Get-NetRoute, Get-NetIPInterface — смотрим метрики, дефолтные маршруты, NextHop на VPN. Linux: ip route, ip rule, ip -4 -6 route show table 100 — видим политику. macOS: netstat -rn, scutil --dns — проверяем дефолт и DNS-scopes. Опустите туннель и проверьте: исчез ли дефолтный маршрут, и не появился ли внешний дефолт без блокировки фаервола. Если появился — дорабатываем политику.

Сниффер на минималках

Linux: tcpdump -i any not host адрес_VPN — не должно быть исходящих пакетов наружу. Windows: встроенный pktmon или Wireshark с фильтром not ip.addr==VPN_IP и not interface==VPN. macOS: tcpdump -i en0 или en1 — при падении туннеля тишина. Сниффер — лучшая лакмусовая бумажка. Он не врет: если пакеты летят, значит, где-то луз.

Тест на гонки и sleep-wake

Сложный, но показательный сценарий: активные закачки, видеозвонок, десяток вкладок в браузере, затем — перевод ноутбука в сон и обратно, смена Wi‑Fi на мобильную точку доступа, быстрый ноутбук в док-станции. Правильный kill switch переживет все это: ни одного пакета мимо туннеля. Если в логах видно короткие выходы наружу — усилите правила на уровне ядра, уменьшите окна между снятием и установкой правил при реконнекте.

Типовые ошибки и реальные кейсы

Двойной дефолт и метрики

Мы видели классический косяк: в Windows метрика для физического интерфейса ниже, чем для VPN. После обновления драйвера метрики «автоматически оптимизировались», и часть трафика пошла не туда. Лекарство — фиксируйте метрики вручную и контролируйте правила фаервола, где явно указан InterfaceAlias VPN.

DNS-утечки через DoH

Браузер умеет DoH через свой список резольверов. Вы блокируете 53/udp — хорошо, но браузер продолжает слать DoH по 443 мимо туннеля. Решение: заставьте приложение использовать системный резолвер через политику, а в фаерволе разрешите DoH только при oif=VPN. На Linux удобно: nftables sets для IP-адресов DoH-провайдера, разрешенных через туннель, и глобальный блок для остальных.

Split-tunnel и человеческий фактор

Корпоративные политики иногда разрешают часть трафика идти напрямую. Риск огромный: одна неверная сеть в исключениях — и приватность дырявая. Подход: минимально необходимый split и чёткий аудит. Белые списки доменов лучше резолвить через VPN и затем выпускать по IP наружу только то, что действительно нужно.

Мобильные сети и NAT64

В LTE/5G иногда работает NAT64 и переходные механизмы, из-за которых часть IPv6-трафика может попытаться проскочить мимо, если вы фильтруете только IPv4. Убедитесь, что kill switch охватывает IPv4 и IPv6. В AllowedIPs ставьте 0.0.0.0/0 и ::/0. В nftables — таблицы inet, чтобы покрывать оба стека одновременно.

Продвинутые техники и тренды 2026

eBPF на Linux: фильтрация на уровне процессов

С eBPF мы уходим от «топорных» глобальных блокировок к умным политикам. cgroup-bpf позволяет сказать: все процессы по умолчанию не могут выходить вне wg0, но сервис «обновление времени» — можно, и только в этот пул IP. Это снижает боль, когда что-то критичное ломается из-за строгой политики. И делает kill switch дружелюбнее для эксплуатации, не снижая безопасность.

Windows: WFP с телеметрией состояний

Современные клиенты используют WFP callouts, которые не просто дропают, а «понимают» состояние туннеля. Если туннель не установлен — состояние «hard block», при установке — «allow via interface». Это уменьшает окна, когда правила еще применяются, а трафик уже пошел. Плюс детальные логи: какой процесс пытался уйти, куда, по какому протоколу — бесценно для расследований.

macOS: NE + PF c атомарными обновлениями

В 2026 многие клиенты переключились на атомарные апдейты PF-якорей: генерируется новый конфиг, грузится в новый якорь, затем аккуратный swap. Нет разрывов, нет гонок. Плюс NE-возможности отслеживания состояния сетей: сменили Wi‑Fi — клиент моментально обновил интерфейс и DNS-скоупы.

Защита от «скрытых» каналов

Некоторые приложения используют QUIC, uTP, встроенные прокси, чтобы «оптимизировать» сеть. Kill switch должен рассматривать их как потенциальные обходы. Решение: блокируем исходящие на всех интерфейсах, кроме VPN, по состоянию сокета, а не по портам; разрешение — только при совпадении интерфейса или марки. Тогда портовая маскировка не помогает обойти политику.

Чек-лист внедрения: шаги, которые не хочется пропускать

Проектирование политики

Определите: тотальный туннель или частичный. Список исключений, если они неизбежны. Требования по DNS (DoH, DoT). Поддерживаемые ОС и версии (Windows 11 24H2+, Linux kernel 6.x, macOS 14+). Сценарии сна, роуминга между Wi‑Fi и Ethernet, мобильной сети.

Техническая реализация

Windows: правила AdvFirewall + WFP; Linux: nftables + policy routing +, при необходимости, eBPF; macOS: NE + PF anchors. Обязательные элементы: блок всего, кроме oif VPN; запрет DNS вне VPN; дефолтный маршрут через туннель; черная дыра для трафика при падении интерфейса.

Тестирование и мониторинг

Сниффер, стресс-тесты реконнекта, логирование процессов, проверка IPv6, проверка DoH, проверка приложений «с характером» (игровые лаунчеры, торренты, корпоративные агенты). Мониторинг: алерты при появлении дефолта не на VPN, уведомления о падении интерфейса, телеметрия попыток обхода.

Эксплуатация и откат

Готовьте «аварийный ключ»: как убрать kill switch, если VPN-клиент погиб и нужно срочно в интернет для фикса. На Windows — заранее скрипт с удалением правил, на Linux — файл с nft flush ruleset и backup конфигом, на macOS — pfctl -d с осторожностью и откат NE-профиля. Делайте это только в офлайн-сценарии или по согласованию, чтобы не сломать безопасность.

Практические команды и примеры: компактная шпаргалка

Windows PowerShell

Добавить блок всего исходящего: New-NetFirewallRule -DisplayName "Block All Outbound" -Direction Outbound -Action Block -Profile Any. Разрешить для интерфейса VPN: New-NetFirewallRule -DisplayName "Allow VPN Outbound" -Direction Outbound -Action Allow -InterfaceAlias "Имя_интерфейса_VPN" -Profile Any. Фикс метрик: Set-NetIPInterface -InterfaceAlias "Имя_интерфейса_VPN" -AutomaticMetric Disabled -InterfaceMetric 5; для физических — 50 и выше.

Linux nftables

Создать таблицу и политику: add table inet vpn; add chain inet vpn output { type filter hook output priority 0; policy drop; }; add rule inet vpn output oifname "wg0" accept; add rule inet vpn output meta oifname "lo" accept; add rule inet vpn output ct state established,related accept. Policy routing: ip rule add fwmark 0x1 table 100; ip route add default dev wg0 table 100. В основной таблице — без дефолта или с blackhole default dev lo.

macOS PF

В pf.conf: set block-policy drop; set skip on lo0; anchor "vpn-killswitch"; в якоре: block out on ! utunX from any to any; pass out on utunX from any to any keep state; block out proto { udp, tcp } to port 53 on ! utunX. Активировать: pfctl -f /etc/pf.conf; pfctl -E. Обновлять utunX при реконнекте клиента.

Диагностика DNS

Windows: Resolve-DnsName с трассировкой; проверяйте, что серверы из Get-DnsClientServerAddress принадлежат VPN. Linux: resolvectl dns и resolvectl status; убедитесь, что интерфейсом указан tun/wg. macOS: scutil --dns — смотрим scoped resolvers; системные сервисы должны указывать utun.

Почему kill switch иногда «вдруг» не срабатывает и как это чинить

Гонки при реконнекте

Если клиент снимает правила до того, как поднялся новый туннель, возникает окно в миллисекунды, иногда секунды. Решение: атомарные транзакции. Сначала держим глобальный блок, затем поднимаем туннель, затем открываем правила на интерфейс. Только так.

Службы ОС с особым статусом

Антивирусы, корпоративные агенты, системные обновления могут иметь привилегии обходить обычные правила. Надо ловить их на уровне ядра: WFP callout для Windows, cgroup-bpf для Linux, NEFilterDataProvider для macOS. Иначе «волшебный» сервис прорежет дырку.

Несогласованность IPv6

Фильтрация только IPv4 — половина дела. В 2026 IPv6 везде. Обязательно проверяйте ::/0, RA, SLAAC, и блокируйте исходящие на физическом интерфейсе по обоим семействам. Таблицы inet в nftables — ваш друг, PF и WFP тоже справятся.

Браузеры и собственный сетевой стек

Некоторые браузеры используют свой DNS-стек, свой QUIC-стек, свои прокси. Выключите «DNS-over-HTTPS всегда», если ваш сценарий не учитывает его туннелирование. Иначе DoH улетит в обход. Лучший вариант — DoH к вашему резолверу внутри VPN и строгий блок всего остального.

Итоги: как понять, что у вас «правильный» kill switch

Признаки зрелой реализации

Нет интернета при падении VPN. Маршрут по умолчанию смотрит в туннель. DNS — только через VPN. IPv6 учтен. Исключения — редкие, точечные и логируются. Проверка сниффером проходит. Сон, роуминг, реконнект — без утечек.

Что дает в реальности

Спокойствие. Реально. Когда вы знаете, что интерфейс дернется — а наружу ни один байт не вылетит — можно работать, смотреть видео, синхронизировать архивы. Не бояться «секунды правды». Kill switch — это предохранитель, который не предает.

Точка действия

Проверьте свою конфигурацию сегодня. Исправьте двойные дефолты. Ужесточите правила. Закройте DNS. И просмотром логов убедитесь: когда VPN молчит, трафик тоже молчит. Тогда все остальное — уже детали.

FAQ: частые вопросы про VPN kill switch

Можно ли сделать kill switch без прав администратора?

Надежно — нет. Нужны права на изменение маршрутов и фаервола. Иначе это игрушка, а не защита.

Чем отличается kill switch от просто «блокировать интернет при разрыве» в клиенте?

Правильный kill switch живет в ядре и фаерволе. «Просто блокировать» в приложении опаздывает и проигрывает гонки. Нужны WFP, nftables, PF.

Если у меня split-tunnel, kill switch теряет смысл?

Нет. Он все равно блокирует неразрешенный трафик. Но риски растут: сплит — сложнее и требует точной настройки.

Нужно ли блокировать IPv6, если провайдер его не дает?

Да. Приложения могут создать локальные IPv6-сессии через соседние сети. Блокируйте по обоим стеклам.

Как проверить, что DoH не уходит мимо VPN?

Сниффер на физическом интерфейсе и политики фаервола: разрешить DoH только через интерфейс VPN, остальное — drop.

WireGuard сам по себе дает kill switch?

Почти. Если AllowedIPs = 0.0.0.0/0, ::/0 и правильно настроены маршруты. Но без фаервола окна утечек при реконнекте все равно возможны. Нужны правила drop вне wg.

Почему при падении VPN у меня остается доступ к локальной сети?

Так настроены правила. Разрешение на link-local и LAN бывает нужно. Если хотите жестче — блокируйте и их, но будьте готовы потерять принтеры и шаринг.