Miért nem fedi le az osztott alagút az alkalmazásod frissítéseit

Hozzáadod az alkalmazást az osztott alagút kizárási listájához, az alkalmazás közvetlenül éri el az internetet, és a frissítések továbbra is meghiúsulnak, vagy továbbra is átkúsznak az alagúton. A kizárás működött. Csak egy másik folyamatot fedett le, mint amely a letöltést végzi, mert egy modern frissítő ritkán ugyanaz a futtatható fájl, mint az alkalmazás ablaka.

A mítosz: az alkalmazás kizárása kizárja a forgalmát

Az alkalmazásonkénti osztott alagút egy folyamatot, egy csomagot vagy egy alkalmazásútvonalat párosít, a platformtól függően. Nem párosít márkát, funkciót vagy felhasználói szándékot. Amikor az alkalmazás átadja a letöltést egy segédprogramnak, egy megosztott platformszolgáltatásnak vagy egy böngészőösszetevőnek, annak a segédprogramnak saját identitása és saját útvonala van az alagúton át. A kizárási listának fogalma sincs arról, hogy a két folyamat ugyanahhoz a termékhez tartozik. Csak azt tudja, melyiket nevezted meg.

Tehát a szabály pontosan azt teszi, amit mondtak neki. A feltételezés arról, ki birtokolja az átvitelt, téves volt, és a javítás e tulajdonos azonosításával kezdődik, nem további kizárások hozzáadásával.

Találd meg az átvitel tulajdonosát

Androidon előfordulhat, hogy a frissítést egy megosztott szolgáltatáscsomag tölti le, nem az a csomag, amelyet kizártál, és az alkalmazásonkénti VPN-szabály arra a csomagra vonatkozik, amely megnyitja a socketet. Windowson a frissítőszolgáltatás az alkalmazástól eltérő futtatható útvonal alatt futhat, így az alkalmazás útvonalához illeszkedő szabály elvéti. macOS-en egy kiemelt segédprogram vagy egy rendszerfrissítő démon végezheti az átvitelt, miközben az alkalmazás csak kéri azt.

Azonosítsd a tulajdonost bizonyítékok alapján: a platform hálózati tevékenységnézete, folyamat szerint szűrt csomagrögzítés vagy a gyártó dokumentációja, amely megnevezi a frissítő összetevőt. A folyamat nevéből való találgatás az az út, amelyen két hasonló bináris fájl összekeveredik, és a rosszat zárják ki.

A frissítőrendszerek gyakran megosztják a munkát is. Egy kis metaadat-kérés verziót ellenőriz, és egy sokkal nagyobb csomagletöltés egy tartalomkiszolgáló hoszthoz vagy egy másik domainhez megy. A metaadat-ellenőrzés sikerülhet az alagúton át, miközben a csomagátvitel elakad egy hoszton, amelyet az alagút másképp irányít. Ez a felosztás magyarázza azt a zavaró jelentést, amelyben a frissítéseket észlelik, de soha nem telepítik. Magát a csomagletöltést teszteld, ugyanarról az eszközről és ugyanarról a hálózatról, ahelyett hogy azt tesztelnéd, megnyílik-e az alkalmazás.

Az ellenőrzés túléli az útvonalváltozást

Az útvonal megváltoztatása nem helyettesíti a TLS-t, a kiadó identitását vagy a csomagaláírás ellenőrzését. Ne kapcsold ki ezeket az ellenőrzéseket csak azért, mert egy letöltés csak egy megmagyarázatlan tanúsítványfigyelmeztetés átkattintása után sikerül. Az a figyelmeztetés, amely csak a kizárt útvonalon jelenik meg, lelet, nem akadály. Vizsgáld ki, mielőtt kiszélesítenéd a megkerülést.

Kezelt eszközön támogatott kivételt kérj, ahelyett hogy széles szabályt adnál minden rendszerszolgáltatáshoz. Az a szabály, amely minden megosztott szolgáltatást kizár egy frissítő javításához, messze az eredeti kérésen túl szélesíti a megkerülést.

Teszteld a frissítést, majd dokumentáld a tulajdonost

A változtatás után csatlakozz újra, és ellenőrizd ismét az alkalmazott szabályt, mert egyes kliensek újraépítik az útválasztásukat, amikor az alagút újracsatlakozik. Futtass le egy teljes frissítési ciklust: ellenőrzés, letöltés, ellenőrzés és telepítés. Egy sikeres ellenőrzés csak az útvonal legkisebb részét bizonyítja.

Rögzítsd az átvitel tulajdonosát, a célhosztokat és a tervezett útvonalat ugyanott, ahol az osztott alagút szabálya van. Különben a frissítési mechanizmus következő változása csendben érvényteleníti a kivételt, és aki örökli, annak semmilyen módja nem lesz megtudni, melyik folyamathoz írták a szabályt.