VPN per app i Android: att utesluta en app är inte att blockera den

Två personer ställer samma fråga och får svar som inte går ihop, eftersom de står på olika ställen. Den ene har systemets VPN-inställningar öppna och redigerar en applista. Den andre skriver VpnService.Builder.addDisallowedApplication() i en editor. Båda kallar det ett VPN-filter per app. Bara en av dem äger den kontroll de beskriver, och ingen av dem blockerar något.

Börja på skärmen användaren ser

Öppna Inställningar, hitta VPN-posten och titta på anslutningen som faktiskt är aktiv. Om klienten erbjuder en lista per app tillhör listan klientens egen tunnel. Plattformen publicerar inget allmänt API där en orelaterad app kan läsa eller ändra en annan VPN:s appval, så en andra app kan inte reparera listan åt användaren.

Det här är den första delningen i genomgången. Saknar den installerade VPN-en inställningen finns det inget att koda runt: funktionen saknas i produkten som äger tunneln. Har den den, ligger rätt rättelse på den skärmen, gjord av den som kan öppna den.

Följ paketet in i en tunnel

När din egen app bygger en tunnel skapar den ett TUN-gränssnitt och deklarerar vilka appars trafik som går in i det. Medlemsskapsanropen sker innan gränssnittet upprättas, och efter det är regeluppsättningen fast för den sessionen:

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 anropen gäller bara tunneln som din app just skapade och inget annat. De är inte en policy för hela enheten, de består inte för andra klienter och de kan inte nå in i någon annans VPN. När ett byggaranrop kastar ett undantag eftersom paketet inte kan lösas upp upprättas aldrig gränssnittet, vilket är ett rent och inte ett tyst fel.

Varför uteslutningen såg ut som en blockering

En utesluten app dirigeras runt din tunnel ut på nätet under. Det är motsatsen till att blockera den: trafiken lämnar fortfarande enheten, bara utanför gränssnittet du styr. En app i brandväggsstil gör det omvända. Den släpper in appens trafik i sin tunnel och kastar sedan paketen, eller vägrar vidarebefordra dem, så gränssnittet är detsamma och riktningen på policyn är omvänd.

Arbetet bakom den vändningen är ingen konfigurationsflagga. Du läser IP-paket från tunnelbeskrivningen, avgör per flöde och vidarebefordrar dem genom en skyddad socket eller kastar dem. Allt du inte hanterar stannar bara, och därför ser en halvfärdig tunnel ut som ett trasigt nätverk i stället för ett fungerande filter. Om målet är blockering, budgetera för pakethantering, en förgrundstjänst och en skriftlig policy för trafik du inte kan klassificera.

Vad som går sönder när du bygger det själv

Android tillåter vanligtvis bara en aktiv VPN åt gången, så din filtertunnel och en integritetstunnel konkurrerar om samma plats om produkterna inte stöder kedjning. Alltid på-VPN med blockerade anslutningar ändrar felmoden på ett sätt som spelar roll här: trafik som inte kan komma in i tunneln kastas i stället för att skickas direkt, vilket en läckageförebyggande design vill och en felsökningssession sällan förväntar sig.

Paketsynlighet är den andra fällan. Uppslag av en apps paketnamn kan misslyckas med NameNotFoundException, och på nyare Android-versioner beror uppsättningen paket du kan se på de frågor du har deklarerat. Hantera undantaget i stället för att anta att varje namn löses upp, och läs om listan när appar installeras eller tas bort i stället för att cacha den för alltid.

Hanterade enheter lägger till en tredje ägare. En policy för företagsmobilitet kan sätta en VPN per app eller en alltid på-profil, och en vanlig app kan inte åsidosätta den. Kontrollera om enheten är hanterad innan du felsöker din egen kod, för i så fall är listan du försöker ändra kanske inte redigerbar för någon som håller i telefonen.

Testa med en app du styr

Testa inte med appen du försöker filtrera. Använd en andra app vars nätbeteende du kan observera, och kontrollera om dess trafik går ut genom din tunnel medan målets inte gör det. Om båda stannar inne fungerar policyn och målet är uteslutet; om ingen kommer ut är själva tunneln fel och applistan är inte problemet.

Bestäm sedan vilket av tre saker du faktiskt bygger. En tunnel per app är byggar-API:t, med listan som en del av din profil. En enhetsbrandvägg är pakethantering plus en livscykel du kan försvara. Att ändra någon annans VPN är inte en stödd väg alls, och det ärliga svaret där är att inställningen tillhör den produkten.