Почему раздельное туннелирование не покрывает обновления вашего приложения

Вы добавляете приложение в список исключений раздельного туннелирования, приложение выходит в интернет напрямую, а обновления всё равно срываются или всё равно ползут через туннель. Исключение сработало. Оно просто охватило другой процесс, а не тот, который выполняет загрузку, потому что современный обновлятор редко является тем же исполняемым файлом, что и окно приложения.

Миф: исключение приложения исключает его трафик

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

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

Найдите владельца передачи

В Android обновление может загружаться общим пакетом службы, а не тем пакетом приложения, который вы исключили, и правило VPN для отдельного приложения применяется к пакету, открывающему сокет. В Windows служба обновления может работать по другому исполняемому пути, чем приложение, поэтому правило, совпадающее с путём приложения, её не задевает. В macOS привилегированный помощник или системный демон обновлений может выполнять передачу, пока приложение только запрашивает её.

Определите владельца по доказательствам: представление сетевой активности платформы, перехват пакетов с фильтром по процессу или документация поставщика, где назван компонент обновления. Догадки по имени процесса — это путь к путанице двух похожих бинарных файлов и исключению неверного.

Системы обновления часто делят работу. Небольшой запрос метаданных проверяет версию, а гораздо большая загрузка пакета уходит на хост доставки контента или на другой домен. Проверка метаданных может пройти через туннель, тогда как передача пакета застревает на хосте, который туннель маршрутизирует иначе. Это разделение объясняет запутанный отчёт, где обновления обнаруживаются, но никогда не устанавливаются. Проверяйте саму загрузку пакета, с того же устройства и той же сети, а не то, открывается ли приложение.

Проверка переживает смену маршрута

Смена маршрута не заменяет TLS, идентичность издателя или проверку подписи пакета. Не отключайте эти проверки из-за того, что загрузка удаётся только после того, как вы прошли необъяснимое предупреждение о сертификате. Предупреждение, которое появляется только на исключённом пути, — это находка, а не препятствие. Исследуйте его, прежде чем расширять обход.

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

Проверьте обновление, затем задокументируйте владельца

После изменения подключитесь заново и ещё раз проверьте применённое правило, потому что некоторые клиенты перестраивают маршрутизацию при переподключении туннеля. Выполните один полный цикл обновления: проверка, загрузка, подтверждение и установка. Успешная проверка доказывает только малую часть пути.

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