Zergatik ezin duen aplikazio batek gordetako VPN profila piztu Android edo iOS-en

Bi lan oso desberdin biltzen dira VPN programatikoaren izenpean, eta horietako bakarra dago eskuragarri ohiko aplikazio batentzat bi plataforma mugikorretan. Lehena erabiltzaileak jada gordetako profila piztea da; bigarrena zure prozesuaren barruan tunela eraikitzea. Androidek bigarrena ematen dizu VpnService bidez eta iOSek bigarrena ematen dizu Network Extension baimenaren bidez, lehena sistemarekin, gailuaren jabearekin edo MDM zerbitzariarekin geratzen den bitartean. Benetan zein behar duzun argitzeak proiektua txikiagoa egiten du normalean.

Izen bera duten bi lan

Gordetako profila aktibatzeak existitzen den tunel bati altxatzeko esatea esan nahi du: ostalari bat, kredentzial bat, protokolo bat, dena jada erabiltzaileak ikus dezakeen lekuan konfiguratuta. Tunela eraikitzeak zure kodea interfazearen, pakete-begiztaren eta protokoloaren jabe dela esan nahi du. Produktu-zerrendan antzekoak dirudite eta ia ez dute inplementaziorik partekatzen.

Bi plataforma mugikorretako batek ere ez dio SDK aplikazio bati lehena eskaintzen. Erabiltzaileak ezer egin gabe agertzen den konexioa ezinezkoa da malwarearengandik bereiztea, beraz bi sistemek baimen-ate bat jartzen dute trafikoa daraman edozein aplikazioren aurrean.

Android: baimen-atea eta profil-APIrik ez

VpnService Android 4.0tik existitzen da eta aplikazio bati tun interfazea sortzen uzten dio, gero paketeak irakurtzeko eta idazteko. Zerbitzua BIND_VPN_SERVICE-rekin deklaratu behar da, eta VpnService.prepare()-k erabiltzaileari baimena eskatzen dion sistema-elkarrizketa sortzen du. Plataformaren lagina, ToyVpn, asmo den formaren adierazpen argiena da: zure kodea interfazearen eta hartatik igarotzen den guztiaren jabe da.

Egiten ez duena da sistemako VPN ezarpenen pantailari sarrera bat gehitzea. Horretarako ez dago API publikorik, eta Ezarpenak aplikazioak bere profilak ohiko aplikazio batek iristen ez duen biltegian gordetzen ditu. Aplikazio arrunt batetik klase ezkutuetara egindako deiek sistemak inoiz zerrendatzen ez dituen profilak sortzen dituzte, horregatik build batean funtzionatzen zuela zirudien kodeak hurrengoan isilka funtzionatzeari uzten dio.

Kudeatutako bidea bereizia da. Gailuaren jabeak edo profilaren jabeak beti piztuta dagoen VPN pakete bat izenda dezake gailu-politikaren APIen bidez, eta enpresa-tresna batek erabiltzaileak gero onartzen duen profila bidal dezake. Hori gailu-kudeaketaren autoritatea da, ez aplikazioak instalatzean eskatzen duen baimena. Zure bezeroa erakundea bada, hori da planifikatzeko bidea; zure bezeroa dendatik instalatzen duen pertsona bada, ez dago batere eskuragarri.

iOS: baimena da muga

iOSek lan bera bestela banatzen du. VPN bezero batek pakete-tunel hornitzaile bat edo aplikazio-proxy bat inplementatzen du Network Extension esparruan, eta dagokion baimena garatzaile-kontuari eman behar zaio. VPN konfigurazio pertsonala NEVPNManager bidez existitzen da kasu sinpleenerako, eta oraindik baimen-eredu berean exekutatzen da. Applek gainazal osoa Network Extension erreferentzian dokumentatzen du, lana mugatu aurretik irakurtzea merezi duena.

Ez dago modu onarturik VPN ezarpenen pantaila irekitzeko, erabiltzailearen gordetako konfigurazioak irakurtzeko edo horietako bat abiatzeko. Bezero batek egin dezakeena erabiltzaileak instalatuko duen konfigurazio-profil bat bidaltzea da, eta gero sortutako tunela sare-dei arruntekin erabiltzea. Aplikazio bakoitzeko tunelak MDM zerbitzari batek esleitzen du eskaeran oinarritutako arau baten bidez, ez aplikazioak exekuzio-denboran aukeratzen.

Hornitzaile handi baten VPN bezeroa ez da zure kontuak gauza bera bidal dezakeen froga. Baimen horiek garatzaile-kontu bakoitzeko eskatzen dira eta berrikusten dira, beraz egutegi-arriskua Appleen dago, ez zure sprint planean.

Mahaigainak urrunago iristen da, baina jabetza ez da aldatzen

Windows da kasu baimengarria. Add-VpnConnection-ek telefonoko liburuko sarrera bat sortzen du PowerShell saio igonean, eta rasdial-ek script batetik konektatzen edo deskonektatzen du. Aplikazio batek hornitzaile baten bezeroa ere gida dezake haren dokumentatutako komando-lerroaren bidez. Profila sortzea administrazio-ekintza da oraindik, sarrera makina osoko biltegian bizi delako.

macOSek gauza bera egiten du beste tresna batzuekin. scutil --nc start eta stop jada existitzen diren zerbitzuetan aritzen dira, eta bat sortzea sistema-administrazioaren zeregina da. Prozesuaren jabe izateak ordenagailu eramangarrian ez zaitu konfigurazioaren jabe egiten.

Zer eraiki horren ordez

Benetako baldintza zure aplikazioa barneko API batera iristea bada, erabiltzaileak jada exekutatzen duen tunela nahikoa da. Egin HTTPS eskaera arruntak, utzi sistemari bidea aukeratzen, eta utzi tunela kontrolatzen saiatzeari. Baldintza zure aplikazioaren trafikoak soilik tunela erabiltzea bada, eskatu aplikazio bakoitzeko VPN kudeaketa-kanalaren bidez, edo amaitu TLS aplikazioaren barruan horrelakorik gabe iristeko modukoa den zerbitzu baten aurka.

API ezkutuak ez dira hartzea merezi duen bide laburra. Bertsioen artean aldatzen dira, aplikazioen berrikuspenean huts egiten dute, eta sortzen dituzten hutsegiteak kodea oinordetzen duenarentzat sare-hutsegite arruntak dirudite. Konparazioa ez da Android iOSren aurka; tunel baten jabe izatea plataformari trafikoa bideratzeko eskatzearen aurka da, eta lehena soilik da zurea eraikitzeko.