De ce o aplicație nu poate activa un profil VPN salvat pe Android sau iOS

Două lucrări foarte diferite intră sub numele de VPN programatic, și doar una dintre ele este disponibilă unei aplicații obișnuite pe oricare dintre cele două platforme mobile. Prima este activarea unui profil pe care utilizatorul l-a salvat deja; a doua este construirea unui tunel în propriul proces. Android vă dă a doua prin VpnService, iar iOS vă dă a doua prin dreptul Network Extension, în timp ce prima rămâne la sistem, la un proprietar al dispozitivului sau la un server MDM. Aflarea celei de care aveți nevoie cu adevărat face de obicei proiectul mai mic.

Două lucrări cu același nume

Activarea unui profil salvat înseamnă să spuneți unui tunel existent să urce: un gazdă, o acreditare, un protocol, toate deja configurate undeva unde utilizatorul le poate vedea. Construirea unui tunel înseamnă că codul dumneavoastră deține interfața, bucla de pachete și protocolul. Se aseamănă într-un backlog de produs și aproape nu împart implementarea.

Niciuna dintre cele două platforme mobile nu expune prima unei aplicații SDK. O conexiune care apare fără ca utilizatorul să facă nimic nu poate fi distinsă de programe malware, așa că ambele sisteme pun o poartă de consimțământ în fața oricărei aplicații care transportă trafic.

Android: o poartă de consimțământ și niciun API de profiluri

VpnService există din Android 4.0 și permite unei aplicații să creeze o interfață tun, apoi să citească și să scrie pachete. Serviciul trebuie declarat cu BIND_VPN_SERVICE, iar VpnService.prepare() produce dialogul de sistem care îi cere utilizatorului să îl permită. Exemplul platformei, ToyVpn, este cea mai clară declarație a formei intenționate: codul dumneavoastră deține interfața și tot ce curge prin ea.

Ceea ce nu face este să adauge o intrare pe ecranul de setări VPN al sistemului. Nu există API public pentru asta, iar aplicația Setări își ține profilurile într-un depozit la care o aplicație obișnuită nu ajunge. Apelurile către clasele ascunse dintr-o aplicație normală produc profiluri pe care sistemul nu le listează niciodată, de aceea codul care părea să funcționeze într-o compilare încetează în tăcere să funcționeze în următoarea.

Calea administrată este separată. Un proprietar al dispozitivului sau al profilului poate desemna un pachet VPN mereu activ prin API-urile de politică ale dispozitivului, iar un instrument enterprise poate trimite un profil pe care utilizatorul îl aprobă apoi. Aceasta este autoritate de administrare a dispozitivului, nu o permisiune pe care o aplicație o cere la instalare. Dacă clientul dumneavoastră este o organizație, aceasta este calea pentru care trebuie să planificați; dacă clientul dumneavoastră este o persoană care instalează dintr-un magazin, ea nu este deloc disponibilă.

iOS: dreptul este granița

iOS împarte aceeași lucrare altfel. Un client VPN implementează un furnizor de tunel de pachete sau un proxy de aplicație în cadrul Network Extension, iar dreptul corespunzător trebuie acordat contului de dezvoltator. O configurație VPN personală prin NEVPNManager există pentru cazul mai simplu și rulează în continuare în același model de permisiuni. Apple documentează întreaga suprafață în referința Network Extension, care merită citită înainte de a delimita lucrarea.

Nu există nicio modalitate acceptată de a deschide ecranul de setări VPN, de a citi configurațiile salvate ale utilizatorului sau de a porni una dintre ele. Ce poate face un client este să trimită un profil de configurare pe care utilizatorul îl instalează, apoi să folosească tunelul rezultat prin apeluri de rețea obișnuite. Tunelarea per aplicație este atribuită de un server MDM printr-o regulă la cerere, nu este aleasă de aplicație în timpul execuției.

Un client VPN de la un furnizor mare nu este dovada că contul dumneavoastră poate trimite același lucru. Acele drepturi sunt solicitate per cont de dezvoltator și verificate, așa că riscul de calendar stă la Apple, nu în planul dumneavoastră de sprint.

Desktopul ajunge mai departe, dar proprietatea nu se schimbă

Windows este cazul permisiv. Add-VpnConnection creează o intrare în cartea de telefon dintr-o sesiune PowerShell ridicată, iar rasdial o conectează sau o deconectează dintr-un script. O aplicație poate conduce și un client al furnizorului prin linia sa de comandă documentată. Crearea profilului rămâne o acțiune administrativă, pentru că intrarea trăiește într-un depozit la nivelul întregii mașini.

macOS se comportă la fel cu alte instrumente. scutil --nc start și stop operează pe servicii care există deja, în timp ce crearea unuia este o sarcină de administrare a sistemului. Deținerea procesului pe un laptop nu vă face proprietarul configurației.

Ce să construiți în schimb

Dacă cerința reală este ca aplicația dumneavoastră să ajungă la un API intern, tunelul pe care utilizatorul îl rulează deja este suficient. Trimiteți cereri HTTPS obișnuite, lăsați sistemul să aleagă calea, și opriți-vă din a încerca să controlați tunelul. Dacă cerința este ca doar traficul aplicației dumneavoastră să folosească tunelul, cereți VPN per aplicație prin canalul de administrare, sau terminați TLS în interiorul aplicației față de un serviciu accesibil fără el.

API-urile ascunse nu sunt o scurtătură care merită luată. Se schimbă între versiuni, eșuează la revizuirea aplicațiilor, iar defecțiunile pe care le produc arată pentru cel care moștenește codul ca defecțiuni obișnuite de rețea. Comparația nu este Android contra iOS; este deținerea unui tunel contra cererii ca platforma să dirijeze traficul, și doar prima este a dumneavoastră de construit.