Почему kill switch обрывает трафик при смене сервера

Вы выбираете сервер, который кажется ближе, нажимаете подключиться, и браузер перестаёт загружать ещё до того, как поднимется новый туннель. Значок переходит в состояние подключения и остаётся там, пока каждая вкладка не исчерпает время. Эта пауза обычно и есть kill switch, работающий как задумано: трафик блокируется, пока у клиента нет туннеля, через который его отправить. Приемлема ли пауза, зависит от того, что клиент делает в эти секунды, и от того, снимается ли блокировка, когда он говорит, что снята.

Что клиент делает между двумя серверами

Смена конечной точки — это несколько шагов, а не один переключатель. Клиент разбирает текущий туннель, обновляет свои правила блокировки, разрешает и достигает новую конечную точку вне туннеля, затем устанавливает новые маршруты и снимает блокировку. Провал, который вы чувствуете, находится между первым и последним шагом.

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

Новой конечной точке нужна дыра в блокировке

Чтобы построить туннель, клиент должен отправлять пакеты на адрес и порт нового сервера через физический интерфейс, например UDP 51820 для типичного профиля WireGuard или 1194 и 443 для OpenVPN, что бы ни указывал ваш собственный профиль. Этот трафик не находится внутри туннеля, который вот-вот будет создан, поэтому блокировка для всего устройства его проглатывает, если нет подходящего правила разрешения.

Профили на основе имени хоста добавляют второе требование: сам поиск. Если клиент разрешает конечную точку до поднятия блокировки, он может использовать адрес из кеша, но когда профиль меняет адреса или запись в кеше устаревает, рукопожатие уходит на адрес, который правило разрешения не покрывает. IPv6 делает это заметным, потому что конечная точка с двойным стеком может публиковать и запись A, и запись AAAA, а правило разрешения, покрывающее только адрес v4, оставляет клиента повторять попытки против заблокированного адреса v6.

Названия параметров и значения по умолчанию различаются в зависимости от клиента и версии, поэтому читайте документированный список для своего, а не угадывайте по скриншотам. Справочник настроек OpenVPN Connect по адресу openvpn.net/connect-docs/app-settings-windows — один из примеров того, как клиент описывает свои параметры блокировки и раздельного туннеля.

Fail-closed — это машина состояний, а не переключатель

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

Механизм различается по платформам, и сбой тоже. Фильтры Windows Filtering Platform имеют веса, поэтому блокирующий фильтр, перевешивающий ваше разрешение, продолжает отбрасывать пакеты, хотя разрешение существует, а фильтры, оставленные убитым процессом клиента могут держать машину без сети после того, как приложение исчезло. Клиенты macOS обычно записывают правила pf в якорь, где порядок правил и быстрые решения определяют, какое правило применяется. Клиенты Linux обычно управляют цепочкой nftables или iptables с политикой drop и явными разрешениями для конечной точки, интерфейса туннеля и loopback. Режим always-on VPN в Android с опцией блокировки соединений без VPN — самый строгий в группе, потому что система применяет блокировку ко всему устройству, а не к отдельному приложению.

WireGuard заслуживает отдельной заметки, потому что AllowedIPs — это селектор маршрутизации, а не блокировщик. Он решает, какие назначения попадают в туннель; он ничего не делает, чтобы пакет без туннеля не вышел через Wi-Fi. В конфигурации только с WireGuard и без правила брандмауэра kill switch на самом деле является отсутствием маршрута, и после отброшенного рукопожатия через физический интерфейс может уйти настоящий пакет.

Измеряйте провал, а не смотрите на значок

Следите за пакетами, а не за лампочкой состояния. В Linux запустите в одном терминале медленный ping до публичного адреса, а в другом перехватите транспортный порт туннеля на физическом интерфейсе:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

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

В Windows netsh wfp show state записывает снимок, в котором можно искать блокирующие фильтры, всё ещё присутствующие, пока клиент утверждает, что отключён. В macOS sudo pfctl -sr перечисляет загруженные правила и их порядок. Сопоставьте любой снимок с собственным журналом клиента; хронология вашего ping скажет, закончилась ли блокировка поздно или не закончилась никогда.

Обычное затемнение против зависшей блокировки

Некоторая пауза и есть смысл этой функции, поэтому сначала оцените ситуацию, а потом меняйте любую настройку:

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

Перед следующим переключением подтвердите четыре вещи: разрешение для конечной точки покрывает каждое семейство адресов, которое разрешает ваш профиль, журнал клиента показывает завершённый переход, ваш ping-тест измеряет провал, а не значок, и закрытие клиента восстанавливает обычное соединение. Kill switch, который держится во время переключения и отпускает после, делает свою работу. Тот, что отпускает рано или никогда, стоит отладки.