IKEv2-VPN-profielen op Android gelden per gebruiker, niet per apparaat

De uitdrukking ingebouwde VPN dekt op Android twee onverwante zaken: een protocolimplementatie die het platform namens jou draait, en de vorm van instellingen die de fabrikant besloot bloot te leggen. Dat zijn niet hetzelfde object, en geen van beide garandeert dat de tunnel toebehoort aan de gebruiker wiens apps hem nodig hebben. De inrichting gebeurt in een bepaalde gebruiker met een bepaald aanroepend pakket, en alles wat volgt erft die context. Lees de eigendom keten voordat je het instellingenscherm leest.

Wat het platform voor je bouwt

Sinds Android 11 stelt het platform VPN-inrichting beschikbaar via VpnManager. Een goedgekeurde app beschrijft een IKEv2-profiel, en het platform voert zelf de IPsec- en IKE-uitwisseling uit, zodat de app nooit pakketten aanraakt. Dat is het wezenlijke verschil met een eigen VPN-app, die VpnService implementeert en de tunnel in zijn eigen proces bouwt.

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

De aanroep hierboven is een schets van de vorm en geen blok om te kopiëren: de builder heeft meerdere authenticatievarianten, ze verschillen per API-niveau, en het profiel draagt ook het vertrouwensmateriaal van het servercertificaat. Wat voor de eigendomsvraag telt, is smaller dan de syntaxis.

Twee eigenschappen volgen uit dit ontwerp. Het profiel is data, dus het kan door een beheerder worden ingericht in plaats van met de hand getypt. En de tunnel is een platformnetwerk, dus hij verschijnt bij applicaties als een netwerk met VPN-transport en niet als de socket van een andere app.

Eigenaarschap is eerst de gebruiker, dan het pakket

Meerdere gebruikers op Android is echte scheiding, geen label. Een werkprofiel is een aparte gebruiker met eigen geïnstalleerde pakketten, eigen appgegevens, eigen keystore en eigen vertrouwensankers. Hetzelfde product dat op beide plaatsen is geïnstalleerd, zijn twee instanties met verschillende gebruikers-id's, zelfs wanneer de launcherpictogrammen en productnamen identiek zijn.

De inrichting wordt vastgelegd op het aanroepende pakket in die gebruiker. Een inrichtingsapp die in het persoonlijke profiel draait, maakt dus een persoonlijke tunnel, en de werkapps in het werkprofiel zien daar niets van. Het omgekeerde geldt ook, en daarom is een tunnel van het werkprofiel onzichtbaar voor persoonlijke apps zonder een expliciet beleid dat anders zegt.

Een apparaatbeleidscontroller kan inrichten namens een beheerd profiel, en dat verklaart de vermelding die niemand op kantoor zich herinnert te hebben gemaakt. Als je een telefoon controleert, is dat de waarschijnlijke eigenaar van een grijs gemaakt profiel, en het is niet aan jou om het als experiment te verwijderen.

Drie poorten voordat een pakket beweegt

De eerste poort is bevoegdheid: het beheer moet VPN überhaupt toestaan, en sommige uitrollen beperken ook het type naast het bestaan. De tweede is identiteit: het clientcertificaat of de inloggegevens moeten beschikbaar zijn in de gebruiker die het profiel bezit, omdat een certificaat dat in de persoonlijke keystore is geïmporteerd niet zichtbaar is voor het werkprofiel.

De derde is toestemming en beleid. Een gebruiker keurt de verbinding meestal goed wanneer hij voor het eerst wordt gebruikt, en een beheerder kan hem daarnaast vastzetten als altijd aan, eventueel met lockdown zodat verkeer de tunnel niet kan verlaten. Die instellingen bepalen wat er gebeurt als de tunnel wegvalt, en dat is het deel dat gebruikers opmerken.

Bereik is waar de drie samenkomen. Het profiel bepaalt de gateway en de identiteit, terwijl de beleidslaag bepaalt welke applicaties de tunnel mogen gebruiken en of het verkeer erdoorheen wordt gedwongen. Twee telefoons met identieke gatewayadressen kunnen zich daarom heel verschillend gedragen.

Waarom een persoonlijke verbinding werkapps niet dekt

Verkeer van een werkapp wordt gegenereerd in de werkgebruiker, en het netwerkbeleid dat geldt is dat in die gebruiker. Een tunnel die in het persoonlijke profiel is opgezet, draagt het niet, hoe gezond de indicator er ook uitziet. Dat ene feit verklaart de meeste meldingen waarin een gebruiker zweert dat de VPN verbonden is en één bepaalde app toch een interne dienst niet bereikt.

Naamresolutie volgt dezelfde grens. Privé-DNS-achtervoegsels en vertrouwensankers zijn per gebruiker, dus een interne hostnaam die in het persoonlijke profiel wordt opgelost, kan in het werkprofiel falen, zelfs met een ogenschijnlijk gelijkwaardige tunnel, omdat het resolverbeleid en het CA-archief verschillende objecten zijn.

Verifieer op een echte inschrijving, niet op een labtelefoon

Stel op het apparaat eerst de eigenaar van de vermelding vast: welke gebruiker, welk pakket, en of het profiel van de platforminrichter kwam of van een app die zijn eigen VPN-dienst implementeert. Bevestig daarna dat de identiteit die het profiel verwacht daadwerkelijk in de keystore van die gebruiker staat.

Test de levenscyclus, niet alleen de verbinding. Meld aan, ontgrendel het referentiearchief, laat het werkprofiel een avond pauzeren, haal het dan terug en controleer of de tunnel terugkomt zonder handmatige tik. Een werkprofiel dat na werktijd uitschakelt, neemt zijn tunnel mee, en dat is verwacht gedrag en geen storing, mits de verwachte niet-beschikbare toestand is opgeschreven.

Test ten slotte de werkapp zelf tegen een bekend intern eindpunt en vergelijk dat met het resultaat van het persoonlijke profiel. De twee mogen verschillen; wat niet mag verschillen is het eigendomsmodel. Als de tunnel bij de verkeerde gebruiker hoort, lost het opnieuw uitgeven van certificaten niets op.

Forceer de kwestie niet door verborgen instellingen activiteiten te starten om een menu te onthullen, en kopieer geen privésleutels tussen profielen om een verbinding te laten verschijnen. De VpnManager-referentie beschrijft wat een aanroeper mag inrichten; als het goedgekeurde pad jouw geval niet omvat, is dat een beslissing voor de beheerder en geen instellingsprobleem.