Android VPN per app og Chrome inkognito: kva regelen dekkjer

Nokon har laga ein automatisering som slår på VPN når ei inkognitofane dukkar opp, og ho fungerer ikkje påliteleg. Det har ei strukturell årsak, og ho er verd å forstå før du justerer automatiseringa. Android sine VPN-reglar per app vel applikasjonspakkar, og inkognito er ein tilstand inne i ein pakke, så regelen kan ikkje skilje dei to. Ei varsling blir utløyst etter at nettlesaren allereie har byrja å arbeide, så sjølv ein riktig utløysar kjem for seint. Gå gjennom kontrollane nedanfor i rekkjefølgje; ein feil ved fjerde kontroll betyr at det er tilnærminga, ikkje konfigurasjonen, som må endrast.

Kontroll éin: stadfest kva regelen per app kan velje

Ein Android VPN-app byggjer tunnelen sin med lister over tillatne eller avviste apppar, og desse listene tek pakkenamn. Chrome i normal modus og Chrome i inkognitomodus er same pakke, med same brukar-ID og same nettverkstilgang, så ein regel som tek med eller utelèt Chrome gjeld likt for båe. Det finst ingen fanebasert identitet som plattformen kan matche mot.

Det er ikkje ein feil å omgå; det er detaljnivået API-et tilbyr. Viss kravet ditt er Chrome-trafikk gjennom tunnelen og alt anna utanfor, uttrykkjer ein regel per app det nøyaktig. Viss kravet ditt er at berre private faner går gjennom tunnelen medan vanlege faner går direkte, kan ingen regel per app uttrykkje det, og inga mengd varslingslogikk vil leggje til ein veljar plattformen ikkje har.

Sjå opp for pakkeidentitetsfella medan du kontrollerer. Ein beta eller ein leverandørbygging er ein annan pakke enn den stabile nettlesaren, så ein regel som dekkjer éin, overser den andre i stillheit:

adb shell pm list packages | grep -i chrome

Kontroll to: test om utløysaren nokon gong kan vere tidleg nok

Ein varsellyttar observerer varsel han har løyve til å sjå. Observasjon er ikkje avlytting: nettlesaren har allereie slått opp namnet og opna sambandet når varselet finst, og ingenting på den vegen ventar på at automatiseringa di blir ferdig. Ein oppgåve som deretter startar VPN-klienten, må vente på klientgrensesnittet, ei eventuell samtykkeførespurnad og tunnelhandtrykket, som blir målte i sekund, medan den første førespurnaden blir målt i millisekund.

Sjølve deteksjonen er skjør av ein annan grunn. Varselteksten endrar seg mellom versjonar og lokaliseringar, så eit mønster som passar til ein utgiving, sluttar å passe etter ei oppdatering, og feilen er stille. Eit manglande varsel er ikkje prov på at privat nettlesing ikkje finst; det kan berre tyde at strengen endra seg eller at kanalen vart dempa.

Det finst ein legitim versjon av denne arbeidsflyten, og han er ordna i staden for reaktiv: kople til den godkjende VPN-en først, stadfest eit beredskapssignal som faktisk provar at tunnelen ber trafikk, opne deretter inkognitoøkta gjennom støtta nettlesarkontrollar, og stopp om beredskapskontrollen feilar. Det vernar økta du er i ferd med å starte utan å late som du vernar ei som allereie køyrer.

Kontroll tre: revider løyvet du er i ferd med å gi

Varseltilgang er eit sensitivt løyve som lèt ein teneste lese varsel frå kvar app, ikkje berre nettlesaren. Å gi det til eit ukjent automatiseringsverktøy for å overvake éin nettlesartilstand er ein dårleg byttehandel, og tilgangen blir verande etter at eksperimentet er over. Tilgjengelegheitsstyrte trykk er verre: dei er eit skriptlag over grensesnittet, ikkje eit støtta VPN-kontrollgrensesnitt, og dei bryt saman ved kvar layoutendring.

Før du gir noko, spør om same resultat kan nåast med ein støtta mekanisme. Viss svaret er eit policykrav, er det vanlegvis det: plattformen kan handheve ein tunnel for ein app eller ein profil utan nokon lyttande teneste i det heile.

Kontroll fire: bruk alltid på og blokkering når kravet er handheving

Viss nettlesaren aldri skal kommunisere utanfor tunnelen, høyrer handhevinga heime i plattforminnstillingane, ikkje i ein makro. Android støttar alltid på-VPN med ein blokkeringsmodus som hindrar trafikk når tunnelen ikkje er etablert, og styrte einingar kan få det gjennom policy. Stadfest kva eininga har no i staden for å anta:

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

Ein appverdi som ikkje er null betyr at ein pakke er konfigurert som alltid på, og ein blokkeringsverdi på 1 betyr at tilkoplingar utanfor tunnelen er blokkerte. Det er dette paret som gjer ein vane med beste innsats til ein garanti, og det fjernar også kappløpet heilt, fordi tunnelen blir etablert før apptrafikk blir tillaten.

To grenser er verd å nemne her. Arbeidsprofilar har sin eigen VPN-konfigurasjon, så ein regel som er verifisert i den personlege profilen, seier ingenting om arbeidsprofilen. Og ein separat installert nettlesar, ei eigendefinert fane opna av ein annan app eller eit webview inne i ein app er ein annan pakke eller kontekst med si eiga ruting, så verifiser den faktiske pakken i staden for å anta at eit annleis stila vindauge er eit eige domene.

Kontroll fem: skriv ned arbeidsflyten og test feilvegen

Uansett kva du vel, dokumenter rekkjefølgja og avbrytingsvilkåret. For bekvemmeligheitsflyten betyr det: tunnel oppe, beredskap prova, inkognito opna, og ein hard stopp om beredskapen feilar. For handhevingsvegen betyr det: alltid på-app konfigurert, blokkering aktivert, og forventa åtferd når tunnelen ikkje kan kome opp i det heile, som er ingen trafikk i staden for uverna trafikk.

Test deretter feilen, ikkje berre suksessen. Kople frå tunnelen under ei økt og sjå kva nettlesaren gjer; blokker VPN-appprosessen og stadfest at ingenting lek. Til slutt, hald dei to personvernmodellane åtskilde i brukardokumentasjonen: inkognito styrer mellombels nettlesartilstand og skjuler ikkje trafikk for nettverket, medan ein VPN ber trafikk, men slettar ikkje innloggingar eller noko som blir sendt i den private økta.