Proč rozdělené tunelování nepokrývá aktualizace vaší aplikace

Přidáte aplikaci do seznamu výjimek rozděleného tunelování, aplikace se dostane na internet přímo, a aktualizace přesto selhávají nebo se stále plazí tunelem. Výjimka fungovala. Jen pokryla jiný proces než ten, který provádí stahování, protože moderní aktualizátor je málokdy stejný spustitelný soubor jako okno aplikace.

Mýtus: vyloučení aplikace vylučuje její provoz

Rozdělené tunelování podle aplikací páruje proces, balíček nebo cestu aplikace v závislosti na platformě. Nepáruje značku, funkci ani záměr uživatele. Když aplikace předá stahování pomocníkovi, sdílené službě platformy nebo komponentě prohlížeče, má tento pomocník vlastní identitu a vlastní cestu tunelem. Seznam výjimek netuší, že oba procesy patří ke stejnému produktu. Ví jen, který z nich jste pojmenovali.

Pravidlo tedy dělá přesně to, co mu bylo řečeno. Předpoklad o tom, kdo vlastní přenos, byl chybný, a oprava začíná identifikací tohoto vlastníka, ne přidáváním dalších výjimek.

Najděte vlastníka přenosu

V Androidu může aktualizaci stáhnout sdílený balíček služby místo balíčku aplikace, který jste vyloučili, a pravidlo VPN pro jednotlivé aplikace platí pro balíček, který otevírá socket. Ve Windows může služba aktualizace běžet pod jinou spustitelnou cestou než aplikace, takže pravidlo odpovídající cestě aplikace ji mine. V macOS může přenos provést privilegovaný pomocník nebo systémový démon aktualizací, zatímco aplikace jej pouze požaduje.

Určete vlastníka podle důkazů: pohled na síťovou aktivitu platformy, zachycení paketů filtrované podle procesu nebo dokumentace dodavatele, která pojmenovává komponentu aktualizace. Hádání podle názvu procesu je způsob, jak se dva podobné binární soubory zamění a vyloučí se ten špatný.

Aktualizační systémy také často práci rozdělují. Malý požadavek na metadata ověřuje verzi a mnohem větší stažení balíčku jde na hostitele pro doručování obsahu nebo na jinou doménu. Kontrola metadat může tunelem projít, zatímco přenos balíčku uvízne na hostiteli, který tunel směruje jinak. Toto rozdělení vysvětluje matoucí hlášení, kdy jsou aktualizace zjištěny, ale nikdy nainstalovány. Testujte samotné stažení balíčku, ze stejného zařízení a stejné sítě, místo toho, zda se aplikace otevře.

Ověřování přežije změnu trasy

Změna trasy nenahrazuje TLS, identitu vydavatele ani ověření podpisu balíčku. Nevypínejte tyto kontroly proto, že stahování uspěje jen poté, co prokliknete nevysvětlené varování o certifikátu. Varování, které se objeví jen na vyloučené trase, je zjištění, ne překážka. Prošetřete je, než rozšíříte obchvat.

Na spravovaném zařízení požádejte o podporovanou výjimku místo přidání širokého pravidla pro každou systémovou službu. Pravidlo, které vyloučí všechny sdílené služby, aby opravilo jeden aktualizátor, rozšíří obchvat daleko za původní požadavek.

Otestujte aktualizaci a poté zdokumentujte vlastníka

Po změně se znovu připojte a znovu ověřte použité pravidlo, protože někteří klienti při opětovném připojení tunelu přestavují své směrování. Proveďte jeden celý cyklus aktualizace: kontrola, stažení, ověření a instalace. Úspěšná kontrola dokazuje jen nejmenší část cesty.

Zaznamenejte vlastníka přenosu, cílové hostitele a zamýšlenou trasu na stejné místo jako pravidlo rozděleného tunelování. Jinak další změna mechanismu aktualizací výjimku tiše zneplatní a ten, kdo ji zdědí, nebude mít jak zjistit, pro který proces bylo pravidlo napsáno.