Kial aplikaĵo ne povas ŝalti konservitan VPN-profilon en Android aŭ iOS

Du tre malsamaj taskoj estas metataj sub la nomon programa VPN, kaj nur unu el ili disponeblas al ordinara aplikaĵo sur iu ajn el la du moveblaj platformoj. La unua estas ŝalti profilon, kiun la uzanto jam konservis; la dua estas konstrui tunelon interne de via propra procezo. Android donas al vi la duan per VpnService kaj iOS donas al vi la duan per la rajto Network Extension, dum la unua restas ĉe la sistemo, posedanto de aparato aŭ MDM-servilo. Eltrovi, kiun vi vere bezonas, kutime malgrandigas la projekton.

Du taskoj kun la sama nomo

Aktivigi konservitan profilon signifas diri al ekzistanta tunelo, ke ĝi levu sin: gastiganto, legitimilo, protokolo, ĉio jam agordita ie, kie la uzanto povas vidi ĝin. Konstrui tunelon signifas, ke via kodo posedas la interfacon, la pakan buklon kaj la protokolon. Ili aspektas similaj en produkta listo kaj preskaŭ tute ne dividas efektivigon.

Neniu el la du moveblaj platformoj elmetas la unuan al SDK-a aplikaĵo. Konekto, kiu aperas sen ke la uzanto faru ion, ne diferencigeblas de malutila programaro, do ambaŭ sistemoj metas konsentan pordon antaŭ ĉiu aplikaĵo, kiu portas trafikon.

Android: konsenta pordo kaj neniu profila API

VpnService ekzistas ekde Android 4.0 kaj lasas aplikaĵon krei tun-interfacon, poste legi kaj skribi pakaĵojn. La servo devas esti deklarita per BIND_VPN_SERVICE, kaj VpnService.prepare() produktas la sistemdialogon, kiu petas la uzanton permesi ĝin. La platforma ekzemplo, ToyVpn, estas la plej klara eldiro de la celata formo: via kodo posedas la interfacon kaj ĉion, kio fluas tra ĝi.

Kion ĝi ne faras, estas aldoni eron al la sistema ekrano de VPN-agordoj. Por tio ne ekzistas publika API, kaj la aplikaĵo Agordoj tenas siajn profilojn en konservejo, kiun ordinara aplikaĵo ne povas atingi. Vokoj al la kaŝitaj klasoj el normala aplikaĵo produktas profilojn, kiujn la sistemo neniam listigas, tial kodo, kiu ŝajnis funkcii en unu konstruo, silente ĉesas funkcii en la sekva.

La administrata vojo estas aparta. Posedanto de aparato aŭ de profilo povas difini ĉiam-ŝaltitan VPN-pakaĵon per la API-oj de aparatpolitiko, kaj entreprena ilo povas puŝi profilon, kiun la uzanto poste aprobas. Tio estas aparat-administra aŭtoritato, ne permeso, kiun aplikaĵo petas ĉe instalado. Se via kliento estas organizo, tio estas la vojo por plani; se via kliento estas persono instalanta el butiko, ĝi tute ne disponeblas.

iOS: la rajto estas la limo

iOS dividas la saman laboron alie. VPN-kliento efektivigas pakan tunelprovizanton aŭ aplikaĵan prokuron sub la kadro Network Extension, kaj la kongrua rajto devas esti donita al la programista konto. Persona VPN-agordo per NEVPNManager ekzistas por la pli simpla kazo, kaj ĝi ankoraŭ funkcias ene de la sama permesa modelo. Apple dokumentas la tutan surfacon en la Network Extension-referenco, kiun indas legi antaŭ ol vi difinos la laboron.

Ne ekzistas subtenata maniero malfermi la ekranon de VPN-agordoj, legi la konservitajn agordojn de la uzanto aŭ startigi unu el ili. Kion kliento povas fari, estas sendi agordan profilon por ke la uzanto instalos ĝin, kaj poste uzi la rezultan tunelon per ordinaraj retaj vokoj. Tunelado por unuopa aplikaĵo estas atribuata de MDM-servilo per laŭposta regulo, ne elektata de la aplikaĵo dum rultempo.

VPN-kliento de granda provizanto ne estas pruvo, ke via konto povas sendi la saman aferon. Tiuj rajtoj estas petataj por ĉiu programista konto kaj reviziataj, do la risko pri tempoplano kuŝas ĉe Apple, ne ĉe via sprintoplano.

La labortablo atingas pli malproksimen, sed posedo restas la sama

Windows estas la permesema kazo. Add-VpnConnection kreas telefonlibran eron el levita PowerShell-sesio, kaj rasdial konektas aŭ malkonektas ĝin el skripto. Aplikaĵo ankaŭ povas peli provizantan klienton per sia dokumentita komandlinio. Krei la profilon ankoraŭ estas administra ago, ĉar la ero vivas en maŝinlarĝa konservejo.

macOS kondutas same kun aliaj iloj. scutil --nc start kaj stop funkcias sur servoj, kiuj jam ekzistas, dum krei unu estas tasko de sistema administrado. Posedi la procezon sur tekokomputilo ne faras vin posedanto de la agordo.

Kion konstrui anstataŭe

Se la vera postulo estas, ke via aplikaĵo atingas internan API, la tunelo, kiun la uzanto jam funkciigas, sufiĉas. Sendu ordinarajn HTTPS-petojn, lasu la sistemon elekti la vojon, kaj ĉesu provi regi la tunelon. Se la postulo estas, ke nur la trafiko de via aplikaĵo uzu la tunelon, petu VPN por unuopa aplikaĵo per la administra kanalo, aŭ finu TLS interne de la aplikaĵo kontraŭ servo atingebla sen ĝi.

Kaŝitaj API-oj ne estas mallonga vojo inda preni. Ili ŝanĝiĝas inter eldonoj, ili malsukcesas en aplikaĵa revizio, kaj la difektoj, kiujn ili produktas, aspektas al tiu, kiu heredas la kodon, kiel ordinaraj retaj difektoj. La komparo ne estas Android kontraŭ iOS; ĝi estas posedi tunelon kontraŭ peti la platformon enkursigi trafikon, kaj nur la unua estas via por konstrui.