Varför en app inte kan slå på en sparad VPN-profil på Android eller iOS

Två helt olika jobb hamnar under namnet programmerbar VPN, och bara ett av dem är tillgängligt för en vanlig app på någon av de två mobilplattformarna. Det första är att slå på en profil som användaren redan har sparat; det andra är att bygga en tunnel inne i din egen process. Android ger dig det andra genom VpnService och iOS ger dig det andra genom rättigheten Network Extension, medan det första stannar hos systemet, en enhetsägare eller en MDM-server. Att avgöra vilket du faktiskt behöver gör oftast projektet mindre.

Två jobb som delar ett namn

Att aktivera en sparad profil betyder att säga till en befintlig tunnel att komma upp: en värd, en inloggningsuppgift, ett protokoll, allt redan konfigurerat någonstans som användaren kan se. Att bygga en tunnel betyder att din kod äger gränssnittet, paketloopen och protokollet. De ser lika ut i en produktbacklog och delar nästan ingen implementation.

Ingen av mobilplattformarna exponerar det första för en SDK-app. En anslutning som dyker upp utan att användaren gör något går inte att skilja från skadlig kod, så båda systemen sätter en samtyckesport framför varje app som bär trafik.

Android: en samtyckesport och inget profil-API

VpnService har funnits sedan Android 4.0 och låter en app skapa ett tun-gränssnitt och sedan läsa och skriva paket. Tjänsten måste deklareras med BIND_VPN_SERVICE, och VpnService.prepare() skapar systemdialogen som ber användaren tillåta det. Plattformsexemplet ToyVpn är det tydligaste uttalandet om den avsedda formen: din kod äger gränssnittet och allt som strömmar genom det.

Det den inte gör är att lägga till en post på systemets VPN-inställningsskärm. Det finns inget offentligt API för det, och appen Inställningar håller sina profiler i ett lager som en vanlig app inte når. Anrop till de dolda klasserna från en normal applikation ger profiler som systemet aldrig listar, och därför slutar kod som verkade fungera i en bygge tyst att fungera i nästa.

Den hanterade vägen är separat. En enhets- eller profilägare kan peka ut ett alltid påslaget VPN-paket genom enhetspolicy-API:erna, och ett företagsverktyg kan skicka ut en profil som användaren sedan godkänner. Det är enhetshanteringsbefogenhet, inte en behörighet som en app begär vid installation. Om din kund är en organisation är det här vägen du måste planera för; om din kund är en person som installerar från en butik är den inte tillgänglig alls.

iOS: rättigheten är gränsen

iOS delar samma arbete annorlunda. En VPN-klient implementerar en pakettunnel-leverantör eller en app-proxy inom Network Extension-ramverket, och motsvarande rättighet måste beviljas utvecklarkontot. En personlig VPN-konfiguration genom NEVPNManager finns för det enklare fallet, och den körs fortfarande inom samma behörighetsmodell. Apple dokumenterar hela ytan i Network Extension-referensen, som är värd att läsa innan du avgränsar arbetet.

Det finns inget stödt sätt att öppna VPN-inställningsskärmen, läsa användarens sparade konfigurationer eller starta en av dem. Det en klient kan göra är att skicka en konfigurationsprofil som användaren installerar, och sedan använda den resulterande tunneln genom vanliga nätverksanrop. Tunnling per app tilldelas av en MDM-server genom en on demand-regel, inte vald av appen vid körning.

En VPN-klient från en stor leverantör är inte bevis för att ditt konto kan skicka samma sak. De rättigheterna begärs per utvecklarkonto och granskas, så tidsplanrisken ligger hos Apple, inte i din sprintplan.

Skrivbordet når längre, men ägandet är oförändrat

Windows är det tillåtande fallet. Add-VpnConnection skapar en telefonbokspost från en förhöjd PowerShell-session, och rasdial ansluter eller kopplar från den i ett skript. En app kan också styra en leverantörsklient genom dess dokumenterade kommandorad. Att skapa profilen är fortfarande en administrativ åtgärd, eftersom posten lever i ett lager för hela maskinen.

macOS beter sig på samma sätt med andra verktyg. scutil --nc start och stop arbetar på tjänster som redan finns, medan det att skapa en är en systemadministrationsuppgift. Att äga processen på en bärbar dator gör dig inte till ägare av konfigurationen.

Vad du bör bygga i stället

Om det egentliga kravet är att din app når ett internt API räcker tunneln som användaren redan kör. Skicka vanliga HTTPS-förfrågningar, låt systemet välja vägen, och sluta försöka kontrollera tunneln. Om kravet är att bara appens trafik använder tunneln, be om VPN per app genom administrationskanalen, eller avsluta TLS inne i appen mot en tjänst som nås utan.

Dolda API:er är inte en genväg som är värd att ta. De ändras mellan versioner, de misslyckas i appgranskningen, och de fel de producerar ser för den som ärver koden ut som vanliga nätverksfel. Jämförelsen är inte Android mot iOS; det är att äga en tunnel mot att be plattformen dirigera trafik, och bara det första är ditt att bygga.