Android VPN per app och Chrome inkognito: vad regeln omfattar

Någon har byggt en automatisering som slår på VPN när en inkognitoflik dyker upp, och den fungerar inte tillförlitligt. Det finns en strukturell orsak till det, och den är värd att förstå innan du justerar automatiseringen. Androids VPN-regler per app väljer applikationspaket, och inkognito är ett tillstånd inuti ett paket, så regeln kan inte skilja de två. En avisering utlöses efter att webbläsaren redan har börjat arbeta, så även en korrekt utlösare kommer för sent. Gå igenom kontrollerna nedan i ordning; ett misslyckande vid den fjärde kontrollen betyder att det är angreppssättet, inte konfigurationen, som måste ändras.

Kontroll ett: bekräfta vad regeln per app kan välja

En Android VPN-app bygger sin tunnel med listor över tillåtna eller nekade appar, och dessa listor tar paketnamn. Chrome i normalt läge och Chrome i inkognitoläge är samma paket, med samma användar-id och samma nätverksbehörighet, så en regel som inkluderar eller utesluter Chrome gäller likadant för båda. Plattformen har ingen flikbunden identitet att matcha mot.

Det är inte en brist att kringgå; det är den detaljnivå som API:t erbjuder. Om kravet är att Chrome-trafik går genom tunneln och allt annat utanför, uttrycker en regel per app det exakt. Om kravet är att bara privata flikar går genom tunneln medan vanliga flikar går direkt, kan ingen regel per app uttrycka det, och ingen mängd aviseringslogik lägger till en väljare som plattformen inte har.

Se upp för paketidentitetsfällan när du kontrollerar. En beta eller en leverantörsbygge är ett annat paket än den stabila webbläsaren, så en regel som täcker den ena missar den andra tyst:

adb shell pm list packages | grep -i chrome

Kontroll två: testa om utlösaren någonsin kan vara tidig nog

En aviseringslyssnare observerar aviseringar som den har tillåtelse att se. Observera är inte avlyssna: webbläsaren har redan slagit upp namnet och öppnat anslutningen när aviseringen finns, och ingenting på den vägen väntar på att din automatisering ska bli klar. En uppgift som sedan startar VPN-klienten måste vänta på klientens gränssnitt, eventuell samtyckesfråga och tunnelns handskakning, som mäts i sekunder, medan den första begäran mäts i millisekunder.

Själva detekteringen är bräcklig av en andra anledning. Aviseringstexten ändras mellan versioner och lokaliseringar, så ett mönster som matchar en utgåva slutar matcha efter en uppdatering, och felet är tyst. En saknad avisering är inte bevis för att privat surfning saknas; det kan bara betyda att strängen ändrades eller att kanalen dämpades.

Det finns en legitim version av det här arbetsflödet, och den är ordnad i stället för reaktiv: anslut den godkända VPN:en först, bekräfta en beredskapssignal som verkligen bevisar att tunneln bär trafik, öppna sedan inkognitosessionen via webbläsarens stödda kontroller, och stoppa om beredskapskontrollen misslyckas. Det skyddar sessionen du är på väg att börja utan att låtsas skydda en som redan pågår.

Kontroll tre: granska behörigheten du är på väg att ge

Aviseringstillgång är en känslig behörighet som låter en tjänst läsa aviseringar från varje app, inte bara webbläsaren. Att ge den till ett okänt automatiseringsverktyg för att övervaka ett webbläsartillstånd är en dålig affär, och åtkomsten består efter att experimentet är över. Tillgänglighetsstyrda tryck är värre: de är ett skriptlager ovanpå gränssnittet, inte ett stött VPN-kontrollgränssnitt, och de går sönder vid varje layoutändring.

Innan du ger något, fråga om samma resultat kan nås med en stödd mekanism. Om svaret är ett policykrav är det oftast det: plattformen kan genomdriva en tunnel för en app eller en profil utan någon lyssnande tjänst alls.

Kontroll fyra: använd alltid på och blockering när kravet är genomdrivning

Om webbläsaren aldrig får kommunicera utanför tunneln hör genomdrivningen hemma i plattformens inställningar, inte i ett makro. Android stöder alltid på-VPN med ett blockeringsläge som hindrar trafik när tunneln inte är upprättad, och hanterade enheter kan få det via policy. Bekräfta vad enheten har nu i stället för att anta:

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

Ett appvärde som inte är null betyder att ett paket är konfigurerat som alltid på, och ett blockeringsvärde på 1 betyder att anslutningar utanför tunneln blockeras. Det är det paret som förvandlar en vana av bästa ansträngning till en garanti, och det tar också bort kapplöpningen helt, eftersom tunneln upprättas innan apptrafik tillåts.

Två gränser är värda att nämna här. Arbetsprofiler har sin egen VPN-konfiguration, så en regel som verifierats i den personliga profilen säger ingenting om arbetsprofilen. Och en separat installerad webbläsare, en anpassad flik som öppnas av en annan app eller en webview inuti en app är ett annat paket eller sammanhang med sin egen routning, så verifiera det faktiska paketet i stället för att anta att ett annat utformat fönster är en egen domän.

Kontroll fem: skriv ned arbetsflödet och testa felvägen

Vad du än väljer, dokumentera ordningen och avbrottsvillkoret. För bekvämlighetsflödet betyder det: tunnel uppe, beredskap bevisad, inkognito öppnat och ett hårt stopp om beredskapen misslyckas. För genomdrivningsvägen betyder det: alltid på-app konfigurerad, blockering aktiverad och det förväntade beteendet när tunneln inte kan komma upp alls, vilket är ingen trafik i stället för oskyddad trafik.

Testa sedan felet, inte bara framgången. Koppla ned tunneln under en session och se vad webbläsaren gör; blockera VPN-appens process och bekräfta att ingenting läcker. Håll till sist de två integritetsmodellerna åtskilda i användardokumentationen: inkognito styr webbläsarens tillfälliga tillstånd och döljer inte trafik för nätverket, medan en VPN bär trafik men raderar inte inloggningar eller något som skickas i den privata sessionen.