Зашто апликација не може да укључи сачувани VPN профил на Android-у или iOS-у

Два веома различита посла сврставају се под назив програмског VPN-а, а само један од њих је доступан обичној апликацији на било којој од две мобилне платформе. Први је укључивање профила који је корисник већ сачувао; други је прављење тунела унутар сопственог процеса. Android вам даје други преко VpnService, а iOS вам даје други преко права Network Extension, док први остаје код система, власника уређаја или MDM сервера. Утврђивање који вам је заиста потребан обично чини пројекат мањим.

Два посла са истим именом

Активирање сачуваног профила значи рећи постојећем тунелу да се подигне: домаћин, акредитив, протокол, све већ конфигурисано негде где корисник може да види. Прављење тунела значи да ваш код поседује интерфејс, петљу пакета и протокол. У продуктном списку изгледају слично и скоро да не деле имплементацију.

Ниједна мобилна платформа не излаже први посао SDK апликацији. Веза која се појави без икакве радње корисника не разликује се од злонамерног софтвера, зато оба система стављају капију сагласности пред сваку апликацију која преноси саобраћај.

Android: капија сагласности и никакав API за профиле

VpnService постоји од Android-а 4.0 и омогућава апликацији да направи tun интерфејс, а затим чита и пише пакете. Сервис мора бити декларисан са BIND_VPN_SERVICE, а VpnService.prepare() ствара системски дијалог који тражи од корисника да га дозволи. Пример платформе, ToyVpn, најјаснија је изјава предвиђеног облика: ваш код поседује интерфејс и све што кроз њега пролази.

Оно што не ради јесте додавање ставке на системски екран VPN подешавања. За то нема јавног API-ја, а апликација Подешавања држи своје профиле у складишту до којег обична апликација не може да дође. Позиви скривених класа из нормалне апликације стварају профиле које систем никада не наводи, зато код који је изгледао да ради у једној изградњи тихо престаје да ради у следећој.

Управљана путања је одвојена. Власник уређаја или профила може да одреди пакет VPN-а који је увек укључен преко API-ја политике уређаја, а корпоративни алат може да пошаље профил који корисник потом одобри. То је овлашћење за управљање уређајем, а не дозвола коју апликација тражи при инсталацији. Ако је ваш клијент организација, то је путања за коју треба планирати; ако је ваш клијент особа која инсталира из продавнице, она уопште није доступна.

iOS: право је граница

iOS дели исти посао другачије. VPN клијент имплементира добављача пакетног тунела или прокси апликације у оквиру Network Extension, а одговарајуће право мора бити додељено налогу програмера. Лична VPN конфигурација преко NEVPNManager постоји за једноставнији случај и она и даље ради у истом моделу дозвола. Apple документује целу површину у референци Network Extension, коју вреди прочитати пре него што одредите обим посла.

Нема подржаног начина да се отвори екран VPN подешавања, прочитају корисникове сачуване конфигурације или покрене једна од њих. Клијент може да пошаље конфигурациони профил који корисник инсталира, а затим да користи настали тунел преко обичних мрежних позива. Тунелирање по апликацији додељује MDM сервер правилом на захтев, а не бира га апликација у време извршавања.

VPN клијент великог добављача није доказ да ваш налог може да пошаље исто. Та права се траже по налогу програмера и прегледају, зато ризик распореда лежи на Apple-у, а не у вашем плану спринта.

Десктоп досеже даље, али власништво је исто

Windows је дозвољавајући случај. Add-VpnConnection ствара ставку у телефонском именику из подигнуте PowerShell сесије, а rasdial је повезује или прекида из скрипте. Апликација може и да управља клијентом добављача преко његове документоване команде линије. Прављење профила је и даље административна радња, јер ставка живи у складишту целе машине.

macOS се понаша исто са другим алатима. scutil --nc start и stop раде на услугама које већ постоје, док је прављење једне задатак системске администрације. Поседовање процеса на лаптопу не чини вас власником конфигурације.

Шта уместо тога изградити

Ако је прави захтев да ваша апликација достигне интерни API, довољан је тунел који корисник већ покреће. Шаљите обичне HTTPS захтеве, пустите систем да изабере пут, и престаните да покушавате да контролишете тунел. Ако је захтев да само саобраћај ваше апликације користи тунел, затражите VPN по апликацији преко канала управљања, или завршите TLS унутар апликације према услузи доступној без њега.

Скривени API-ји нису пречица коју вреди узети. Мењају се између издања, падају на прегледу апликација, а откази које производе изгледају ономе ко наследи код као обични мрежни откази. Поређење није Android против iOS-а; то је поседовање тунела против захтева да платформа усмерава саобраћај, и само је прво ваше да се изгради.