IKEv2-VPN-profilar på Android gjeld per brukar, ikkje per eining

Omgrepet innebygd VPN dekkjer to uskylde ting på Android: ei protokollimplementering som plattforma køyrer på dine vegne, og kva form for innstillingar produsenten valde å visa. Dette er ikkje same objektet, og ingen av dei garanterer at tunnelen høyrer til brukaren som appane hans treng han for. Oppsettet skjer i ein bestemd brukar med ein bestemd kallande pakke, og alt som følgjer arvar den samanhengen. Les eigarskapskjeda før du les innstillingsskjermen.

Kva plattforma byggjer for deg

Sidan Android 11 legg plattforma til rette for VPN-oppsett gjennom VpnManager. Ein godkjend app skildrar ein IKEv2-profil, og plattforma køyrer sjølv IPsec- og IKE-utvekslinga, så appen rører aldri pakkane. Det er den vesentlege skilnaden frå ein eigen VPN-app, som implementerer VpnService og byggjer tunnelen i sin eigen prosess.

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

Kallet ovanfor er ei skisse av forma og ikkje eit blokk du kan kopiere: byggjaren har fleire autentiseringsvariantar, dei varierer med API-nivå, og profilen ber òg tillitsmaterialet til servercertifikatet. Det som tel for eigarskapsspørsmålet, er trongare enn syntaksen.

To eigenskapar følgjer av denne utforminga. Profilen er data, så han kan setjast opp av ein administrator i staden for å skrivast for hand. Og tunnelen er eit plattformnettverk, så han syner seg for applikasjonar som eit nettverk med VPN-transport og ikkje som sokkelen til ein annan app.

Eigarskap er brukaren, så pakken

Fleirbruk på Android er reell skilnad, ikkje ei merkelapp. Ein arbeidsprofil er ein eigen brukar med eigne installerte pakkar, eigne appdata, eigen keystore og eigne tillitsanker. Same produktet installert båe stader er to instansar med ulike brukar-id-ar, jamvel når launcher-ikona og produktnamna er identiske.

Oppsettet vert registrert mot den kallande pakka i den brukaren. Ein oppsettsapp som køyrer i den personlege profilen, lagar altså ein personleg tunnel, og arbeidsappane i arbeidsprofilen ser ingenting av han. Det motsette er òg sant, og difor er ein arbeidsprofil-tunnel usynleg for personlege appar utan ei uttrykkeleg retningslinje som seier noko anna.

Ein eining politikkstyring kan setje opp på vegner av ein styrt profil, og det forklarer oppføringa som ingen på kontoret hugsar å ha laga. Viss du granskar ein telefon, er det den trulege eigaren av ein gråa profil, og han er ikkje din å sletta som eit eksperiment.

Tre portar før ein pakke flyttar seg

Den fyrste porten er myndigheit: styringa må tillate VPN i det heile, og nokre utrullingar avgrensar både typen og førekomsten. Den andre er identitet: klientcertifikatet eller innloggingsdetaljane må vere tilgjengelege i brukaren som eig profilen, fordi eit sertifikat importert i den personlege keystoren ikkje er synleg for arbeidsprofilen.

Den tredje er samtykke og retningslinje. Brukaren godkjenner vanlegvis sambandet fyrste gong det vert brukt, og ein administrator kan i tillegg feste det som alltid på, om ynskjeleg med lockdown slik at trafikken ikkje kan gå utanfor tunnelen. Dei innstillingane avgjer kva som skjer når tunnelen er nede, og det er den delen brukarane legg merke til.

Omfang er der dei tre møtest. Profilen avgjer gatewayen og identiteten, medan retningslinjelaget avgjer kva applikasjonar som kan bruke tunnelen og om trafikken vert tvinga gjennom han. To telefonar med same gatewayadresse kan difor oppføre seg heilt ulikt.

Kvifor eit personleg samband ikkje dekkjer arbeidsappar

Trafikk frå ein arbeidsapp vert laga i arbeidsbrukaren, og nettverksretningslinja som gjeld, er den i den brukaren. Ein tunnel etablert i den personlege profilen ber han ikkje, same kor frisk indikatoren ser ut. Den eine opplysninga forklarer dei fleste meldingane der ein brukar sver at VPN-en er kopla til og ein bestemd app framleis ikkje når ei intern teneste.

Namneoppslag følgjer same grensa. Private DNS-suffiks og tillitsanker er per brukar, så eit internt vertsnamn som vert løyst i den personlege profilen, kan feile i arbeidsprofilen jamvel med ein tilsynelatande likeverdig tunnel, fordi resolver-retningslinja og CA-lageret er ulike objekt.

Stadfest på ei reell innmelding, ikkje ein labtelefon

På eininga: finn fyrst eigaren av oppføringa: kva brukar, kva pakke, og om profilen kom frå plattformleverandøren eller frå ein app som implementerer si eiga VPN-teneste. Stadfest så at identiteten profilen ventar, faktisk finst i keystoren til den brukaren.

Test livssyklusen, ikkje berre sambandet. Logg inn, lås opp vitnemålsarmbåndet, lat arbeidsprofilen pause for kvelden, hent han så attende og sjekk at tunnelen kjem tilbake utan eit manuelt trykk. Ein arbeidsprofil som slår seg av etter arbeidstid, tek tunnelen med seg, og det er venta åtferd og ikkje ein feil, så framt den venta utilgjengelege tilstanden er skriven ned.

Til slutt: test sjølve arbeidsappen mot eit kjend internt endepunkt og samanlikn med resultatet frå den personlege profilen. Dei to kan godt vere ulike; det som ikkje kan vere ulikt, er eigarskapsmodellen. Viss tunnelen høyrer til feil brukar, hjelper det ikkje å gje ut sertifikatet på nytt.

Ikkje tving saka ved å starte skjulte innstillingaktivitetar for å avdekkje ei meny, og ikkje kopier private nyklar mellom profilar for å få eit samband til å sjå ut. VpnManager-referansen syner kva ein kallar har lov til å setje opp; viss den godkjende vegen ikkje femner tilfellet ditt, er det ei avgjerd for administratoren og ikkje eit innstillingsproblem.