VPN pr. app på Android: at udelukke en app er ikke at blokere den

To personer stiller det samme spørgsmål og får uforenelige svar, fordi de står forskellige steder. Den ene har systemets VPN-indstillinger åbne og redigerer en liste over apps. Den anden skriver VpnService.Builder.addDisallowedApplication() i en editor. Begge kalder det et VPN-filter pr. app. Kun én af dem ejer den kontrol, de beskriver, og ingen af dem blokerer noget.

Start ved den skærm, brugeren ser

Åbn Indstillinger, find VPN-punktet og se på den forbindelse, der faktisk er aktiv. Hvis klienten tilbyder en liste pr. app, tilhører listen klientens egen tunnel. Platformen offentliggør ikke et generelt API, hvor en uvedkommende app kan læse eller redigere en anden VPNs app-valg, så en anden app kan ikke rette den liste for brugeren.

Dette er den første forgrening i gennemgangen. Hvis den installerede VPN ikke har denne indstilling, er der intet at kode uden om: funktionen findes ikke i det produkt, der ejer tunnelen. Hvis den har, er den rigtige rettelse på den skærm og udføres af den person, der kan åbne den.

Følg pakken ind i en tunnel

Når din egen app bygger en tunnel, opretter den en TUN-grænseflade og erklærer, hvilke appes trafik der går ind i den. Medlemskabskaldene sker, før grænsefladen etableres, og derefter er regelsættet fast for den session:

val builder = VpnService.Builder()
builder.addAddress("10.8.0.2", 32)
builder.addRoute("0.0.0.0", 0)
builder.addDisallowedApplication("com.example.bypass")
val tun = builder.establish()   // membership decided here

De kald gælder kun for den tunnel, din app netop har oprettet. De er ikke en politik for hele enheden, de bliver ikke hos andre klienter, og de kan ikke nå ind i en andens VPN. Når et builder-kald fejler, fordi pakken ikke kan slås op, etableres grænsefladen aldrig, hvilket er en ren og ikke en stille fejl.

Hvorfor udelukkelsen lignede en blokering

En udelukket app sendes uden om din tunnel over i det underliggende netværk. Det er det modsatte af at blokere den: trafikken forlader stadig enheden, bare uden for den grænseflade, du styrer. En app i firewall-stil gør det modsatte: den lukker appens trafik ind i sin tunnel og kasserer derefter pakkerne eller nægter at videresende dem, så grænsefladen er den samme, og politikens retning er vendt.

Arbejdet bag den vending er ikke et konfigurationsflag. Du læser IP-pakker fra tunnelbeskrivelsen, beslutter pr. flow og videresender dem gennem en beskyttet socket eller kasserer dem. Alt, du ikke håndterer, stopper simpelthen, og derfor ligner en halvfærdig tunnel et brudt netværk snarere end et fungerende filter. Hvis målet er blokering, så budgetter med pakkehåndtering, en forgrundstjeneste og en skriftlig politik for trafik, du ikke kan klassificere.

Hvad der brækker, når du bygger det selv

Android tillader normalt kun én aktiv VPN ad gangen, så din filtreringstunnel og en privattunnel konkurrerer om den samme plads, medmindre produkterne understøtter kædning. Altid-aktiv VPN med blokering af forbindelser ændrer fejltilstanden på en måde, der betyder noget her: trafik, der ikke kan komme ind i tunnelen, kasseres i stedet for at blive sendt direkte, hvilket et lækageforebyggende design vil have, og en fejlretningssession sjældent forventer.

Pakkernes synlighed er den anden fælde. Opslag af en apps pakkenavn kan fejle med NameNotFoundException, og på nyere Android-versioner afhænger de pakker, du kan se, af de forespørgsler, du har erklæret. Håndtér undtagelsen i stedet for at antage, at hvert navn slås op, og læs listen igen, når apps installeres eller fjernes, i stedet for at cache den for evigt.

Administrerede enheder tilføjer en tredje ejer. En virksomhedsmobilitetspolitik kan sætte en VPN pr. app eller en altid-aktiv profil, og en almindelig app kan ikke tilsidesætte den. Kontroller, om enheden administreres, før du fejlretter din egen kode, for i så fald er den liste, du prøver at ændre, måske ikke redigerbar for nogen, der holder telefonen.

Test med en app, du styrer

Test ikke med den app, du prøver at filtrere. Brug en anden app, hvis netværksadfærd du kan observere, og kontroller, om dens trafik forlader gennem din tunnel, mens målets ikke gør. Hvis begge bliver inde, virker politikken, og målet er udelukket; hvis ingen af dem forlader, er tunnelen forkert, og app-listen er ikke problemet.

Beslut derefter, hvilken af tre ting du faktisk bygger. En tunnel pr. app er builder-APIet, med listen som en del af din profil. En enhedsfirewall er pakkehåndtering plus en livscyklus, du kan forsvare. At ændre en andens VPN er slet ikke en understøttet vej, og det ærlige svar der er, at indstillingen tilhører det produkt.