IKEv2 VPN-profiler på Android gäller per användare, inte per enhet

Uttrycket inbyggd VPN täcker två orelaterade saker på Android: en protokollimplementering som plattformen kör å dina vägnar, och den inställningsform tillverkaren valde att exponera. Det är inte samma objekt, och ingen av dem garanterar att tunneln tillhör användaren vars appar behöver den. Etableringen sker i en viss användare med ett visst anropande paket, och allt som följer ärver den kontexten. Läs ägarkedjan innan du läser inställningsskärmen.

Vad plattformen bygger åt dig

Sedan Android 11 exponerar plattformen VPN-etablering genom VpnManager. En godkänd app beskriver en IKEv2-profil, och plattformen kör IPsec- och IKE-utbytet själv, så appen rör aldrig paketen. Det är den väsentliga skillnaden mot en egen VPN-app, som implementerar VpnService och bygger tunneln i sin egen process.

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

Anropet ovan är en skiss av formen och inte ett block att kopiera: byggaren har flera varianter av autentisering, de skiljer sig åt beroende på API-nivå, och profilen bär också servercertifikatets förtroendematerial. Det som spelar roll för ägarskapsfrågan är snävare än syntaxen.

Två egenskaper följer av den här konstruktionen. Profilen är data, så den kan etableras av en administratör i stället för att skrivas för hand. Och tunneln är ett plattformsnätverk, så den framstår för program som ett nätverk med VPN-transport och inte som en annan apps socket.

Ägarskapet är användaren, sedan paketet

Androids fleranvändarläge är verklig åtskillnad, inte en etikett. En arbetsprofil är en separat användare med egna installerade paket, egna appdata, eget keystore och egna förtroendeankare. Samma produkt installerad på båda ställena är två instanser med olika användar-id, även när launcherikonerna och produktnamnen är identiska.

Etableringen registreras mot det anropande paketet i den användaren. En etableringsapp som körs i den personliga profilen skapar alltså en personlig tunnel, och arbetsapparna i arbetsprofilen ser ingenting av den. Det omvända är också sant, och därför är en tunnel i arbetsprofilen osynlig för personliga appar utan en uttrycklig policy som säger annat.

En kontrollant för enhetspolicy kan etablera åt en hanterad profil, och det förklarar posten som ingen på kontoret minns att de skapade. Om du granskar en telefon är det den sannolika ägaren till en gråad profil, och den är inte din att radera som experiment.

Tre portar innan ett paket rör sig

Den första porten är behörighet: hanteringen måste tillåta VPN över huvud taget, och vissa utrullningar begränsar både typen och förekomsten. Den andra är identitet: klientcertifikatet eller inloggningsuppgifterna måste finnas i den användare som äger profilen, eftersom ett certifikat som importerats i det personliga keystore inte är synligt för arbetsprofilen.

Den tredje är samtycke och policy. Användaren godkänner vanligtvis anslutningen första gången den används, och en administratör kan dessutom fästa den som alltid på, eventuellt med låsning så att trafiken inte kan gå utanför tunneln. De inställningarna avgör vad som händer när tunneln ligger nere, och det är den delen användarna märker.

Omfattning är där de tre möts. Profilen bestämmer gatewayen och identiteten, medan policylagret bestämmer vilka program som får använda tunneln och om trafiken tvingas genom den. Två telefoner med identiska gatewayadresser kan därför bete sig helt olika.

Varför en personlig anslutning inte täcker arbetsappar

Trafik från en arbetsapp skapas i arbetsanvändaren, och den nätverkspolicy som gäller är den i den användaren. En tunnel som etablerats i den personliga profilen bär den inte, hur frisk indikatorn än ser ut. Det enda faktumet förklarar de flesta rapporter där en användare svär att VPN:en är ansluten och en viss app ändå inte når en intern tjänst.

Namnuppslagning följer samma gräns. Privata DNS-suffix och förtroendeankare är per användare, så ett internt värdnamn som löses i den personliga profilen kan misslyckas i arbetsprofilen även med en till synes likvärdig tunnel, eftersom resolverpolicyn och CA-lagret är olika objekt.

Verifiera på en verklig registrering, inte på en labbtelefon

På enheten: identifiera först postens ägare: vilken användare, vilket paket, och om profilen kom från plattformens etablerare eller från en app som implementerar sin egen VPN-tjänst. Bekräfta sedan att den identitet profilen förväntar sig faktiskt finns i den användarens keystore.

Testa livscykeln, inte bara anslutningen. Logga in, lås upp uppgiftslagret, låt arbetsprofilen vila en kväll, hämta sedan tillbaka den och kontrollera att tunneln kommer tillbaka utan ett manuellt tryck. En arbetsprofil som stängs av efter arbetstid tar sin tunnel med sig, och det är förväntat beteende och inte ett fel, förutsatt att det förväntade otillgängliga tillståndet är nedskrivet.

Till sist: testa själva arbetsappen mot en känd intern ändpunkt och jämför med resultatet för den personliga profilen. De två får skilja sig; det som inte får skilja sig är ägarskapsmodellen. Om tunneln tillhör fel användare hjälper det inte att utfärda certifikatet igen.

Tvinga inte fram saken genom att starta dolda inställningsaktiviteter för att avslöja en meny, och kopiera inte privata nycklar mellan profiler för att få en anslutning att synas. VpnManager-referensen dokumenterar vad en anropare får etablera; om den godkända vägen inte omfattar ditt fall är det ett beslut för administratören och inte ett inställningsproblem.