IKEv2 VPN-profiler på Android hører til brukeren, ikke til enheten

Begrepet innebygd VPN rommer to ting på Android som ikke har med hverandre å gjøre: en protokollimplementasjon som plattformen kjører på dine vegne, og den innstillingsformen produsenten bestemte seg for å vise fram. Det er ikke samme objekt, og ingen av dem garanterer at tunnelen tilhører brukeren som trenger den for appene sine. Oppsettet skjer i en bestemt bruker med en bestemt kallende pakke, og alt som kommer etter, arver den sammenhengen. Les eierskapskjeden før du leser innstillingsskjermen.

Dette bygger plattformen for deg

Fra og med Android 11 tilbyr plattformen VPN-oppsett gjennom VpnManager. En godkjent app beskriver en IKEv2-profil, og plattformen kjører IPsec- og IKE-utvekslingen selv, slik at appen aldri tar i pakkene. Det er den viktige 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 over er en skisse av formen, ikke en ferdig kodeblokk: byggeren har flere varianter for autentisering, de avhenger av API-nivået, og profilen bærer også tillitsmaterialet for server sertifikatet. Det som betyr noe for eierskapsspørsmålet, er snevrere enn syntaksen.

To egenskaper følger av denne konstruksjonen. Profilen er data, og kan derfor settes opp av en administrator i stedet for å skrives for hånd. Og tunnelen er et plattformnettverk, så den framstår for applikasjoner som et nettverk med VPN-transport og ikke som socketen til en annen app.

Eierskap er brukeren først, deretter pakken

Flerbruk i Android er ekte atskillelse, ikke en merkelapp. En arbeidsprofil er en egen bruker med egne installerte pakker, egne appdata, eget keystore og egne tillitsankre. Samme produkt installert begge steder er to forekomster med forskjellige bruker-id-er, selv når launcher-ikonene og produktnavnene er like.

Oppsettet registreres mot den kallende pakken i den brukeren. En oppsettsapp som kjører i den personlige profilen, lager dermed en personlig tunnel, og arbeidsappene i arbeidsprofilen ser ingenting av den. Det omvendte gjelder også, og derfor er en tunnel i arbeidsprofilen usynlig for personlige apper uten en uttrykkelig policy som sier noe annet.

En kontrollør for enhetspolicy kan sette opp på vegne av en administrert profil, og det forklarer oppføringen som ingen på kontoret husker at de laget. Hvis du går gjennom en telefon, er det den sannsynlige eieren av en nedtonet profil, og den er ikke din å slette som et forsøk.

Tre porter før en pakke beveger seg

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

Den tredje er samtykke og policy. Brukeren godkjenner vanligvis forbindelsen 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 den delen brukerne merker.

Omfanget er der de tre møtes. Profilen bestemmer gatewayen og identiteten, mens policy laget bestemmer hvilke applikasjoner som får bruke tunnelen og om trafikken tvinges gjennom den. To telefoner med samme gatewayadresse kan derfor oppføre seg svært ulikt.

Hvorfor en personlig forbindelse ikke dekker arbeidsapper

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

Navneoppslag følger samme grense. Private DNS-suffikser og tillitsankre er per bruker, så et internt vertsnavn som løses i den personlige profilen, kan svikte i arbeidsprofilen selv med en tunnel som ser likverdig ut, fordi resolver-policyen og CA-lageret er forskjellige objekter.

Verifiser på en virkelig registrering, ikke på en labtelefon

På enheten: finn først ut hvem som eier oppføringen: hvilken bruker, hvilken pakke, og om profilen kom fra plattformens oppsett eller fra en app som implementerer sin egen VPN-tjeneste. Bekreft deretter at identiteten profilen forventer, faktisk ligger i keystore for den brukeren.

Test livsløpet, ikke bare tilkoblingen. Logg inn, lås opp lageret for påloggingsinformasjon, la arbeidsprofilen hvile en kveld, hent den så tilbake og kontroller 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 for 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 hvor mange ganger sertifikatet utstedes på nytt.

Ikke tving gjennom saken ved å starte skjulte innstilling aktiviteter for å avdekke en meny, og ikke kopier private nøkler mellom profiler for å få en forbindelse til å se ut som noe. VpnManager-referansen dokumenterer hva en som kaller, har lov til å sette opp; hvis den godkjente veien ikke dekker tilfellet ditt, er det en avgjørelse for administratoren og ikke et innstillingsproblem.