VPN pr. app på Android og Chrome-inkognito: hvad reglen dækker

Nogen har bygget en automatisering, der tænder VPN, når en inkognitofane vises, og den virker ikke pålideligt. Årsagen er strukturel og værd at forstå, før automatiseringen finjusteres: Androids regler pr. app vælger applikationspakker, mens inkognito er en tilstand inde i én pakke. Reglen kan ikke skelne de to. Underretningen kommer også først, efter at browseren er begyndt at arbejde, så selv en korrekt udløser kommer for sent. Gå gennem de fem kontroller i rækkefølge; en fejl ved kontrol fire betyder, at tilgangen, ikke indstillingerne, skal ændres.

Kontrol et: hvad reglen kan vælge

En VPN-app bygger sin tunnel ud fra lister over tilladte eller blokerede apps, og disse lister tager pakkenavne. Chrome i normal tilstand og Chrome i inkognito er samme pakke med samme bruger-id og samme netværkstilladelse, så en regel, der medtager eller udelukker Chrome, gælder identisk for begge. Platformen har ingen faneidentitet at matche imod.

Det er ikke en fejl, der skal omgås; det er den detaljeringsgrad, API'en tilbyder. Hvis du har brug for Chrome-trafik inde i tunnelen og alt andet udenfor, udtrykker en regel pr. app præcis det. Hvis du kun har brug for private faner inde i tunnelen, mens almindelige faner går direkte, kan ingen regel pr. app udtrykke det, og ingen underretningslogik tilføjer en vælger, som platformen ikke har.

Pas på fælden med pakkeidentitet: en beta eller en leverandørbuild er en anden pakke end den stabile browser, så en regel, der dækker den ene, rammer lydløst forbi den anden:

adb shell pm list packages | grep -i chrome

Kontrol to: kan udløseren nogensinde være tidlig nok

En underretningslytter observerer de underretninger, den må se. Observation er ikke aflytning: når underretningen findes, har browseren allerede slået navnet op og åbnet forbindelsen, og intet på den vej venter på din automatisering. En opgave, der derefter starter VPN-klienten, skal vente på klientens grænseflade, en eventuel samtykkedialog og tunnelens håndtryk, som måles i sekunder, mens den første anmodning måles i millisekunder.

Registreringen er skrøbelig af en anden grund. Underretningstekst ændrer sig mellem versioner og sprog, så et mønster, der passede på en udgivelse, holder op med at passe efter en opdatering, og fejlen er tavs. En manglende underretning er ikke bevis for, at privat browsing er fraværende; det kan kun betyde, at strengen er ændret, eller at kanalen er dæmpet.

Der findes en legitim version af dette arbejdsforløb, og den er ordnet i stedet for reaktiv: tilslut først den godkendte VPN, bekræft et parathedssignal, der faktisk beviser, at tunnelen bærer trafik, åbn derefter inkognitosesionen via browserens understøttede kontroller, og stop, hvis parathedskontrollen fejler. Det beskytter den session, du er ved at starte, uden at foregive at beskytte en, der allerede kører.

Kontrol tre: revider den tilladelse, du er ved at give

Adgang til underretninger er en følsom tilladelse, der lader en tjeneste læse underretninger fra hver app, ikke kun browseren. At give den til et ukendt automatiseringsværktøj for at overvåge én browsertilstand er en dårlig handel, og adgangen består efter forsøgets afslutning. Tryk styret af tilgængelighed er værre: de er et scriptlag over grænsefladen, ikke en understøttet VPN-kontrol, og enhver layoutændring bryder dem.

Før du giver noget, så spørg, om samme resultat kan nås med en understøttet mekanisme. Hvis svaret er et politikrav, kan det som regel: platformen kan håndhæve en tunnel for en app eller en profil helt uden en lyttende tjeneste.

Kontrol fire: brug altid-tændt og blokering, når du har brug for håndhævelse

Hvis browseren aldrig må kommunikere uden for tunnelen, hører håndhævelsen hjemme i platformens indstillinger, ikke i en makro. Android understøtter en altid-tændt VPN med en blokeringstilstand, der forhindrer trafik, når tunnelen ikke er etableret, og administrerede enheder kan få det via politik. Bekræft, hvad enheden har nu, i stedet for at antage:

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

En ikke-null app-værdi betyder, at en pakke er konfigureret som altid-tændt, og en lockdown-værdi på 1 betyder, at forbindelser uden for tunnelen er blokeret. Parret gør en vane med bedste indsats til en garanti og fjerner kapløbet helt, fordi tunnelen etableres, før apptrafik tillades.

To grænser er værd at nævne her. Arbejdsprofiler har deres egen VPN-konfiguration, så en regel, der er verificeret i den personlige profil, siger intet om arbejdsprofilen. Og en separat installeret browser, en brugerdefineret fane åbnet af en anden app eller en webvisning inde i en app er en anden pakke eller kontekst med sin egen routing, så verificér den faktiske pakke i stedet for at antage, at et andet udseende vindue er et separat domæne.

Kontrol fem: skriv arbejdsforløbet ned, og test fejlvejen

Uanset hvad du vælger, så dokumentér rækkefølgen og stopbetingelsen. For bekvemmelighedsforløbet betyder det: tunnel oppe, parathed bevist, inkognito åbnet og et hårdt stop, hvis paratheden fejler. For håndhævelsesvejen betyder det: altid-tændt app konfigureret, blokering aktiveret, og den forventede adfærd, når tunnelen slet ikke kan komme op, nemlig ingen trafik i stedet for ubeskyttet trafik.

Test derefter fejlen, ikke kun succesen. Afbryd tunnelen under en session, og se, hvad browseren gør; bloker VPN-appens proces, og bekræft, at intet lækker. Hold til sidst de to privatlivsmodeller adskilt i dokumentationen: inkognito styrer en midlertidig browsertilstand og skjuler ikke trafik for netværket, mens en VPN bærer trafik, men sletter ikke logins eller noget, der er sendt i den private session.