Android IKEv2 VPN-profiele is per gebruiker, nie per toestel nie

Die term ingeboude VPN dek twee onverwante dinge op Android: ’n protokolimplementering wat die platform namens jou laat loop, en watter instellingsvorm die vervaardiger ook al besluit het om beskikbaar te stel. Dit is nie dieselfde objek nie, en nie een van die twee waarborg dat die tonnel aan die gebruiker behoort wie se programme dit nodig het nie. Inrigting vind in ’n spesifieke gebruiker met ’n spesifieke oproepende pakket plaas, en alles wat volg erf daardie konteks. Lees die eienaarskapketting voordat jy die instellingskerm lees.

Wat die platform vir jou bou

Sedert Android 11 stel die platform VPN-inrigting deur VpnManager beskikbaar. ’n Goedgekeurde program beskryf ’n IKEv2-profiel, en die platform doen self die IPsec- en IKE-uitruiling, so die program raak nooit aan pakkette nie. Dit is die betekenisvolle verskil met ’n pasgemaakte VPN-program, wat VpnService implementeer en die tonnel in sy eie proses bou.

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

Die oproep hierbo is ’n skets van die vorm, nie ’n kopieer-en-plak-blok nie: die bouer het verskeie outentiseringsvariasies, hulle verskil per API-vlak, en die profiel dra ook die vertrouensmateriaal van die bediener-sertifikaat. Wat vir die eienaarskapvraag saak maak, is smaller as die sintaksis.

Twee eienskappe volg uit hierdie ontwerp. Die profiel is data, so dit kan deur ’n administrateur ingerig word eerder as om met die hand getik te word. En die tonnel is ’n platformnetwerk, so dit verskyn vir programme as ’n netwerk met ’n VPN-transport eerder as as een of ander ander program se socket.

Eienaarskap is die gebruiker, dan die pakket

Android se multi-gebruiker is werklike skeiding, nie ’n etiket nie. ’n Werkprofiel is ’n aparte gebruiker met sy eie geïnstalleerde pakkette, sy eie programdata, sy eie sleutelstoor en sy eie vertrouensankerpunte. Dieselfde produk wat op albei plekke geïnstalleer is, is twee instansies met verskillende gebruikersidentifikasies, selfs wanneer die laxeerikone en produkname identies is.

Inrigting word teen die oproepende pakket in daardie gebruiker aangeteken. ’n Inrigtingsprogram wat in die persoonlike profiel loop, skep dus ’n persoonlike tonnel, en die werkprogramme in die werkprofiel sien niks daarvan nie. Die omgekeerde is ook waar, en daarom is ’n werkprofiel-tonnel onsigbaar vir persoonlike programme sonder ’n uitdruklike beleid wat anders sê.

’n Toestelbeleidbeheerder kan namens ’n bestuurde profiel inrig, wat die inskrywing verklaar wat niemand in die kantoor onthou hulle het geskep nie. As jy ’n foon oudit, is dit waarskynlik die eienaar van ’n grysgemaakte profiel, en dit is nie joune om as eksperiment te verwyder nie.

Drie hekke voordat ’n pakket beweeg

Die eerste hek is gesag: bestuur moet ’n VPN hoegenaamd toelaat, en sommige ontplooiings beperk die tipe sowel as die bestaan. Die tweede is identiteit: die kliëntsertifikaat of geloofsbriewe moet beskikbaar wees in die gebruiker wat die profiel besit, want ’n sertifikaat wat in die persoonlike sleutelstoor ingevoer is, is nie vir die werkprofiel sigbaar nie.

Die derde is toestemming en beleid. ’n Gebruiker keur gewoonlik die verbinding die eerste keer goed dat dit gebruik word, en ’n administrateur kan dit boonop as altyd-aan vaspen, opsioneel met toesluiting sodat verkeer nie buite die tonnel kan uitgaan nie. Daardie instellings bepaal wat gebeur wanneer die tonnel af is, en dit is die deel wat gebruikers raaksien.

Omvang is waar die drie ontmoet. Die profiel bepaal die poort en die identiteit, terwyl die beleidslaag besluit watter programme die tonnel mag gebruik en of die verkeer daardeur gedwing word. Twee telefone met identiese poortadresse kan dus baie verskillend optree.

Waarom ’n persoonlike verbinding nie werkprogramme dek nie

Verkeer van ’n werkprogram word in die werkgebruiker gegenereer, en die netwerkbeleid wat geld, is dié in daardie gebruiker. ’n Tonnel wat in die persoonlike profiel opgerig is, dra dit nie, maak nie saak hoe gesond die aanwyser lyk nie. Daardie enkele feit verklaar die meeste verslae waarin ’n gebruiker sweer die VPN is verbind en een spesifieke program steeds nie ’n interne diens kan bereik nie.

Naamresolusie volg dieselfde grens. Private DNS-agtervoegsels en vertrouensankerpunte is per gebruiker, so ’n interne gasheernaam wat in die persoonlike profiel oplos, kan in die werkprofiel misluk selfs met ’n ekwivalent-lykende tonnel, want die resolveerderbeleid en die CA-stoor is verskillende objekte.

Verifieer op ’n werklike inskrywing, nie ’n laboratoriumfoon nie

Op die toestel, identifiseer eers die inskrywing se eienaar: watter gebruiker, watter pakket, en of die profiel van die platform-inrigter of van ’n program met sy eie VPN-diens gekom het. Bevestig dan dat die identiteit wat die profiel verwag, werklik in daardie gebruiker se sleutelstoor teenwoordig is.

Toets die lewensiklus, nie net die verbinding nie. Meld aan, ontsluit die geloofsbriewestoor, laat die werkprofiel vir die aand pouseer, bring dit dan terug en kyk of die tonnel terugkeer sonder ’n handmatige tik. ’n Werkprofiel wat na ure afskakel, neem sy tonnel saam, en dit is verwagte gedrag eerder as ’n fout, mits die verwagte onbeskikbare toestand neergeskryf is.

Toets ten slotte die werkprogram self teen ’n bekende interne eindpunt en vergelyk dit met die persoonlike profiel se resultaat. Die twee mag verskil; wat nie mag verskil nie, is die eienaarskapsmodel. As die tonnel aan die verkeerde gebruiker behoort, sal geen hoeveelheid heruitreiking van sertifikate dit regstel nie.

Moenie die saak forceer deur verborge instellingsaktiwiteite te begin om ’n kieslys te openbaar nie, en moenie private sleutels tussen profiele kopieer om ’n verbinding te laat verskyn nie. Die VpnManager-verwysing dokumenteer wat ’n oproeper mag inrig; as die goedgekeurde pad nie jou geval insluit nie, is dit ’n besluit vir die administrateur eerder as ’n instellingsprobleem.