Защо разделеното тунелиране не покрива актуализациите на приложението ви

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

Митът: изключването на приложението изключва трафика му

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

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

Открийте собственика на трансфера

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

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

Системите за актуализации често разделят и работата. Малка заявка за метаданни проверява за версия, а много по-голямото изтегляне на пакет отива към хост за доставка на съдържание или различен домейн. Проверката на метаданните може да успее през тунела, докато трансферът на пакета засяда на хост, който тунелът маршрутизира различно. Това разделяне обяснява объркващия отчет, при който актуализациите се откриват, но никога не се инсталират. Тествайте самото изтегляне на пакета, от същото устройство и същата мрежа, вместо да тествате дали приложението се отваря.

Проверката оцелява при промяна на маршрута

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

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

Тествайте актуализацията, после документирайте собственика

Свържете се отново след промяната и проверете отново приложеното правило, защото някои клиенти преизграждат маршрутизацията си при повторно свързване на тунела. Изпълнете един пълен цикъл на актуализация: проверка, изтегляне, проверка и инсталиране. Успешната проверка доказва най-малката част от пътя.

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