Kill switch продолжает блокировать трафик после отключения VPN

Туннеля нет, значок сети выглядит обычно, а ничего не загружается. Вы отключили VPN, удалили его или перезагрузились, а блокировка, которая должна была защитить вас при обрыве, всё ещё стоит. Окно клиента этого не объяснит, потому что блокирует не клиент: решение было записано в ядро от вашего имени, и ничего не осталось, чтобы его убрать. В Windows это состояние находится в Windows Filtering Platform; в Linux это набор правил в iptables или nftables, часто со снимком, который воспроизводится при загрузке. Далее — порядок, которым пользуюсь я: прочитать состояние, удалить самый узкий объект, объясняющий сбой, затем найти то, что постоянно возвращает его на место.

Kill switch — это состояние ядра, а не настройка

Настольные клиенты реализуют блокировку, добавляя фильтры, запрещающие трафик вне туннеля. В Windows это фильтры WFP на уровнях connect-redirect и transport, и некоторые из них постоянные: они записываются в хранилище политик Base Filtering Engine и восстанавливаются при загрузке машины, до запуска любого VPN-ПО. Клиенты различаются тем, когда убирают за собой. Одни удаляют фильтры при отключении, другие только при чистом выходе, а третьи только если сначала выключить переключатель. Удалите программу, пока блокировка активна, или убейте процесс, и фильтры останутся.

Эквивалент в Linux — правило drop или reject в исходящем пути, иногда правило forwarding, иногда изменённая политика цепочки. Эти правила переживают процесс, добавивший их, потому что это состояние ядра: убейте клиент, уроните его или отключите питание, и ядро продолжит отбрасывать пакеты, а отменить это будет нечем. Пакет сохранения добавляет второй слой постоянства: делает снимок текущего набора правил и восстанавливает его при загрузке, поэтому следующий запуск начинается с уже установленной блокировкой.

Прочитайте состояние WFP, прежде чем что-то удалять

Windows поставляется с нужными инструментами. Запустите консоль с правами администратора и выгрузите состояние платформы; дамп появится как wfpstate.xml в рабочем каталоге.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Ищите в XML имя ушедшего поставщика, действие Block и уровень. Фильтры на connect-redirect и transport — те, что ломают обычный трафик; фильтр на уровне receive-accept обычно не ваша причина. Если Base Filtering Engine вообще не работает, ищите в другом месте, потому что больше ничто не может применять эти фильтры.

Проверьте и обычный вид брандмауэра, ведь большинство смотрит только один из двух:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Когда встроенные профили включены и ни одно правило не совпадает с отказавшим трафиком, блокировка идёт от стороннего поставщика, а не от Windows Firewall. Это различие и решает, каким инструментом вы будете чинить.

Читайте правила Linux в том синтаксисе, которым будете удалять

iptables -S печатает правила в той же форме, в какой они добавлялись, поэтому вывод можно сразу использовать для удаления. iptables -L -v -n добавляет счётчики пакетов, и эти счётчики говорят, действительно ли правило совпадает с вашими неудачными запросами или просто стоит в цепочке.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Читайте политики цепочек, а не только правила: -P OUTPUT DROP блокирует трафик, даже когда ни одно правило не совпадает. Проверяйте IPv6 отдельно, потому что клиент, устанавливающий оба семейства, может оставить блокировку IPv6 после исчезновения правил IPv4, и тогда симптом зависит от того, какое семейство предпочитает приложение. Там, где используется nftables, запустите и nft list ruleset; два инструмента сосуществуют через слой совместимости, и один список не обязательно показывает каждое правило, способное отбросить пакет.

Удалите самый узкий объект, объясняющий сбой

В Windows первый шаг по-прежнему — путь удаления от самого поставщика: запустите установщик заново и используйте repair или uninstall, либо запустите средство очистки, если поставщик его публикует. Оставшиеся службы и задачи планировщика — обычное дело, а задача, запускающая клиент при входе, переустанавливает его фильтры при следующей загрузке. Удаление, которое падает при чтении ключа реестра клиента, обычно означает, что служба или задача всё ещё держит его, а не что реестр испорчен.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Постоянные фильтры — крайняя мера. Они лежат под HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, по одному значению на фильтр с ключом GUID. Сначала экспортируйте ключ, запишите удаляемые GUID, удаляйте только значения, принадлежащие ушедшему клиенту, затем перезагрузитесь, чтобы движок перестроил состояние. Не удаляйте весь ключ и не отключайте Base Filtering Engine: Windows Firewall и Defender зависят от него, и вы обменяли бы один сбой на более худший.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

В Linux возьмите строку, которую напечатал iptables -S, и замените -A на -D. Удалить одно найденное правило лучше, чем очистить цепочку, потому что ваша собственная политика остаётся нетронутой.

sudo iptables -D OUTPUT -p udp -j REJECT

Если drop находится в определяемой пользователем цепочке, сначала удалите переход в эту цепочку, а затем удалите цепочку через -X. Установка политики цепочки в ACCEPT, пока правила drop ещё на месте, помогает только пакетам, которые вообще доходят до решения по политике. Очистка всех таблиц — крайняя мера: она удаляет и правила, добавленные вами по другим причинам, а при включённом ufw оставляет службу в уверенности, что она владеет цепочками, которых больше нет.

Найдите владельца, который возвращает это на место

После немедленного ремонта поищите то, что восстановило бы состояние. В Linux проверьте, включён ли модуль сохранения, есть ли у клиента настройка восстановления брандмауэра при входе и существует ли сохранённый файл правил под /etc. В Windows снова проверьте элементы автозагрузки, службы и задачи планировщика, затем перезагрузитесь и перечитайте состояние теми же командами, что и раньше.

Если блокировка возвращается, удаление не было решением; решением был владелец. Запишите, какой клиент или служба устанавливает её, и отключите функцию там, вместо того чтобы бороться с ней на уровне брандмауэра после каждого отключения.

Проверяйте реальным трафиком, а не одним ping

Проверьте разрешение имени, TCP-соединение и новую сессию браузера, затем перезагрузитесь и повторите те же три проверки. Ping, который работает, пока HTTPS не работает, указывает на фильтр транспортного уровня, а не на сеть, а блокировка, появляющаяся снова только после перезагрузки, указывает на владельца, которого вы ещё не нашли.

Сохраните доказательства: экспортированный ключ BFE или вывод iptables -S, снятый до изменения. Прежде чем называть это исправленным, подтвердите уровень, с которого вы удалили объект, владельца, который мог бы установить его заново, состояние после одной чистой перезагрузки и то, что обычный просмотр работает без запущенного процесса VPN. Страница руководства iptables(8) содержит точный синтаксис удаления и политики, если вы пишете очистку скриптом.