Kill switch для отдельных приложений против блокировки всего устройства: что меняется
Решайте по защищённому набору, а не по ярлыку: что останавливается для исключённых приложений, фоновых помощников и новых подключений, и как проверить каждый случай.
Kill switch для отдельных приложений звучит как осторожный выбор: при падении туннеля сеть теряет только рабочий клиент, а всё остальное продолжает работать. Потом кто-то замечает, что личный браузер всё-таки загрузил страницу, помощник синхронизации из того же пакета продолжал пытаться, а кэшированное имя по-прежнему разрешалось в адрес, который ни разу не касался туннеля. Ярлык на функции и набор соединений, которые она действительно защищает, — две разные вещи. Сначала определите защищённый набор, потому что именно он решает, что будет честным описанием: применение по приложениям или блокировка всего устройства.
Начните с набора, а не с ярлыка
Политика по приложениям защищает выбранные приложения. Блокировка устройства нацелена на более широкую сетевую границу, обычно с документированными исключениями для локальной печати, управляющего трафика или captive-порталов. Ни один ярлык не полон, пока вы не ответите на три вопроса: что происходит с исключёнными приложениями, что происходит с помощниками, которые эти приложения запускают, и что происходит с соединениями, открытыми пока защита недоступна.
Запишите эти ответы, прежде чем трогать любую настройку клиента. Если требование звучит как "этот зарплатный клиент никогда не должен говорить с интернетом вне туннеля, а мой браузер может", набор мал и применение по приложениям подходит. Если требование звучит как "ничто на этом устройстве не выходит в интернет без защиты, кроме службы обновлений", никакая политика по приложениям этого не даст, потому что проблема — приложения, которые вы не назвали.
Применение по приложениям сопоставляет идентификаторы, а не имена программ
Android предоставляет VPN по приложениям через пакеты, и его документация VpnService описывает, как это взаимодействует с режимом постоянного включения и блокировкой. iOS настраивает VPN по приложениям через профиль управления и сопоставляет по приложению или по домену. В Windows и Linux маршрута по процессу нет вообще, поэтому ту же идею приближают правилом брандмауэра, ограниченным программой, или правилом, которое сопоставляется с пользователем-владельцем.
Граница — это идентификатор, а идентификаторы легко обойти. Приложение, которое передаёт URL системному браузеру или открывает документ в просмотрщике, переходит в процесс, который ваша политика никогда не называла. Опция завершения при обрыве тоже не является фильтром пакетов: она убивает настроенное приложение, тогда как дочерний процесс, обработчик очереди или вкладка браузера могут сохранить существующий сокет живым.
Блокировка охватывает то, чего политика по приложениям не видит
Блокировка всего устройства убирает выбор. Каждый исходящий пакет, не принадлежащий туннелю, отбрасывается, включая трафик процессов, о которых ваша политика приложений никогда не знала. В Android это постоянно включённый VPN вместе с настройкой блокировки соединений, и применение происходит в системе, а не в окне клиента. На настольном компьютере это постоянное правило брандмауэра или маршрут по умолчанию, указывающий на недостижимый шлюз.
Цена в том, что всё остальное останавливается, поэтому исключения становятся частью замысла, а не поздней мыслью. Локальные принтеры, обнаружение служб, вход на captive-порталы, агенты управления и обновления ОС — каждому нужна документированная дыра, потому что каждый из них остаётся открытым путём, когда туннель не работает. Блокировка лишь настолько сильна, насколько коротка самая короткая запись в этом списке.
DNS, IPv6 и фоновые помощники скрывают утечки
То, что защищённое приложение не может разрешить имя, не доказывает, что кэшированные ответы или прямой IP-трафик блокируются. Если распознаватель всё ещё доступен вне туннеля, имя разрешается, а соединение терпит неудачу, что выглядит как работающий kill switch и таковым не является. Хуже того, кэшированная запись может указывать на адрес, который туннель не несёт, поэтому соединение уходит напрямую, пока приложение сообщает об ошибке VPN.
IPv6 требует собственного правила на каждой платформе, которая его использует, потому что правило отбрасывания для v4 не покрывает маршрут v6. На мобильном настройка приватного DNS может перенести разрешение в зашифрованный канал, который политика устройства не проверяет. А фоновые помощники — обычный виновник на настольном компьютере: процесс обновления или синхронизации в трее стартует раньше VPN-клиента и держит собственное соединение, поэтому никогда не видит изменённый маршрут.
Проверьте три приложения и два перехода
| Test | What it proves |
|---|---|
| Included app, by name and by direct IP | the policy is applied, not just the resolver |
| Excluded app, same checks | the exclusion is intentional and documented |
| Helper or updater process | nothing inherited an older route |
| Tunnel drop, then Wi-Fi to cellular | the block survives the transition |
Запустите каждую строку дважды: один раз с именем хоста и один раз с буквальным адресом, и ещё раз по IPv6, если сеть это предлагает. Прохождение означает, что включённое приложение остановилось, исключённое вело себя так, как вы записали, а помощник не выскользнул. Запишите прямое поведение, которое вы сочли приемлемым, чтобы следующий администратор отличил намеренное исключение от сбоя.
Затем опишите результат одним предложением, называющим приложения и условия, например: у зарплатного клиента нет маршрута вне туннеля, браузер намеренно прямой, а всё остальное останавливается, когда туннель не работает. Если это предложение трудно написать, политика всё ещё представляет собой две политики, воюющие друг с другом.