„Android“ IKEv2 VPN profiliai priskiriami naudotojui, o ne įrenginiui

Terminas įtaisytasis VPN „Android“ apima du nesusijusius dalykus: protokolo įgyvendinimą, kurį platforma vykdo jūsų vardu, ir tą nustatymų formą, kurią gamintojas nusprendė rodyti. Tai ne tas pats objektas, ir nė vienas iš jų negarantuoja, kad tunelis priklauso naudotojui, kurio programoms jo reikia. Sukūrimas vyksta konkrečiame naudotojuje su konkrečiu kviečiančiu paketu, ir visa, kas toliau, paveldi tą kontekstą. Perskaitykite nuosavybės grandinę prieš nustatymų ekraną.

Ką platforma pastato už jus

Nuo „Android“ 11 platforma teikia VPN kūrimą per VpnManager. Patvirtinta programa aprašo IKEv2 profilį, o platforma pati atlieka IPsec ir IKE mainus, todėl programa niekada neliečia paketų. Tai esminis skirtumas nuo savos VPN programos, kuri įgyvendina VpnService ir stato tunelį savo procese.

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

Aukščiau pateiktas kvietimas yra formos eskizas, o ne kopijuojamas blokas: kūrėjas turi kelis autentifikavimo variantus, jie skiriasi pagal API lygį, o profilis taip pat neša serverio sertifikato pasitikėjimo medžiagą. Nuosavybės klausimui svarbu siauriau nei sintaksė.

Iš šios konstrukcijos kyla dvi savybės. Profilis yra duomenys, todėl administratorius gali jį sukurti, o ne įvesti ranka. O tunelis yra platformos tinklas, todėl programos mato jį kaip tinklą su VPN transportu, o ne kaip kitos programos lizdą.

Savininkas yra naudotojas, paskui paketas

Daugianaudotoji „Android“ sistema yra tikras atskyrimas, o ne etiketė. Darbo profilis yra atskiras naudotojas su savo įdiegtais paketais, programų duomenimis, raktų saugykla ir pasitikėjimo inkarais. Ta pati produkto versija abiejose vietose yra du egzemplioriai su skirtingais naudotojo identifikatoriais, net kai piktogramos ir pavadinimai vienodi.

Sukūrimas registruojamas tam naudotojui priklausančiam kviečiančiam paketui. Todėl asmeniniame profilyje veikianti kūrimo programa sukuria asmeninį tunelį, o darbo profilio darbo programos jo visai nemato. Ir atvirkščiai, todėl darbo profilio tunelis nematomas asmeninėms programoms be aiškios politikos, nurodančios kitaip.

Įrenginio politikos valdiklis gali kurti valdomo profilio vardu, o tai paaiškina įrašą, kurio niekas biure neprisimena kūręs. Jei atliekate telefono auditą, tai greičiausiai pilko profilio savininkas, ir jo ištrinti eksperimentui ne jūsų reikalas.

Trys vartai, kol paketas pajuda

Pirmieji vartai yra įgaliojimas: valdymas turi apskritai leisti VPN, o kai kurie diegimai riboja ir tipą, ir patį egzistavimą. Antrieji yra tapatybė: kliento sertifikatas arba kredencialai turi būti prieinami naudotojui, kuriam priklauso profilis, nes sertifikatas, importuotas į asmeninę saugyklą, nėra matomas darbo profiliui.

Tretieji yra sutikimas ir politika. Naudotojas paprastai patvirtina ryšį pirmą kartą jį naudodamas, o administratorius gali papildomai prisegti jį kaip visada įjungtą, pasirinktinai su užraktu, kad srautas negalėtų išeiti už tunelio. Šie nustatymai sprendžia, kas nutinka tuneliui nutrūkus, ir būtent tai naudotojai pastebi.

Aprėptis yra vieta, kur susitinka visi trys. Profilis nustato šliuzą ir tapatybę, o politikos sluoksnis sprendžia, kurios programos gali naudoti tunelį ir ar srautas per jį varomas. Todėl du telefonai su vienodais šliuzo adresais gali elgtis labai skirtingai.

Kodėl asmeninis ryšys neapima darbo programų

Srautas iš darbo programos sukuriamas darbo naudotojuje, o taikoma tinklo politika yra to naudotojo. Asmeniniame profilyje sukurtas tunelis jo neneša, kad ir kaip sveikai atrodytų indikatorius. Šis vienas faktas paaiškina daugumą pranešimų, kai naudotojas prisiekia, kad VPN prisijungtas, o konkreti programa vis tiek nepasiekia vidinės paslaugos.

Vardų skyrimas laikosi tos pačios ribos. Privatūs DNS priesagos ir pasitikėjimo inkarai yra kiekvienam naudotojui, todėl vidinis kompiuterio vardas, kuris išsprendžiamas asmeniniame profilyje, gali nepavykti darbo profilyje net su iš pažiūros lygiaverčiu tuneliu, nes sprendėjo politika ir CA saugykla yra skirtingi objektai.

Tikrinkite realioje registracijoje, o ne laboratoriniame telefone

Įrenginyje pirmiausia nustatykite įrašo savininką: kuris naudotojas, kuris paketas ir ar profilis atėjo iš platformos kūrėjo, ar iš programos su savo VPN paslauga. Tada patvirtinkite, kad tapatybė, kurios tikisi profilis, tikrai yra to naudotojo raktų saugykloje.

Tikrinkite gyvavimo ciklą, o ne tik prisijungimą. Prisijunkite, atrakinkite kredencialų saugyklą, leiskite darbo profiliui vakare pristabdyti, tada grąžinkite jį ir patikrinkite, ar tunelis grįžta be rankinio prisilietimo. Darbo profilis, kuris išsijungia po darbo valandų, nusineša ir tunelį, ir tai yra laukiamas elgesys, o ne gedimas, jei laukiama nepasiekiamumo būsena yra užrašyta.

Galiausiai išbandykite pačią darbo programą prieš žinomą vidinį galinį tašką ir palyginkite su asmeninio profilio rezultatu. Jie gali skirtis; skirtis neturi nuosavybės modelis. Jei tunelis priklauso netinkamam naudotojui, joks sertifikatų perleidimas to nepataisys.

Nespręskite klausimo prievarta paleisdami paslėptas nustatymų veiklas meniu atskleisti, ir nekopijuokite privačių raktų tarp profilių, kad ryšys atsirastų. VpnManager nuoroda aprašo, ką kviečiantysis gali sukurti; jei patvirtintas kelias neapima jūsų atvejo, tai administratoriaus sprendimas, o ne nustatymų problema.