Чому роздільне тунелювання не покриває оновлення вашого застосунку

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

Міф: виключення застосунку виключає його трафік

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

Отже, правило робить саме те, що йому сказали. Припущення про те, кому належить передавання, було хибним, і виправлення починається з визначення цього власника, а не з додавання нових винятків.

Знайдіть власника передавання

В Android оновлення може завантажувати спільний пакет служби, а не той пакет застосунку, який ви виключили, і правило VPN для окремого застосунку застосовується до пакета, що відкриває сокет. У Windows служба оновлення може працювати за іншим виконуваним шляхом, ніж застосунок, тому правило, що збігається зі шляхом застосунку, її не зачіпає. У macOS привілейований помічник або системний демон оновлень може виконувати передавання, поки застосунок лише запитує його.

Визначте власника за доказами: подання мережевої активності платформи, перехоплення пакетів із фільтром за процесом або документація постачальника, де названо компонент оновлення. Здогадки за назвою процесу — це шлях до плутанини двох схожих двійкових файлів і виключення неправильного.

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

Перевірка переживає зміну маршруту

Зміна маршруту не замінює TLS, ідентичність видавця або перевірку підпису пакета. Не вимикайте ці перевірки через те, що завантаження вдається лише після того, як ви пройшли непояснене попередження про сертифікат. Попередження, яке з’являється лише на виключеному шляху, — це знахідка, а не перешкода. Дослідіть його, перш ніж розширювати обхід.

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

Перевірте оновлення, потім задокументуйте власника

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

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