VPN per app op Android en Chrome incognito: wat de regel dekt

Iemand heeft een automatisering gebouwd die de VPN aanzet wanneer een incognitotabblad verschijnt, en die werkt niet betrouwbaar. Daar is een structurele reden voor, en het is de moeite waard die te begrijpen voordat je de automatisering afstelt. Android-regels voor VPN per app selecteren applicatiepakketten, en incognito is een toestand binnen één pakket, dus de regel kan de twee niet onderscheiden. Een melding wordt pas geactiveerd nadat de browser al is begonnen, dus zelfs een correcte trigger komt te laat. Werk de controles hieronder in volgorde af; een fout bij de vierde controle betekent dat de aanpak, niet de configuratie, moet veranderen.

Controle één: bevestig wat de regel per app kan selecteren

Een Android-VPN-app bouwt zijn tunnel met lijsten met toegestane of geweigerde apps, en die lijsten nemen pakketnamen. Chrome in de normale modus en Chrome in de incognitomodus zijn hetzelfde pakket, met dezelfde gebruikers-id en dezelfde netwerkmachtiging, dus een regel die Chrome opneemt of uitsluit, geldt voor beide identiek. Er is geen identiteit op tabbladniveau waarmee het platform kan vergelijken.

Dat is geen gebrek om te omzeilen; het is de granulariteit die de API biedt. Als je eis is dat Chrome-verkeer door de tunnel gaat en al het andere erbuiten, dan drukt een regel per app dat precies uit. Als je eis is dat alleen privétabbladen door de tunnel gaan terwijl gewone tabbladen rechtstreeks gaan, dan kan geen enkele regel per app dat uitdrukken, en geen enkele hoeveelheid meldingslogica voegt een selector toe die het platform niet heeft.

Let op de valkuil van pakketidentiteit tijdens het controleren. Een bèta of een build van een leverancier is een ander pakket dan de stabiele browser, dus een regel die het ene dekt, mist het andere stilzwijgend:

adb shell pm list packages | grep -i chrome

Controle twee: test of de trigger ooit vroeg genoeg kan zijn

Een meldingslistener observeert meldingen die hij mag zien. Observeren is geen onderscheppen: de browser heeft de naam al opgelost en de verbinding geopend op het moment dat de melding bestaat, en niets op dat pad wacht tot jouw automatisering klaar is. Een taak die daarna de VPN-client start, moet wachten op de clientinterface, een eventuele toestemmingsvraag en de tunnelhandshake, die in seconden worden gemeten, terwijl het eerste verzoek in milliseconden wordt gemeten.

De detectie zelf is kwetsbaar om een tweede reden. De meldingstekst verandert tussen versies en localisaties, dus een patroon dat bij één release past, past na een update niet meer, en de fout is stil. Een ontbrekende melding is geen bewijs dat privé browsen ontbreekt; het kan alleen betekenen dat de tekenreeks veranderde of dat het kanaal werd gedempt.

Er is een legitieme versie van deze werkstroom, en die is geordend in plaats van reactief: verbind eerst de goedgekeurde VPN, bevestig een gereedheidssignaal dat echt bewijst dat de tunnel verkeer draagt, open daarna de incognitosessie via ondersteunde browserbesturing, en stop als de gereedheidscontrole mislukt. Dat beschermt de sessie die je op het punt staat te beginnen zonder te doen alsof je een al lopende sessie beschermt.

Controle drie: controleer de machtiging die je op het punt staat te geven

Toegang tot meldingen is een gevoelige machtiging waarmee een dienst meldingen van elke app kan lezen, niet alleen van de browser. Die geven aan een onbekend automatiseringshulpmiddel om één browsertoestand te bewaken is een slechte ruil, en de toegang blijft bestaan na afloop van het experiment. Door toegankelijkheid aangestuurde tikken zijn erger: het is een scriptlaag boven de interface, geen ondersteunde VPN-besturingsinterface, en ze breken bij elke lay-outwijziging.

Vraag je voordat je iets geeft af of hetzelfde resultaat haalbaar is met een ondersteund mechanisme. Als het antwoord een beleidsvereiste is, is dat meestal zo: het platform kan een tunnel afdwingen voor een app of een profiel zonder enige luisterende dienst.

Controle vier: gebruik altijd aan en blokkering wanneer de eis handhaving is

Als de browser nooit buiten de tunnel mag communiceren, hoort handhaving in de platforminstellingen, niet in een macro. Android ondersteunt een altijd aan staande VPN met een blokkeringsmodus die verkeer voorkomt wanneer de tunnel niet is opgezet, en beheerde apparaten kunnen die via beleid krijgen. Bevestig wat het apparaat nu heeft in plaats van aan te nemen:

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

Een app-waarde die niet null is, betekent dat een pakket als altijd aan is geconfigureerd, en een blokkeringswaarde van 1 betekent dat verbindingen buiten de tunnel zijn geblokkeerd. Dat paar maakt van een gewoonte van beste inspanning een garantie, en het haalt ook de race volledig weg, omdat de tunnel wordt opgezet voordat app-verkeer wordt toegestaan.

Twee grenzen zijn hier het vermelden waard. Werkprofielen dragen hun eigen VPN-configuratie, dus een regel die in het persoonlijke profiel is geverifieerd, zegt niets over het werkprofiel. En een apart geïnstalleerde browser, een aangepast tabblad dat door een andere app wordt geopend, of een webview in een app is een ander pakket of context met zijn eigen routering, dus verifieer het werkelijke pakket in plaats van aan te nemen dat een anders gestyled venster een apart domein is.

Controle vijf: schrijf de werkstroom op en test het faalpad

Wat je ook kiest, documenteer de volgorde en de afbreekvoorwaarde. Voor de gemakswerkstroom betekent dat: tunnel omhoog, gereedheid bewezen, incognito geopend, en een harde stop als de gereedheid faalt. Voor het handhavingspad betekent het: altijd aan-app geconfigureerd, blokkering ingeschakeld, en het verwachte gedrag wanneer de tunnel helemaal niet omhoog kan komen, namelijk geen verkeer in plaats van onbeschermd verkeer.

Test daarna de fout, niet alleen het succes. Verbreek de tunnel tijdens een sessie en kijk wat de browser doet; blokkeer het proces van de VPN-app en bevestig dat er niets lekt. Ten slotte houd je de twee privacymodellen gescheiden in de gebruikersdocumentatie: incognito beheert tijdelijke browsertoestand en verbergt verkeer niet voor het netwerk, terwijl een VPN verkeer draagt maar aanmeldingen of iets dat in de privésessie is verzonden niet wist.