Profilet VPN IKEv2 në Android janë për përdorues, jo për pajisje

Shprehja VPN e integruar mbulon në Android dy gjëra pa lidhje: një zbatim protokolli që platforma e ekzekuton në emrin tuaj, dhe atë formë cilësimesh që prodhuesi vendosi të ekspozojë. Këto nuk janë i njëjti objekt, dhe asnjëra nuk garanton se tuneli i takon përdoruesit, aplikacionet e të cilit kanë nevojë për të. Përgatitja ndodh në një përdorues të caktuar me një paketë të caktuar thirrëse, dhe gjithçka që vjen më pas trashëgon atë kontekst. Lexoni zinxhirin e pronësisë përpara se të lexoni ekranin e cilësimeve.

Çfarë ndërton platforma për ju

Që nga Android 11 platforma ekspozon përgatitjen e VPN përmes VpnManager. Një aplikacion i miratuar përshkruan një profil IKEv2, dhe platforma e ekzekuton vetë shkëmbimin IPsec dhe IKE, kështu që aplikacioni nuk i prek kurrë paketat. Ky është dallimi thelbësor nga një aplikacion VPN i vetëndërtuar, i cili zbaton VpnService dhe e ndërton tunelin në procesin e vet.

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

Thirrja më sipër është një skicë e formës dhe jo një bllok për kopjim: ndërtuesi ka disa variante vërtetimi, ato ndryshojnë sipas nivelit të API, dhe profili mban edhe materialin e besimit të certifikatës së serverit. Ajo që ka rëndësi për pyetjen e pronësisë është më e ngushtë se sintaksa.

Nga ky dizajn rrjedhin dy veti. Profili është të dhëna, prandaj mund të përgatitet nga një administrator në vend që të shkruhet me dorë. Dhe tuneli është rrjet i platformës, prandaj u shfaqet aplikacioneve si rrjet me transport VPN dhe jo si socket i një aplikacioni tjetër.

Pronësia është përdoruesi, pastaj paketa

Shumë-përdoruesi i Android është ndarje e vërtetë, jo etiketë. Profili i punës është përdorues i veçantë me paketat e tij të instaluara, të dhënat e veta të aplikacioneve, keystore-in e vet dhe ankorat e veta të besimit. I njëjti produkt i instaluar në të dyja vendet janë dy instanca me identifikues të ndryshëm përdoruesi, edhe kur ikonat e lëshuesit dhe emrat e produktit janë identikë.

Përgatitja regjistrohet kundrejt paketës thirrëse në atë përdorues. Prandaj një aplikacion përgatitjeje që punon në profilin personal krijon një tunel personal, dhe aplikacionet e punës në profilin e punës nuk shohin asgjë prej tij. E kundërta është gjithashtu e vërtetë, dhe për këtë arsye një tunel i profilit të punës është i padukshëm për aplikacionet personale pa një politikë të shprehur që thotë ndryshe.

Një kontrollues i politikës së pajisjes mund të përgatisë në emër të një profili të administruar, dhe kjo shpjegon zërin që askush në zyrë nuk mbahet mend ta ketë krijuar. Nëse po auditoni një telefon, ai është pronari i mundshëm i një profili të hirtë, dhe nuk është puna juaj ta fshini si eksperiment.

Tre porta përpara se të lëvizë një paketë

Porta e parë është autoriteti: administrimi duhet të lejojë fare VPN, dhe disa vendosje kufizojnë edhe llojin, jo vetëm ekzistencën. E dyta është identiteti: certifikata e klientit ose kredencialet duhet të jenë të disponueshme në përdoruesin që zotëron profilin, sepse një certifikatë e importuar në keystore-in personal nuk është e dukshme për profilin e punës.

E treta është pëlqimi dhe politika. Përdoruesi zakonisht e miraton lidhjen herën e parë që përdoret, dhe administratori mund ta fiksojë përveç kësaj si gjithmonë aktive, sipas dëshirës me bllokim, që trafiku të mos mund të dalë jashtë tunelit. Ato cilësime vendosin çfarë ndodh kur tuneli bie, dhe kjo është pjesa që përdoruesit e vënë re.

Fusha është vendi ku takohen të tre. Profili përcakton portën dhe identitetin, ndërsa shtresa e politikës vendos cilat aplikacione mund ta përdorin tunelin dhe nëse trafiku detyrohet përmes tij. Dy telefona me adresa portë identike mund të sillen pra shumë ndryshe.

Pse një lidhje personale nuk i mbulon aplikacionet e punës

Trafiku nga një aplikacion pune krijohet në përdoruesin e punës, dhe politika e rrjetit që zbatohet është ajo e atij përdoruesi. Një tunel i vendosur në profilin personal nuk e mbart atë, sado i shëndetshëm të duket treguesi. Ky fakt i vetëm shpjegon shumicën e raportimeve ku përdoruesi betohet se VPN-i është i lidhur dhe një aplikacion i caktuar prapë nuk arrin një shërbim të brendshëm.

Zgjidhja e emrave ndjek të njëjtin kufi. Prapashtesat private të DNS dhe ankorat e besimit janë për përdorues, prandaj një emër hosti i brendshëm që zgjidhet në profilin personal mund të dështojë në profilin e punës edhe me një tunel që duket ekuivalent, sepse politika e zgjidhësit dhe depoja e CA-ve janë objekte të ndryshme.

Verifikoni në një regjistrim real, jo në një telefon laboratori

Në pajisje, identifikoni së pari pronarin e zërit: cili përdorues, cila paketë, dhe nëse profili erdhi nga përgatitësi i platformës apo nga një aplikacion që zbaton shërbimin e vet VPN. Më pas konfirmoni që identiteti që pret profili është në të vërtetë i pranishëm në keystore-in e atij përdoruesi.

Provoni ciklin e jetës, jo vetëm lidhjen. Hyni, shkyçni depon e kredencialeve, lërini profilin e punës të pushojë për një mbrëmje, pastaj rikthejeni dhe kontrolloni nëse tuneli kthehet pa një prekje manuale. Një profil pune që fiket pas orarit e merr tunelin me vete, dhe kjo është sjellje e pritur dhe jo defekt, me kusht që gjendja e pritur e padisponueshme të jetë shkruar.

Së fundmi, provoni vetë aplikacionin e punës kundrejt një pike fundore të brendshme të njohur dhe krahasoni me rezultatin e profilit personal. Të dyja lejohet të ndryshojnë; ajo që nuk duhet të ndryshojë është modeli i pronësisë. Nëse tuneli i takon përdoruesit të gabuar, rikthimi i certifikatave nuk rregullon asgjë.

Mos e forcioni çështjen duke nisur aktivitete të fshehura të cilësimeve për të zbuluar një menu, dhe mos kopjoni çelësa privatë midis profileve që një lidhje të duket. Referenca e VpnManager dokumenton çfarë lejohet të përgatisë një thirrës; nëse rruga e miratuar nuk e përfshin rastin tuaj, ai është vendim i administratorit dhe jo problem cilësimesh.