IKEv2-VPN-profiloj en Android apartenas al la uzanto, ne al la aparato

La esprimo enkonstruita VPN en Android kovras du senrilatajn aferojn: protokolan efektivigon, kiun la platformo plenumas anstataŭ vi, kaj la formon de agordoj, kiun la fabrikanto decidis montri. Tiuj ne estas la sama objekto, kaj nek unu garantiis, ke la tunelo apartenas al la uzanto, kies aplikaĵoj bezonas ĝin. La provizado okazas en difinita uzanto kun difinita alvokanta pako, kaj ĉio posta heredas tiun kuntekston. Legu la posedan ĉenon antaŭ la agorda ekrano.

Kion la platformo konstruas por vi

Ekde Android 11 la platformo elmetas VPN-provizadon per VpnManager. Aprobita aplikaĵo priskribas IKEv2-profilo, kaj la platformo mem plenumas la interŝanĝon IPsec kaj IKE, do la aplikaĵo neniam tuŝas pakojn. Tio estas la signifa diferenco de propra VPN-aplikaĵo, kiu efektivigas VpnService kaj konstruas la tunelon en sia propra procezo.

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

La supra alvoko estas skizo de la formo, ne bloko por kopii: la konstruilo havas plurajn variantojn de aŭtentigo, ili diferencas laŭ API-nivelo, kaj la profilo ankaŭ portas la fido-materialon de la servila atestilo. Por la posedo-demando, la grava parto estas pli mallarĝa ol la sintakso.

El tiu dezajno sekvas du ecoj. La profilo estas datumoj, do administranto povas provizi ĝin anstataŭ tajpi mane. Kaj la tunelo estas platforma reto, do ĝi aperas al aplikaĵoj kiel reto kun VPN-transporto, ne kiel ingo de alia aplikaĵo.

La posedanto estas la uzanto, poste la pako

La pluruzanta Android estas reala apartigo, ne etikedo. La labora profilo estas aparta uzanto kun propraj instalitaj pakoj, propraj aplikaĵaj datumoj, propra ŝlosilujo kaj propraj fido-ankroj. La sama produkto instalita en ambaŭ lokoj estas du ekzempleroj kun malsamaj uzant-identigiloj, eĉ kiam la lanĉilaj ikonoj kaj produktnomoj estas identaj.

La provizado estas registrata kontraŭ la alvokanta pako en tiu uzanto. Do provizanta aplikaĵo kuranta en la persona profilo kreas personan tunelon, kaj la laboraj aplikaĵoj en la labora profilo vidas nenion de ĝi. Ankaŭ la malo veras, tial laborprofila tunelo estas nevidebla al personaj aplikaĵoj sen eksplicita politiko diranta alie.

Regilo de aparata politiko povas provizi nome de administrata profilo, kio klarigas la eron, kiun neniu en la oficejo memoras krei. Se vi aŭditas telefonon, tiu estas la verŝajna posedanto de griza profilo, kaj ne via tasko forigi ĝin kiel eksperimenton.

Tri pordegoj antaŭ ol pako moviĝas

La unua pordego estas aŭtoritato: la administrado devas tute permesi VPN, kaj kelkaj enkondukoj limigas la tipon krom la ekziston. La dua estas identeco: la klienta atestilo aŭ akreditaĵoj devas esti disponeblaj en la uzanto posedanta la profilon, ĉar atestilo importita en la personan ŝlosilujon ne videblas al la labora profilo.

La tria estas konsento kaj politiko. Uzanto kutime aprobas la konekton je la unua uzo, kaj administranto povas krome fiksi ĝin kiel ĉiam-ŝalta, laŭelekte kun ŝloso por ke trafiko ne povu eliri ekster la tunelon. Tiuj agordoj decidas, kio okazas kiam la tunelo estas malsupra, kaj tio estas la parto, kiun uzantoj rimarkas.

La amplekso estas kie la tri renkontiĝas. La profilo difinas la enirejon kaj la identecon, dum la politika tavolo decidas, kiuj aplikaĵoj rajtas uzi la tunelon kaj ĉu la trafiko estas devigata tra ĝi. Tial du telefonoj kun identaj enirejaj adresoj povas konduti tre malsame.

Kial persona konekto ne kovras laborajn aplikaĵojn

Trafiko de labora aplikaĵo estiĝas en la labora uzanto, kaj la valida reta politiko estas tiu en tiu uzanto. Tunelo starigita en la persona profilo ne portas ĝin, kiel ajn sana la indikilo aspektas. Tiu sola fakto klarigas la plej multajn raportojn, kie uzanto ĵuras, ke la VPN estas konektita kaj unu specifa aplikaĵo tamen ne atingas internan servon.

Nomsolvado sekvas la saman limon. Privataj DNS-sufiksoj kaj fido-ankroj estas po uzanto, do interna gastigantnomo, kiu solviĝas en la persona profilo, povas malsukcesi en la labora profilo eĉ kun ŝajne ekvivalenta tunelo, ĉar la solvila politiko kaj la CA-ŝlosilujo estas malsamaj objektoj.

Kontrolu en reala aliĝo, ne en laboratoria telefono

Sur la aparato, unue identigu la posedanton de la ero: kiu uzanto, kiu pako, kaj ĉu la profilo venis de la platforma provizanto aŭ de aplikaĵo kun propra VPN-servo. Poste konfirmu, ke la identeco, kiun la profilo atendas, efektive ĉeestas en la ŝlosilujo de tiu uzanto.

Testu la vivciklon, ne nur la konekton. Salutu, malŝlosu la akreditaĵan ŝlosilujon, lasu la laboran profilon paŭzi por la vespero, poste revenigu ĝin kaj kontrolu, ĉu la tunelo revenas sen mana tuŝo. Labora profilo, kiu malŝaltiĝas post la labortempo, kunportas sian tunelon, kaj tio estas atendata konduto, ne fuŝo, se la atendata nehavebla stato estas dokumentita.

Fine, testu la laboran aplikaĵon mem kontraŭ konata interna finpunkto kaj komparu kun la rezulto de la persona profilo. Ili rajtas diferenci; tio, kio ne rajtas diferenci, estas la posedmodelo. Se la tunelo apartenas al la malĝusta uzanto, nenia reeldono de atestiloj riparos ĝin.

Ne trudu la aferon lanĉante kaŝitajn agordajn agadojn por malkaŝi menuon, kaj ne kopiu privatajn ŝlosilojn inter profiloj por igi konekton aperi. La referenco VpnManager dokumentas, kion alvokanto rajtas provizi; se la aprobita vojo ne inkluzivas vian kazon, tio estas decido por la administranto, ne agorda problemo.