Waarom ’n app nie ’n gestoorde VPN-profiel op Android of iOS kan aanskakel nie

Twee baie verskillende take word onder programmeerbare VPN ingedeel, en net een daarvan is vir ’n gewone app op enige van die twee mobiele platforms beskikbaar. Die eerste is om ’n profiel aan te skakel wat die gebruiker reeds gestoor het; die tweede is om ’n tonnel binne jou eie proses te bou. Android gee jou die tweede deur VpnService en iOS gee jou die tweede deur die Network Extension-reg, terwyl die eerste by die stelsel, ’n toestel-eienaar of ’n MDM-bediener bly. Om uit te werk watter een jy werklik nodig het, maak die projek gewoonlik kleiner.

Twee take wat dieselfde naam deel

Om ’n gestoorde profiel te aktiveer beteken om vir ’n bestaande tonnel te sê om op te kom: ’n gasheer, ’n geloofsbrief, ’n protokol, alles reeds opgestel op ’n plek wat die gebruiker kan sien. Om ’n tonnel te bou beteken jou kode besit die koppelvlak, die pakketlus en die protokol. Hulle lyk soortgelyk in ’n produkagterstand en hulle deel byna geen implementering nie.

Nie een van die mobiele platforms stel die eerste aan ’n SDK-app bloot nie. ’n Verbinding wat verskyn sonder dat die gebruiker iets doen, is nie van wanware te onderskei nie, so albei stelsels plaas ’n toestemmingshek voor enige app wat verkeer dra.

Android: ’n toestemmingshek, en geen profiel-API nie

VpnService bestaan sedert Android 4.0 en laat ’n app ’n tun-koppelvlak skep, dan pakkette lees en skryf. Die diens moet met BIND_VPN_SERVICE verklaar word, en VpnService.prepare() lewer die stelseldialoog wat die gebruiker vra om dit toe te laat. Die platformvoorbeeld, ToyVpn, is die duidelikste stelling van die beoogde vorm: jou kode besit die koppelvlak en alles wat daardeur vloei.

Wat dit nie doen nie, is om ’n inskrywing by die stelsel se VPN-instellingsskerm te voeg. Daar is geen openbare API daarvoor nie, en die Instellings-app hou sy profiele in ’n stoor wat ’n gewone app nie kan bereik nie. Oproepe na die verborge klasse vanuit ’n normale toepassing lewer profiele wat die stelsel nooit lys nie, en daarom hou kode wat op een bou gelyk het of dit werk, stilweg op om op die volgende een te werk.

Die bestuurde pad is apart. ’n Toestel-eienaar of profiel-eienaar kan ’n altyd-aan VPN-pakket deur die toestelbeleid-API’s aanwys, en ’n ondernemingsinstrument kan ’n profiel stuur wat die gebruiker dan goedkeur. Dit is toestelbestuurgesag, nie ’n toestemming wat ’n app by installasie aanvra nie. As jou kliënt ’n organisasie is, is dit die roete om voor te beplan; as jou kliënt ’n persoon is wat uit ’n winkel installeer, is dit glad nie beskikbaar nie.

iOS: die reg is die grens

iOS verdeel dieselfde werk anders. ’n VPN-kliënt implementeer ’n pakkettunnel-verskaffer of ’n app-proksie onder die Network Extension-raamwerk, en die ooreenstemmende reg moet aan die ontwikkelaarsrekening toegeken word. ’n Persoonlike VPN-opstelling deur NEVPNManager bestaan vir die eenvoudiger geval, en dit loop steeds binne dieselfde toestemmingsmodel. Apple dokumenteer die hele oppervlak in die Network Extension-verwysing, wat die moeite werd is om te lees voordat jy die werk bepaal.

Daar is geen ondersteunde manier om die VPN-instellingsskerm oop te maak, die gebruiker se gestoorde opstellings te lees of een daarvan te begin nie. Wat ’n kliënt kan doen, is om ’n opstellingsprofiel te lewer wat die gebruiker installeer, en dan die resulterende tonnel deur gewone netwerkoproepe te gebruik. Per-app-tonnelering word deur ’n MDM-bediener deur ’n op-aanvraag-reël toegewys, nie deur die app tydens looptyd gekies nie.

’n VPN-kliënt van ’n groot verskaffer is nie bewys dat jou rekening dieselfde ding kan lewer nie. Daardie regte word per ontwikkelaarsrekening aangevra en hersien, so die skedulerisiko lê by Apple, nie by jou sprintplan nie.

Die rekenaar reik verder, maar eienaarskap bly dieselfde

Windows is die toegeeflike geval. Add-VpnConnection skep ’n telefoonboekinskrywing vanuit ’n verhoogde PowerShell-sessie, en rasdial verbind of ontkoppel dit vanuit ’n skrip. ’n App kan ook ’n verskaffer-kliënt deur sy gedokumenteerde opdragreël dryf. Om die profiel te skep is steeds ’n administratiewe aksie, want die inskrywing woon in ’n masjienwye stoor.

macOS gedra hom dieselfde met ander gereedskap. scutil --nc start en stop werk op dienste wat reeds bestaan, terwyl die skep van een ’n stelseladministrasietaak is. Om die proses op ’n skootrekenaar te besit, maak jou nie die eienaar van die opstelling nie.

Wat om eerder te bou

As die werklike vereiste is dat jou app ’n interne API bereik, is die tonnel wat die gebruiker reeds gebruik genoeg. Maak normale HTTPS-versoeke, laat die stelsel die pad kies, en hou op om die tonnel te probeer beheer. As die vereiste is dat net jou app se verkeer die tonnel gebruik, vra vir per-app VPN deur die bestuurskanaal, of termineer TLS binne die app teen ’n diens wat sonder een bereikbaar is.

Verborge API’s is nie ’n kortpad wat die moeite werd is nie. Hulle verander tussen uitgawes, hulle faal app-hersiening, en die foute wat hulle lewer, lyk vir elkeen wat die kode erf soos gewone netwerkfoute. Die vergelyking is nie Android teenoor iOS nie; dit is om ’n tonnel te besit teenoor om die platform te vra om verkeer te lei, en net die eerste een is joune om te bou.