Zergatik zure Android aplikazioak ezin duen sistemako VPN profil bat gehitu

Ezarpenetan VPN errenkada ukitzen duzu, beste norbaitek instalatutako profila ikusten duzu eta hura gehitzen duen deia bilatzen hasten zara. Ez dago halako deirik. Aplikazio batek bere tunela ireki dezake VpnService bidez, baina zerrenda horretako sarrerak plataformarenak eta hura sortu zuen bezeroarenak dira. Mugak non dagoen zehazki jakiteak aste bat aurreztuko dizu ezkutuko klaseen atzetik.

Hasi Ezarpenen pantailak erakusten duenarekin

VPN zerrenda sistema edo hornitzaile baten bezeroak instalatutako profilen erregistroa da: PPTP, L2TP/IPsec, IKEv2 eta OEM aplikazio edo MDM batek bultzatutako errenkadak. Errenkada bakoitzak zerbitzari helbide bat, kredentzialak eta zure prozesutik kanpo bizi den protokolo inplementazio bat daramatza. Erabiltzaileak han Konektatu ukitzen duenean, plataformaren bezeroak altxatzen du tunela, ez zure kodeak. Horregatik bizirauten du errenkadak berrabiaraztean eta horregatik ez du zure aplikazioa desinstalatzeak inoiz kentzen.

Erabiltzailearen ikuspegitik zerrendak API azalera bat dirudi, VPN bat gehitzea intent bat besterik ez litzatekeen lekua. Ez da. Hura ukitzen duten sarrera publiko bakarrak nabigazio intentak dira, eta hara idazten duen guztia plataformarena edo osagai pribilegiatu batena da.

Ondorio praktikoa: laguntza-testu batek erabiltzaileei profila Ezarpenetan gehitzeko esaten badie, zure aplikazioa ez da fluxu horren parte batere.

Zer ematen dizun VpnService-ek benetan

VpnService eta VpnService.Builder zure aplikazioak duen tunel bat deskribatzen dute. Helbideak, ibilbideak, DNS zerbitzariak eta MTU bat gehitzen dituzu, trafikoa addAllowedApplication() edo addDisallowedApplication() bidez mugatzen duzu, eta gero establish() funtzioak TUN interfaze baterako ParcelFileDescriptor bat itzultzen du. Une horretatik aurrera aplikazioak IP paketeak irakurtzen eta erantzunak idazten ditu, hau da, protokoloa zurea da inplementatzeko edo txertatzeko: OpenVPN, WireGuard, garraiobide pertsonalizatua.

Sekuentzia horretan ezerk ez du PPTP, L2TP/IPsec edo IKEv2 hitz egiten. Builderrek ez du sistemaren L2TP bezeroa erabili esaten duen etengailurik, eta ez dago plataformak jada duen profil bat gidatzeko aukera ematen duen callbackik. Hori da benetako muga, eta diseinu-muga da, ez baimen hutsune bat.

Beraz, aplikazio bat erabat izan daiteke VPN bezeroa Androiden. Bakarrik ezin du telefonoarekin datozen bezeroen kudeatzaile izan.

Baimen-elkarrizketa ez da apaingarria

Zure tunelak beste aplikazioen trafikoa harrapa dezakeenez, sistemak erabiltzaileak berariaz onartzea eskatzen du. prepare() funtzioak abiarazi behar duzun Intent bat itzultzen du, onespena zure paketeari lotuta dago, eta tunela martxan dagoen bitartean egoera-barrak etengabeko adierazle bat erakusten du. Altxatzen den bigarren VPN batek lehenengoa desaktibatzen du, Androidek VPN aktibo bakarra exekutatzen baitu aldi berean.

Aktibo bakarraren arauak jendea estropezuarazten du probetan. Zure tunela altxatzen duzu bezero korporatibo bat konektatuta dagoela eta zure kodea hondatuta dagoela ondorioztatzen duzu, plataformak beste bezeroarengandik besterik gabe aldatu duenean. Onespenak geroago balia daitezke, eta prepare() funtzioak null itzul dezake onespen-jarduera falta den gailuetan, beraz establish() funtzioak hutsa kudeatu behar du oraindik.

API ezkutuak eta ezarpen-intentak

Erantzun zaharragoek com.android.internal klaseak eta AIDL interfazeak aipatzen dituzte, barneko bezeroak erabiltzen dituenak. Ez daude SDKan, argitalpenen artean aldatzen dira abisurik gabe, eta aplikazio-dendek arriskutzat jotzen dute sarbide hori. Gailua rootatzeak ere ez ditu egonkor bihurtzen, roota eta API ezkutuen sarbidea arazo desberdinak baitira.

Onartutako nabigazio-laguntzailea Settings.ACTION_VPN_SETTINGS da, eta haren balioa android.net.vpn.SETTINGS da. Ebatz ezazu abiarazi aurretik, OEM bertsio batzuek ez baitute jarduera hori bidaltzen, eta joan idatzitako urratseetara ebazpenak huts egiten duenean. Erabiltzailea pantailara eramaten du eta ez du ezer konfiguratzen.

Gailuaren jabearen eta MDMren bideak jendeak normalean esan nahi duen salbuespena dira. DevicePolicyManagerrek beti aktibo dagoen VPN pakete bat izenda dezake, eta kudeatutako konfigurazioek haiek onartzen dituen bezero baterako ezarpenak aurrez karga ditzakete, baina hori oraindik ez da PPTP profil bat idazten duen SDK publikoa.

Erabakiaren ibilbidea erabiltzailearen aldetik

Zure produktuak trafikoa eraman behar badu, VpnService eta benetako protokolo-pila bat planifikatu, eta denbora aurreikusi onespen-fluxurako eta VPN bakarraren araurako. Helburua lehendik dagoen profil korporatibo batera konektatzea bada, zure lana gidatzea da: esteka sakona ezarpen-pantailara, eremuak dokumentatu, eta utzi plataformaren bezeroari tunela egiten. Aplikazioak amaiera-puntu pribatu batera iritsi behar badu soilik, ez du bere tunelik behar.

Idatzi erabaki hori kodea idatzi aurretik, hiru bideek ia ezer ez baitute elkarrekin lehen sprinta ondoren.

Azken egiaztapena hasi aurretik: eskakizunak gure aplikazioa konektatzen dela dio, edo gailua konektatzen dela? Lehenengoa VpnService da, bigarrena ezin duzun sortu profil bat. Esaldi hori ondo asmatzea edozein berregituratze baino merkeagoa da.