Profili VPN IKEv2 v Androidu pripadajo uporabniku, ne napravi

Izraz vgrajeni VPN v Androidu pokriva dve nepovezani stvari: izvedbo protokola, ki jo platforma izvaja v vašem imenu, in tisto obliko nastavitev, ki se jo je proizvajalec odločil razkriti. To nista isti objekt in nobeno od tega ne zagotavlja, da tunel pripada uporabniku, katerega aplikacije ga potrebujejo. Vzpostavitev se zgodi v določenem uporabniku z določenim klicočim paketom in vse, kar sledi, to okolje podeduje. Preberite verigo lastništva, preden preberete zaslon z nastavitvami.

Kaj platforma zgradi za vas

Od Androida 11 platforma izpostavlja vzpostavljanje VPN prek VpnManager. Odobrena aplikacija opiše profil IKEv2, platforma pa sama izvede izmenjavo IPsec in IKE, tako da se aplikacija nikoli ne dotakne paketov. To je bistvena razlika od lastne aplikacije VPN, ki izvaja VpnService in tunel zgradi v svojem procesu.

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

Zgornji klic je skica oblike, ne blok za kopiranje: graditelj ima več različic preverjanja pristnosti, te se razlikujejo glede na raven API, profil pa nosi tudi gradivo zaupanja strežnikovega potrdila. Za vprašanje lastništva je pomembno ožje od skladnje.

Iz te zasnove izhajata dve lastnosti. Profil so podatki, zato ga lahko vzpostavi skrbnik, namesto da bi ga vnašali ročno. In tunel je omrežje platforme, zato se aplikacijam kaže kot omrežje s prenosom VPN, ne kot vtičnica druge aplikacije.

Lastništvo je najprej uporabnik, nato paket

Večuporabniški način v Androidu je resnična ločitev, ne oznaka. Delovni profil je ločen uporabnik z lastnimi nameščenimi paketi, lastnimi podatki aplikacij, lastnim keystoreom in lastnimi sidri zaupanja. Isti izdelek, nameščen na obeh mestih, sta dva primerka z različnimi uporabniškimi identifikatorji, tudi ko so ikone v zaganjalniku in imena izdelka enaki.

Vzpostavitev se zabeleži pri klicočem paketu v tem uporabniku. Zato aplikacija za vzpostavljanje, ki teče v osebnem profilu, ustvari osebni tunel, delovne aplikacije v delovnem profilu pa o njem ne vidijo ničesar. Velja tudi obratno, zato je tunel delovnega profila neviden osebnim aplikacijam brez izrecne politike, ki pravi drugače.

Krmilnik pravilnika naprave lahko vzpostavlja v imenu upravljanega profila, in to pojasni vnos, za katerega se v pisarni nihče ne spomni, da bi ga ustvaril. Če pregledujete telefon, je to verjetni lastnik osivelega profila, in brisanje kot poskus ni vaša stvar.

Tri vrata, preden se paket premakne

Prva vrata so pooblastilo: upravljanje mora VPN sploh dovoliti, nekatere namestitve pa omejujejo tudi vrsto, ne le obstoja. Druga so identiteta: odjemalčevo potrdilo ali poverilnice morajo biti na voljo v uporabniku, ki ima profil, ker potrdilo, uvoženo v osebni keystore, ni vidno delovnemu profilu.

Tretja so soglasje in pravilnik. Uporabnik običajno povezavo odobri ob prvi uporabi, skrbnik pa jo lahko dodatno pripne kot vedno vključeno, po želji z zaklepom, da promet ne more izstopiti izven tunela. Te nastavitve odločajo, kaj se zgodi, ko tunel pade, in to je del, ki ga uporabniki opazijo.

Obseg je kraj, kjer se vsi trije srečajo. Profil določa prehod in identiteto, medtem ko plast pravilnika odloča, katere aplikacije smejo uporabljati tunel in ali je promet prisilno speljan skozi. Dva telefona z enakimi naslovi prehoda se zato lahko obnašata zelo različno.

Zakaj osebna povezava ne pokrije delovnih aplikacij

Promet iz delovne aplikacije nastane v delovnem uporabniku, veljavni omrežni pravilnik pa je tisti v tem uporabniku. Tunel, vzpostavljen v osebnem profilu, ga ne prenaša, ne glede na to, kako zdravo je videti indikator. To eno dejstvo pojasni večino poročil, kjer uporabnik prisega, da je VPN povezan, ena določena aplikacija pa vseeno ne doseže notranje storitve.

Razreševanje imen sledi isti meji. Zasebne pripone DNS in sidra zaupanja so na uporabnika, zato notranje ime gostitelja, ki se razreši v osebnem profilu, v delovnem lahko spodleti tudi z navidezno enakovrednim tunelom, ker sta pravilnik razreševalnika in shramba CA različna objekta.

Preverjajte na resnični včlanitvi, ne na laboratorijskem telefonu

Na napravi najprej ugotovite lastnika vnosa: kateri uporabnik, kateri paket in ali je profil prišel od ponudnika platforme ali od aplikacije, ki izvaja lastno storitev VPN. Nato potrdite, da je identiteta, ki jo profil pričakuje, res prisotna v keystoreu tega uporabnika.

Preizkusite življenjski cikel, ne le povezave. Prijavite se, odklenite shrambo poverilnic, pustite delovni profil, da za večer miruje, nato ga vrnite in preverite, ali se tunel vrne brez ročnega dotika. Delovni profil, ki se po delovnem času izklopi, odnese tunel s seboj, in to je pričakovano vedenje, ne napaka, če je pričakovano nedosegljivo stanje zapisano.

Nazadnje preizkusite še delovno aplikacijo proti znani notranji končni točki in primerjajte z izidom osebnega profila. Ta dva se smeta razlikovati; razlikovati se ne sme model lastništva. Če tunel pripada napačnemu uporabniku, ponovno izdajanje potrdil tega ne popravi.

Ne silite rešitve z zaganjanjem skritih dejavnosti nastavitev, da bi razkrili meni, in ne kopirajte zasebnih ključev med profili, da bi povezava izgledala. Referenca VpnManager opisuje, kaj sme klicoči vzpostaviti; če odobrena pot ne vključuje vašega primera, je to odločitev skrbnika in ne težava z nastavitvami.