IKEv2-VPN-profiler på Android gjelder per bruker, ikke per enhet

Uttrykket innebygd VPN dekker to urelaterte ting på Android: en protokollimplementering plattformen kjører på dine vegne, og hvilken innstillingsform produsenten valgte å eksponere. Dette er ikke samme objekt, og ingen av dem garanterer at tunnelen tilhører brukeren hvis apper trenger den. Provisjoneringen skjer i en bestemt bruker med en bestemt kallende pakke, og alt som følger arver den konteksten. Les eierskapskjeden før du leser innstillingene.

Hva plattformen bygger for deg

Siden Android 11 eksponerer plattformen VPN-provisjonering gjennom VpnManager. En godkjent app beskriver en IKEv2-profil, og plattformen kjører IPsec- og IKE-utvekslingen selv, så appen berører aldri pakkene. Det er den vesentlige forskjellen fra en egen VPN-app, som implementerer VpnService og bygger tunnelen i sin egen prosess.

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

Kallet ovenfor er en skisse av formen og ikke en blokk du kan kopiere: byggeren har flere autentiseringsvarianter, de varierer med API-nivå, og profilen bærer også serverens sertifikattillit. Det som betyr noe for eierskapsspørsmålet, er smalere enn syntaksen.

To egenskaper følger av dette designet. Profilen er data, så den kan provisjoneres av en administrator i stedet for å skrives for hånd. Og tunnelen er et plattformnettverk, så den vises for applikasjoner som et nettverk med VPN-transport og ikke som en annen apps socket.

Eierskap er brukeren, så pakken

Androids flerbruk er reell separasjon, ikke en etikett. En arbeidsprofil er en egen bruker med egne installerte pakker, egne appdata, eget keystore og egne tillitsankere. Samme produkt installert begge steder er to forekomster med ulike bruker-id-er, selv når launcher-ikonene og produktnavnene er identiske.

Provisjoneringen registreres mot den kallende pakken i den brukeren. En provisjoneringsapp som kjører i den personlige profilen, lager altså en personlig tunnel, og arbeidsappene i arbeidsprofilen ser ingenting av den. Det motsatte er også sant, og derfor er en arbeidsprofil-tunnel usynlig for personlige apper uten en uttrykkelig policy som sier noe annet.

En enhets policy-kontroller kan provisjonere på vegne av en administrert profil, og det forklarer oppføringen som ingen på kontoret husker å ha laget. Hvis du reviderer en telefon, er det den sannsynlige eieren av en grået ut profil, og den er ikke din å slette som et eksperiment.

Tre porter før en pakke flyttes

Den første porten er myndighet: administrasjonen må tillate VPN i det hele tatt, og enkelte utrullinger begrenser både typen og forekomsten. Den andre er identitet: klient sertifikatet eller legitimasjonen må være tilgjengelig i brukeren som eier profilen, fordi et sertifikat importert i det personlige keystore ikke er synlig for arbeidsprofilen.

Den tredje er samtykke og policy. Brukeren godkjenner vanligvis tilkoblingen første gang den brukes, og en administrator kan i tillegg feste den som alltid på, eventuelt med lockdown slik at trafikken ikke kan gå utenfor tunnelen. De innstillingene avgjør hva som skjer når tunnelen er nede, og det er delen brukerne legger merke til.

Omfang er der de tre møtes. Profilen bestemmer gatewayen og identiteten, mens policylaget bestemmer hvilke applikasjoner som kan bruke tunnelen og om trafikken tvinges gjennom den. To telefoner med identiske gatewayadresser kan derfor oppføre seg svært forskjellig.

Hvorfor en personlig tilkobling ikke dekker arbeidsapper

Trafikk fra en arbeidsapp genereres i arbeidsbrukeren, og nettverkspolicyen som gjelder, er den i den brukeren. En tunnel etablert i den personlige profilen bærer den ikke, uansett hvor sunn indikatoren ser ut. Det ene faktum forklarer de fleste rapportene der en bruker sverger på at VPN-en er tilkoblet og én bestemt app fortsatt ikke når en intern tjeneste.

Navneoppslag følger samme grense. Private DNS-suffikser og tillitsankere er per bruker, så et internt vertsnavn som løses i den personlige profilen, kan feile i arbeidsprofilen selv med en tilsynelatende likeverdig tunnel, fordi resolverpolicyen og CA-lageret er forskjellige objekter.

Verifiser på en reell registrering, ikke en labtelefon

På enheten: identifiser oppføringens eier først: hvilken bruker, hvilken pakke, og om profilen kom fra plattformleverandøren eller fra en app som implementerer sin egen VPN-tjeneste. Bekreft deretter at identiteten profilen forventer, faktisk finnes i den brukerens keystore.

Test livssyklusen, ikke bare tilkoblingen. Logg inn, lås opp legitimasjonslageret, la arbeidsprofilen pause for kvelden, og hent den så tilbake og sjekk at tunnelen kommer tilbake uten et manuelt trykk. En arbeidsprofil som slås av etter arbeidstid, tar tunnelen med seg, og det er forventet atferd og ikke en feil, forutsatt at den forventede utilgjengelige tilstanden er skrevet ned.

Til slutt: test selve arbeidsappen mot et kjent internt endepunkt og sammenlign med resultatet fra den personlige profilen. De to kan godt være forskjellige; det som ikke kan være forskjellig, er eierskapsmodellen. Hvis tunnelen tilhører feil bruker, hjelper det ikke å utstede sertifikatet på nytt.

Ikke tving saken ved å starte skjulte innstillingsaktiviteter for å avdekke en meny, og ikke kopier private nøkler mellom profiler for å få en tilkobling til å se ut. VpnManager-referansen dokumenterer hva en kaller har lov til å provisjonere; hvis den godkjente veien ikke omfatter ditt tilfelle, er det en avgjørelse for administratoren og ikke et innstillingsproblem.