IKEv2 VPN-profiler på Android hører til brugeren, ikke enheden

Udtrykket indbygget VPN dækker to ubeslægtede ting på Android: en protokolimplementering, som platformen kører på dine vegne, og den form for indstillinger, som producenten valgte at vise. Det er ikke samme objekt, og ingen af dem garanterer, at tunnelen tilhører den bruger, hvis apps har brug for den. Oprettelsen sker i en bestemt bruger med en bestemt kaldende pakke, og alt derefter arver den kontekst. Læs ejerskabskæden, før du læser indstillingsskærmen.

Hvad platformen bygger for dig

Siden Android 11 eksponerer platformen VPN-oprettelse gennem VpnManager. En godkendt app beskriver en IKEv2-profil, og platformen kører selv IPsec- og IKE-udvekslingen, så appen rører aldrig ved pakker. Det er den væsentlige forskel fra en egen VPN-app, som implementerer VpnService og bygger tunnelen i sin egen proces.

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

Kaldet ovenfor er en skitse af formen, ikke en blok til kopiering: builderen har flere godkendelsesvarianter, de afhænger af API-niveau, og profilen bærer også tillidsmaterialet for servercertifikatet. For ejerskabsspørgsmålet er det afgørende snævrere end syntaksen.

To egenskaber følger af designet. Profilen er data, så en administrator kan oprette den i stedet for at taste den ind. Og tunnelen er et platformnetværk, så apps ser den som et netværk med VPN-transport og ikke som en anden apps socket.

Ejerskabet er brugeren, derefter pakken

Androids flerbrugerfunktion er egentlig adskillelse, ikke en etiket. En arbejdsprofil er en separat bruger med sine egne installerede pakker, egne appdata, eget nøglelager og egne tillidsankre. Det samme produkt installeret begge steder er to forekomster med forskellige bruger-id’er, selv når launcherikoner og produktnavne er identiske.

Oprettelsen registreres mod den kaldende pakke i den bruger. En app til oprettelse, der kører i den personlige profil, skaber derfor en personlig tunnel, og arbejdsappene i arbejdsprofilen ser intet af den. Det omvendte gælder også, og derfor er en arbejdsprofiltunnel usynlig for personlige apps uden en udtrykkelig politik, der siger andet.

En enhedspolitikcontroller kan oprette på vegne af en administreret profil, hvilket forklarer posten, som ingen på kontoret husker at have oprettet. Hvis du reviderer en telefon, er det den sandsynlige ejer af en grånet profil, og det er ikke din opgave at slette den som et eksperiment.

Tre porte, før en pakke flytter sig

Den første port er beføjelse: ledelsen skal tillade VPN overhovedet, og nogle udrulninger begrænser både typen og selve eksistensen. Den anden er identitet: klientcertifikatet eller legitimationsoplysningerne skal være tilgængelige i den bruger, der ejer profilen, for et certifikat importeret i det personlige nøglelager er ikke synligt for arbejdsprofilen.

Den tredje er samtykke og politik. En bruger godkender typisk forbindelsen første gang, den bruges, og en administrator kan desuden fastgøre den som altid-til, eventuelt med lås, så trafik ikke kan gå uden for tunnelen. De indstillinger afgør, hvad der sker, når tunnelen er nede, og det er den del, brugerne lægger mærke til.

Omfanget er der, hvor de tre mødes. Profilen bestemmer gateway og identitet, mens politiklaget bestemmer, hvilke apps der må bruge tunnelen og om trafikken tvinges igennem den. Derfor kan to telefoner med identiske gatewayadresser opføre sig meget forskelligt.

Hvorfor en personlig forbindelse ikke dækker arbejdsapps

Trafik fra en arbejdsapp opstår i arbejdsbrugeren, og den netværkspolitik, der gælder, er den i den bruger. En tunnel oprettet i den personlige profil bærer den ikke, uanset hvor sund indikatoren ser ud. Den ene kendsgerning forklarer de fleste rapporter, hvor en bruger sværger, at VPN er forbundet, mens en bestemt app stadig ikke kan nå en intern tjeneste.

Navneopløsning følger samme grænse. Private DNS-suffikser og tillidsankre er pr. bruger, så et internt værtsnavn, der opløses i den personlige profil, kan fejle i arbejdsprofilen selv med en tilsyneladende tilsvarende tunnel, fordi resolverpolitikken og CA-lageret er forskellige objekter.

Verificer på en rigtig tilmelding, ikke på en laboratorietelefon

På enheden skal du først identificere postens ejer: hvilken bruger, hvilken pakke, og om profilen kom fra platformens opretter eller fra en app med sin egen VPN-tjeneste. Bekræft derefter, at den identitet, profilen forventer, faktisk findes i den brugers nøglelager.

Test livscyklussen, ikke kun forbindelsen. Log ind, lås legitimationslageret op, lad arbejdsprofilen holde pause om aftenen, bring den tilbage og kontroller, at tunnelen vender tilbage uden et manuelt tryk. En arbejdsprofil, der slukker efter arbejdstid, tager sin tunnel med, og det er forventet adfærd og ikke en fejl, forudsat at den forventede utilgængelige tilstand er skrevet ned.

Test til sidst selve arbejdsappen mod et kendt internt endepunkt og sammenlign med den personlige profiles resultat. De to må gerne være forskellige; det, der ikke må være forskelligt, er ejerskabsmodellen. Hvis tunnelen tilhører den forkerte bruger, retter nogen genudstedelse af certifikater det ikke.

Tving ikke sagen ved at starte skjulte indstillingsaktiviteter for at afsløre en menu, og kopiér ikke private nøgler mellem profiler for at få en forbindelse til at se ud. VpnManager-referencen dokumenterer, hvad en kalder må oprette; hvis den godkendte vej ikke omfatter dit tilfælde, er det en beslutning for administratoren og ikke et indstillingsproblem.