Android VPN per app og Chrome inkognito: hva regelen dekker

Noen har laget en automatisering som slår på VPN når en inkognitofane dukker opp, og den fungerer ikke pålitelig. Det har en strukturell årsak, og den er verdt å forstå før du justerer automatiseringen. Androids VPN-regler per app velger applikasjonspakker, og inkognito er en tilstand inne i én pakke, så regelen kan ikke skille de to. Et varsel utløses etter at nettleseren allerede har begynt å arbeide, så selv en riktig utløser kommer for sent. Gå gjennom kontrollene nedenfor i rekkefølge; en feil ved fjerde kontroll betyr at det er tilnærmingen, ikke konfigurasjonen, som må endres.

Kontroll én: bekreft hva regelen per app kan velge

En Android VPN-app bygger tunnelen sin med lister over tillatte eller avviste apper, og disse listene tar pakkenavn. Chrome i normal modus og Chrome i inkognitomodus er samme pakke, med samme bruker-ID og samme nettverkstillatelse, så en regel som inkluderer eller utelukker Chrome gjelder likt for begge. Det finnes ingen fanebasert identitet som plattformen kan matche mot.

Det er ikke en feil å omgå; det er detaljnivået API-et tilbyr. Hvis kravet ditt er Chrome-trafikk gjennom tunnelen og alt annet utenfor, uttrykker en regel per app det nøyaktig. Hvis kravet ditt er at bare private faner går gjennom tunnelen mens vanlige faner går direkte, kan ingen regel per app uttrykke det, og ingen mengde varslingslogikk vil legge til en velger plattformen ikke har.

Se opp for pakkeidentitetsfellen mens du kontrollerer. En beta eller en leverandørbygging er en annen pakke enn den stabile nettleseren, så en regel som dekker én, overser den andre i stillhet:

adb shell pm list packages | grep -i chrome

Kontroll to: test om utløseren noen gang kan være tidlig nok

En varsellytter observerer varsler den har tillatelse til å se. Observasjon er ikke avlytting: nettleseren har allerede slått opp navnet og åpnet forbindelsen når varselet finnes, og ingenting på den veien venter på at automatiseringen din skal bli ferdig. En oppgave som deretter starter VPN-klienten, må vente på klientgrensesnittet, en eventuell samtykkeforespørsel og tunnelhåndtrykket, som måles i sekunder, mens den første forespørselen måles i millisekunder.

Deteksjonen selv er skjør av en annen grunn. Varselteksten endres mellom versjoner og lokaliseringer, så et mønster som passer til én utgivelse slutter å passe etter en oppdatering, og feilen er stille. Et manglende varsel er ikke bevis på at privat nettlesing ikke finnes; det kan bare bety at strengen endret seg eller at kanalen ble dempet.

Det finnes en legitim versjon av denne arbeidsflyten, og den er ordnet i stedet for reaktiv: koble til den godkjente VPN-en først, bekreft et beredskapssignal som faktisk beviser at tunnelen bærer trafikk, åpne deretter inkognitoøkten gjennom støttede nettleserkontroller, og stopp hvis beredskapskontrollen feiler. Det beskytter økten du er i ferd med å starte uten å late som du beskytter en som allerede kjører.

Kontroll tre: revider tillatelsen du er i ferd med å gi

Varselstilgang er en sensitiv tillatelse som lar en tjeneste lese varsler fra hver app, ikke bare nettleseren. Å gi den til et ukjent automatiseringsverktøy for å overvåke én nettlesertilstand er en dårlig byttehandel, og tilgangen består etter at eksperimentet er over. Tilgjengelighetsstyrte trykk er verre: de er et skriptlag over grensesnittet, ikke et støttet VPN-kontrollgrensesnitt, og de bryter sammen ved enhver layoutendring.

Før du gir noe, spør om samme resultat kan nås med en støttet mekanisme. Hvis svaret er et policykrav, er det vanligvis det: plattformen kan håndheve en tunnel for en app eller en profil uten noen lyttende tjeneste i det hele tatt.

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

Hvis nettleseren aldri skal kommunisere utenfor tunnelen, hører håndhevingen hjemme i plattforminnstillingene, ikke i en makro. Android støtter alltid på-VPN med en blokkeringsmodus som hindrer trafikk når tunnelen ikke er etablert, og administrerte enheter kan få det gjennom policy. Bekreft hva enheten har nå i stedet for å anta:

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

En appverdi som ikke er null betyr at en pakke er konfigurert som alltid på, og en blokkeringsverdi på 1 betyr at tilkoblinger utenfor tunnelen er blokkert. Det er dette paret som gjør en vane med beste innsats til en garanti, og det fjerner også kappløpet helt, fordi tunnelen etableres før apptrafikk tillates.

To grenser er verdt å nevne her. Arbeidsprofiler har sin egen VPN-konfigurasjon, så en regel som er verifisert i den personlige profilen, sier ingenting om arbeidsprofilen. Og en separat installert nettleser, en egendefinert fane åpnet av en annen app eller en webview inne i en app er en annen pakke eller kontekst med sin egen ruting, så verifiser den faktiske pakken i stedet for å anta at et annerledes stilt vindu er et eget domene.

Kontroll fem: skriv ned arbeidsflyten og test feilveien

Uansett hva du velger, dokumenter rekkefølgen og avbrytelsesbetingelsen. For bekvemmelighetsflyten betyr det: tunnel oppe, beredskap bevist, inkognito åpnet, og en hard stopp hvis beredskapen feiler. For håndhevingsveien betyr det: alltid på-app konfigurert, blokkering aktivert, og forventet atferd når tunnelen ikke kan komme opp i det hele tatt, som er ingen trafikk i stedet for ubeskyttet trafikk.

Test deretter feilen, ikke bare suksessen. Koble fra tunnelen under en økt og se hva nettleseren gjør; blokker VPN-appprosessen og bekreft at ingenting lekker. Til slutt, hold de to personvernmodellene atskilt i brukerdokumentasjonen: inkognito kontrollerer midlertidig nettlesertilstand og skjuler ikke trafikk for nettverket, mens en VPN bærer trafikk, men sletter ikke innlogginger eller noe som sendes i den private økten.