Kial via iPhone-a aplikaĵo ne povas ŝalti aŭ malŝalti la sisteman VPN
Publika aplikaĵo ne povas ŝalti la sisteman VPN, legi ĝian staton aŭ devigi konekton. Reguloj On Demand, profiloj Always On sur kontrolataj aparatoj kaj MDM estas la ebloj.
Produkta manaĝero petas butonon, kiu ŝaltas la firmaan VPN, kaj la peto sonas banala. En iOS tio ne estas malgranda trajto; ĝi staras ekster la publika kontrakto, kaj ĉiu ĉirkaŭvojo aŭ malsukcesas en la revizio aŭ rompiĝas en la sekva eldono. Trapasu la peton tra tio, kion la platformo efektive permesas, kaj la dezajno preskaŭ skribas sin mem. Aplikaĵo povas posedi VPN-agordon kaj lanĉi ĝin. Aplikaĵo ne povas atingi la sisteman ŝaltilon, ne povas legi la staton de profilo, kiun ĝi ne kreis, kaj ne povas teni uzanton konektita kontraŭ ties volo.
Komencu de la tri aferoj, kiujn la uzanto celas
Apartigu la signifojn antaŭ ol apartigi la API-ojn. Foje la uzanto volas, ke la tunelo de via aplikaĵo estu konektita, foje li volas ŝalti la ŝaltilon en Agordoj por profilo, kiun instalas iu alia, kaj foje li volas, ke la telefono ne povu retumi sen la tunelo. Tiuj respondas al tri malsamaj mekanismoj, kaj nur la unua estas malfermita al ordinara aplikaĵo.
La dua signifo estas tiu, kiu generas la demandojn de Stack Overflow, kaj ĝi havas nenian subtenatan respondon. La ŝaltilo en Agordoj apartenas al la uzanto kaj, sur administrataj aparatoj, al la profilo. Neniu publika API listigas VPN-agordojn, raportas ĉu la sistema tunelo estas supre, aŭ ŝaltas ĝin.
Kion aplikaĵo efektive povas krei
NetworkExtension donas al aplikaĵo propran agordon per NEVPNManager. Kun la rajto Personal VPN kaj la konsento de la uzanto, la aplikaĵo konservas agordon, kiu aperas en Agordoj sub ĝia propra nomo, kaj ĝi povas lanĉi aŭ haltigi tiun unu konekton. Tio estas reala, reviziebla kapablo, kaj ĝi ankaŭ estas la tuta amplekso: la administranto legas kaj skribas nur tion, kion ĝi kreis.
La rajto ne estas aŭtomata. Vi petas ĝin de Apple kaj pravigas, kial la aplikaĵo entute bezonas tunelon, kaj kliento, kies sola celo estas ŝalti la profilon de iu alia, havas neniun bonan respondon. Provizantoj de pakaĵtuneloj sekvas la saman regulon per alia klaso: NETunnelProviderManager posedas provizant-bazitajn agordojn, kiujn la aplikaĵo mem instalas. Neniu el la du vojoj atingas profilon, kiun liveris MDM.
Konsento validas ankaŭ je la konserva momento. Skribi agordon demandas la uzanton, kaj tiu demando ne estas io, kion aplikaĵo rajtas subpremi por komforto.
Legi la staton trafas la saman muron
Statuso aspektas pli amika ol kontrolo kaj estas same fermita. NEVPNStatus raportas malvalidan, malkonektitan, konektantan, konektitan, relanĉantan aŭ malkonektantan por la propra agordo de la aplikaĵo, kaj ĉe ĉiu ŝanĝo ekas sciigo. Ĝi diras nenion pri tunelo instalita de administra profilo, kaj ĝuste tion helpcentro volas vidi.
Retvoja monitorado kaj interfacaj ŝanĝoj estas proponataj kiel anstataŭaĵoj en dezajnaj revizioj. Ili priskribas la vojon, kiun prenas la trafiko de la aplikaĵo, kiu ŝanĝiĝas pro kialoj senrilataj al la VPN-stato, kaj uzi ilin kiel VPN-legado donas interfacon, kiu mensogas en ambaŭ direktojn.
On Demand kaj Always On estas la veraj leviloj
La subtenataj leviloj loĝas en la profilo, ne en la aplikaĵo. Reguloj On Demand diras al la sistemo, kiam konekti: ordigita listo de kondiĉoj kun agoj, taksata de la operaciumo, ne de via kodo. Regulo, kiu konektas sur ajna interfaco, kreas senton de ĉiama konekto sen doni al iu aplikaĵo kontrolon.
Always On VPN estas la deviga mekanismo, kaj ĝi ligiĝas al superrigardo. Sur superrigardata aparato, MDM instalas profilon, kiu tenas la tunelon supre; sur persona telefono sen superrigardo la samaj ŝlosiloj ne produktas la saman konduton. Tiu nesimetrio estas intenca, kaj neniu kombinaĵo de utilŝarĝaj ŝlosiloj forigas ĝin. Kiam la postulo vere estas, ke la VPN devas esti ŝaltita, la postulo fakte estas, ke la aparato devas esti administrata.
Inter la du sidas la pli malforta kuzo: regulo, kiu rekonektas post kiam la uzanto malkonektiĝas. Ĝi rekonektas kiam la regulo estas taksata venontfoje, kio ne samas al tuj, kaj uzanto, kiu malkonektiĝis intence, rimarkos la diferencon. Dezajnu la interfacon ĉirkaŭ tiu breĉo anstataŭ promesi seruron.
Liveru la subtenatan vojon
Kvar demandoj decidas la mekanismon antaŭ ol ekzistas iu ajn kodo: kiu posedas la aparaton, ĉu ĝi estas superrigardata, kiu kliento finas la tunelon, kaj de kie venas la profilo. Se io el tio estas nekonata, la trajtopeto ne pretas por takso.
Privata API, kiu tuŝetas la sisteman VPN, trapasos demon kaj malsukcesos en la revizio, kaj se ĝi estos liverita alimaniere, ĝi rompiĝos en la sekva iOS-eldono. Ne ekzistas versio de tiu interŝanĝo inda je unu ŝaltilo.
Administra telemetrio estas aparta kanalo: ĝi raportas, ke profilo estas instalita kaj ĉu la aparato konformas, kio estas raportado, ne rega surfaco por aplikaĵo. Testu la fluon sur reala aparato post ĉiu ĝisdatigo, ĉar la subtenata konduto loĝas en la operaciumo, kaj la operaciumo moviĝas.