Fail-open или fail-closed: что решает kill switch в VPN
Оба термина описывают, что происходит после исчезновения туннеля, а не то, насколько сильное шифрование. Выбранный охват решает, утекает ли трафик на самом деле.
Миф в том, что fail-closed — безопасная настройка, а fail-open — небрежная. Оба описывают, что происходит с трафиком после исчезновения туннеля, и ни один не меняет, насколько хорошо этот туннель шифрует. Политика fail-closed с длинным списком исключений может утекать больше, чем политика fail-open на устройстве, которое никогда не покидает офисную сеть. Выберите результат, который сможете объяснить владельцу трафика.
Ярлык описывает результат, а не силу
Словарь пришёл из систем управления: fail-open разрешает работу при отказе компонента, fail-closed запрещает её. В применении к VPN отказывающий компонент — это туннель, и вопрос в том, разрешено ли трафику продолжиться другим путём. Выбор шифра, длина ключа и протокол — отдельные решения.
Путаница держится потому, что kill switch звучит как функция безопасности, и поставщики так его и продают. Механически это правило маршрутизации и брандмауэра, которое блокирует трафик, который туннель должен был нести, реализованное в клиенте, в операционной системе или на шлюзе. Какой бы уровень его ни исполнял, он же определяет и его охват, а правило на одном уровне не покрывает другой. Правило на шлюзе не может защитить ноутбук, который уже перешёл в другую сеть.
Как выглядит каждый результат
Одна и та же политика может вести себя очень по-разному в зависимости от того, на какой сбой вы наткнётесь, поэтому сравнивайте события, а не ярлыки.
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
Последняя строка ловит тех, кто считает, что kill switch — это один переключатель. Правило, написанное для таблицы маршрутов IPv4, оставляет маршрут по умолчанию IPv6 нетронутым, и приложение может спокойно им пользоваться.
Охват решает, будет ли утечка
Спросите, что покрывает политика, прежде чем спрашивать, какой это режим. Правило для одного приложения защищает одно приложение и ничего больше, правило для всего устройства защищает всё, кроме исключений, а правило на шлюзе защищает только трафик, доходящий до этого шлюза. DNS нуждается в собственном решении, потому что запрос к локальному резолверу может раскрыть имена даже при заблокированной полезной нагрузке.
Исключения для локальной сети существуют ради принтеров, трансляции экрана и порталов входа, и каждое из них — дыра в блокировке. Документируйте их рядом с политикой, иначе человек, унаследовавший конфигурацию, прочтёт fail-closed как абсолют.
Переподключение и блокировка — тоже отдельные средства управления. Клиент может автоматически переподключаться, никогда не блокируя, или блокировать без переподключения, и сочетание определяет, что переживает пользователь во время сбоя.
Докажите это во время перехода
Проверка устойчивого состояния ничего не доказывает. Намеренно оборвите туннель и попробуйте приложение, которое должно быть защищено, затем проверьте, дошло ли оно до сети. Сравните индикатор клиента с результатом, потому что индикатор, который всё ещё говорит «подключено», — это ровно тот случай, для которого существует политика. Если защищённое приложение добивается успеха, название режима не имеет значения; у вас утечка.
Повторите с холодной загрузки до входа в систему, при переключении с Wi-Fi на мобильную сеть и с защищённым приложением в фоне. Если блокировку исполняет процесс клиента, проверьте также, что происходит, когда этот процесс убивают, а не закрывают аккуратно.
Наконец, проверьте путь очистки. Если клиент удаляют, пока его правила активны, используйте документированную поставщиком процедуру удаления, а не отключайте брандмауэр операционной системы, который снимает постороннюю защиту, не отвечая на вопрос, кому принадлежит оставшееся правило.