Androidos alkalmazásonkénti VPN és Chrome inkognitó: mit fed le a szabály

Valaki készített egy automatizálást, amely bekapcsolja a VPN-t, amikor megjelenik egy inkognitó lap, és ez nem működik megbízhatóan. Ennek szerkezeti oka van, és érdemes megérteni, mielőtt az automatizálást hangolja. Az Android alkalmazásonkénti VPN-szabályai alkalmazáscsomagokat választanak, az inkognitó pedig egy csomagon belüli állapot, ezért a szabály nem tudja megkülönböztetni a kettőt. Az értesítés azután indul, hogy a böngésző már elkezdett dolgozni, ezért még a helyes kiváltó is elkésik. Haladjon végig az alábbi ellenőrzéseken sorrendben; a negyedik ellenőrzés kudarca azt jelenti, hogy a megközelítést, nem a konfigurációt kell megváltoztatni.

Első ellenőrzés: erősítse meg, mit választhat az alkalmazásonkénti szabály

Az Android VPN-alkalmazás engedélyezett vagy tiltott alkalmazáslistákkal építi az alagútját, és ezek a listák csomagneveket fogadnak. A Chrome normál módban és a Chrome inkognitó módban ugyanaz a csomag, ugyanazzal a felhasználói azonosítóval és ugyanazzal a hálózati engedéllyel, ezért a Chrome-ot tartalmazó vagy kizáró szabály mindkettőre azonosan vonatkozik. A platformnak nincs lapszintű identitása, amihez illeszteni lehetne.

Ez nem kikerülendő hiba; ez az a részletesség, amit az API kínál. Ha a követelménye a Chrome forgalma az alagúton és minden más kívül, az alkalmazásonkénti szabály pontosan ezt fejezi ki. Ha a követelménye az, hogy csak a privát lapok menjenek az alagúton, míg a normál lapok közvetlenül, akkor egyetlen alkalmazásonkénti szabály sem tudja ezt kifejezni, és az értesítési logika semmilyen mennyisége nem ad hozzá olyan választót, amivel a platform nem rendelkezik.

Figyeljen a csomagidentitás csapdájára az ellenőrzés során. Egy béta vagy egy gyártói build más csomag, mint a stabil böngésző, ezért az egyiket lefedő szabály csendben kihagyja a másikat:

adb shell pm list packages | grep -i chrome

Második ellenőrzés: tesztelje, lehet-e valaha elég korai a kiváltó

Az értesítésfigyelő azokat az értesítéseket figyeli, amelyeket láthat. A megfigyelés nem elfogás: a böngésző már feloldotta a nevet és megnyitotta a kapcsolatot, mire az értesítés létezik, és ezen az úton semmi nem vár arra, hogy az automatizálás befejeződjön. Egy feladat, amely ezután elindítja a VPN-klienst, kénytelen várni a kliens felületére, az esetleges hozzájárulási kérésre és az alagút kézfogására, amelyeket másodpercekben mérnek, míg az első kérést milliszekundumokban.

Maga az észlelés egy második okból is törékeny. Az értesítés szövege verziók és lokalizációk között változik, ezért az egyik kiadáshoz illesztett minta frissítés után már nem illeszkedik, és a hiba csendes. Egy hiányzó értesítés nem bizonyíték arra, hogy nincs privát böngészés; csak azt jelentheti, hogy a karakterlánc megváltozott vagy a csatorna elnémult.

Ennek a munkafolyamatnak van legitim változata, és az rendezett, nem reaktív: először csatlakoztassa a jóváhagyott VPN-t, erősítsen meg egy készültségi jelet, amely valóban bizonyítja, hogy az alagút forgalmat szállít, majd nyissa meg az inkognitó munkamenetet a támogatott böngészővezérlőkkel, és álljon le, ha a készültségi ellenőrzés meghiúsul. Ez védi a hamarosan induló munkamenetet anélkül, hogy azt színlelné, egy már futót véd.

Harmadik ellenőrzés: auditálja az engedélyt, amelyet adni készül

Az értesítésekhez való hozzáférés érzékeny engedély, amely lehetővé teszi egy szolgáltatás számára, hogy minden alkalmazás értesítéseit olvassa, nem csak a böngészőét. Egy ismeretlen automatizálási eszköznek adni egyetlen böngészőállapot figyeléséhez rossz üzlet, és a hozzáférés a kísérlet után is megmarad. A kisegítő lehetőségek által vezérelt koppintások rosszabbak: réteg a felület felett, nem támogatott VPN-vezérlőfelület, és minden elrendezésváltozásnál eltörnek.

Mielőtt bármit megadna, kérdezze meg, elérhető-e ugyanaz az eredmény támogatott mechanizmussal. Ha a válasz házirend-követelmény, általában igen: a platform kikényszeríthet alagutat egy alkalmazás vagy profil számára hallgató szolgáltatás nélkül.

Negyedik ellenőrzés: használjon mindig bekapcsolt módot és blokkolást, ha a követelmény érvényesítés

Ha a böngésző soha nem kommunikálhat az alagúton kívül, az érvényesítés a platform beállításaiba tartozik, nem egy makróba. Az Android támogatja a mindig bekapcsolt VPN-t blokkolási móddal, amely megakadályozza a forgalmat, ha az alagút nincs létrehozva, és a felügyelt eszközök házirenddel kaphatják meg. Erősítse meg, mi van most az eszközön, ahelyett hogy feltételezné:

adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdown

A nem null alkalmazásérték azt jelenti, hogy egy csomag mindig bekapcsoltként van beállítva, az 1 blokkolási érték pedig azt, hogy az alagúton kívüli kapcsolatok blokkoltak. Ez a pár alakítja a legjobb erőfeszítés szokását garanciává, és teljesen megszünteti a versenyt is, mert az alagút azelőtt jön létre, hogy az alkalmazás forgalma engedélyezett lenne.

Két határ érdemes itt megemlíteni. A munkaprofilok saját VPN-konfigurációval rendelkeznek, ezért a személyes profilban ellenőrzött szabály semmit nem mond a munkaprofilról. És egy külön telepített böngésző, egy másik alkalmazás által megnyitott egyedi lap vagy egy alkalmazáson belüli webview más csomag vagy környezet, saját útválasztással, ezért ellenőrizze a tényleges csomagot, ne feltételezze, hogy egy eltérő stílusú ablak külön tartomány.

Ötödik ellenőrzés: írja le a munkafolyamatot és tesztelje a hibaútját

Bármit is választ, dokumentálja a sorrendet és a megszakítási feltételt. A kényelmi munkafolyamatnál ez azt jelenti: alagút fent, készültség bizonyítva, inkognitó megnyitva, és kemény leállás, ha a készültség meghiúsul. Az érvényesítési útnál ez azt jelenti: mindig bekapcsolt alkalmazás beállítva, blokkolás engedélyezve, és a várt viselkedés, amikor az alagút egyáltalán nem jön létre, ami nem forgalom a védelem nélküli forgalom helyett.

Aztán tesztelje a kudarcot, ne csak a sikert. Bontsa a munkamenet közben az alagutat, és figyelje, mit tesz a böngésző; blokkolja a VPN-alkalmazás folyamatát, és erősítse meg, hogy semmi nem szivárog. Végül tartsa a két adatvédelmi modellt külön a felhasználói dokumentációban: az inkognitó a böngésző ideiglenes állapotát vezérli, és nem rejti el a forgalmat a hálózat elől, míg a VPN forgalmat szállít, de nem törli a bejelentkezéseket vagy bármit, amit a privát munkamenetben küldtek.