Proč aplikace nemůže zapnout uložený profil VPN na Androidu nebo iOS

Dvě velmi odlišné práce se řadí pod označení programové VPN a jen jedna z nich je dostupná běžné aplikaci na kterékoli ze dvou mobilních platform. První je zapnutí profilu, který uživatel už uložil; druhá je stavba tunelu uvnitř vlastního procesu. Android vám druhou dává přes VpnService a iOS vám druhou dává přes právo Network Extension, zatímco první zůstává systému, správci zařízení nebo serveru MDM. Zjistit, kterou vlastně potřebujete, obvykle projekt zmenší.

Dvě práce se stejným jménem

Aktivace uloženého profilu znamená říct existujícímu tunelu, ať vyjede: hostitel, přihlašovací údaj, protokol, vše už nastavené někde, kde to uživatel vidí. Stavba tunelu znamená, že váš kód vlastní rozhraní, smyčku paketů a protokol. V produktovém backlogu vypadají podobně a téměř nesdílejí implementaci.

Ani jedna mobilní platforma nevystavuje první práci aplikaci na SDK. Spojení, které se objeví bez jakékoli akce uživatele, nelze odlišit od škodlivého softwaru, takže oba systémy staví bránu souhlasu před každou aplikaci, která přenáší provoz.

Android: brána souhlasu a žádné API pro profily

VpnService existuje od Androidu 4.0 a umožňuje aplikaci vytvořit rozhraní tun a potom číst a zapisovat pakety. Služba musí být deklarována s BIND_VPN_SERVICE a VpnService.prepare() vytváří systémový dialog, který žádá uživatele o povolení. Ukázka platformy ToyVpn je nejjasnějším vyjádřením zamýšleného tvaru: váš kód vlastní rozhraní i vše, co jím prochází.

Co nedělá, je přidání položky na systémovou obrazovku nastavení VPN. Veřejné API na to neexistuje a aplikace Nastavení drží své profily v úložišti, kam se běžná aplikace nedostane. Volání skrytých tříd z normální aplikace vytvářejí profily, které systém nikdy nezobrazí, a proto kód, který v jednom sestavení vypadal, že funguje, v dalším tiše přestane fungovat.

Spravovaná cesta je oddělená. Správce zařízení nebo správce profilu může určit balíček VPN, který je vždy zapnutý, pomocí API zásad zařízení a podnikový nástroj může poslat profil, který uživatel potom schválí. To je pravomoc správy zařízení, ne oprávnění, které aplikace žádá při instalaci. Pokud je vaším zákazníkem organizace, je to cesta, na kterou máte plánovat; pokud je vaším zákazníkem člověk instalující z obchodu, není dostupná vůbec.

iOS: hranicí je oprávnění

iOS dělí stejnou práci jinak. Klient VPN implementuje poskytovatele paketového tunelu nebo proxy aplikace v rámci frameworku Network Extension a odpovídající oprávnění musí být přiděleno vývojářskému účtu. Osobní konfigurace VPN přes NEVPNManager existuje pro jednodušší případ a stále běží ve stejném modelu oprávnění. Apple dokumentuje celou plochu v referenci Network Extension, kterou stojí za to si přečíst, než vymezíte práci.

Neexistuje podporovaný způsob, jak otevřít obrazovku nastavení VPN, přečíst uživatelovy uložené konfigurace nebo jednu z nich spustit. Klient může poslat konfigurační profil k instalaci uživatelem a potom výsledný tunel používat běžnými síťovými voláními. Tunelování pro jednotlivé aplikace přiděluje server MDM pravidlem na vyžádání, aplikace ho za běhu nevybírá.

Klient VPN od velkého dodavatele není důkaz, že váš účet může poslat totéž. Tato oprávnění se žádají pro každý vývojářský účet a posuzují se, takže riziko harmonogramu leží na Apple, ne na vašem plánu sprintu.

Desktop dosáhne dál, ale vlastnictví se nemění

Windows je permisivní případ. Add-VpnConnection vytváří položku telefonního seznamu ze zvýšené relace PowerShellu a rasdial ji připojuje nebo odpojuje ze skriptu. Aplikace může také řídit klientský program dodavatele přes jeho dokumentovanou příkazovou řádku. Vytvoření profilu je pořád administrativní akce, protože položka žije v úložišti pro celý stroj.

macOS se chová stejně s jinými nástroji. scutil --nc start a stop pracují se službami, které už existují, zatímco vytvoření jedné je úkol systémové administrace. Vlastnictví procesu na notebooku z vás nedělá vlastníka konfigurace.

Co postavit místo toho

Pokud je skutečným požadavkem, aby vaše aplikace dosáhla na interní API, tunel, který uživatel už provozuje, stačí. Posílejte běžné požadavky HTTPS, nechte systém vybrat cestu a přestaňte se snažit tunel ovládat. Pokud je požadavkem, aby tunel používal jen provoz vaší aplikace, požádejte o VPN pro jednotlivé aplikace přes kanál správy, nebo ukončete TLS uvnitř aplikace vůči službě dostupné bez něj.

Skrytá API nejsou zkratka, kterou stojí za to brát. Mění se mezi verzemi, selhávají v recenzi aplikací a poruchy, které vytvářejí, vypadají pro toho, kdo kód zdědí, jako běžné síťové poruchy. Srovnání není Android proti iOS; je to vlastnictví tunelu proti žádosti, aby platforma směrovala provoz, a jen první je vaše ke stavbě.