Profily IKEv2 VPN v Androidu patří uživateli, ne zařízení

Označení vestavěný VPN v Androidu pokrývá dvě nesouvisející věci: implementaci protokolu, kterou platforma spouští za vás, a tu podobu nastavení, kterou se výrobce rozhodl ukázat. Není to tentýž objekt a ani jedno nezaručuje, že tunel patří uživateli, jehož aplikace ho potřebují. Zřízení probíhá v konkrétním uživateli s konkrétním volajícím balíčkem a vše další ten kontext dědí. Přečtěte si řetěz vlastnictví dřív než obrazovku nastavení.

Co za vás platforma postaví

Od Androidu 11 platforma vystavuje zřizování VPN přes VpnManager. Schválená aplikace popíše profil IKEv2 a platforma sama vede výměnu IPsec a IKE, takže aplikace na pakety nikdy nesahá. V tom je podstatný rozdíl oproti vlastní VPN aplikaci, která implementuje VpnService a staví tunel ve svém procesu.

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

Volání výše je náčrt tvaru, ne blok ke zkopírování: builder má několik variant ověřování, liší se podle úrovně API a profil nese i materiál důvěry pro serverový certifikát. Pro otázku vlastnictví je podstatné užší než syntaxe.

Z tohoto návrhu plynou dvě vlastnosti. Profil jsou data, takže ho může zřídit správce, místo aby se psal ručně. A tunel je síť platformy, takže se aplikacím jeví jako síť s transportem VPN, nikoli jako socket jiné aplikace.

Vlastníkem je uživatel, pak balíček

Víceuživatelský Android je skutečné oddělení, ne nálepka. Pracovní profil je samostatný uživatel s vlastními nainstalovanými balíčky, vlastními daty aplikací, vlastním úložištěm klíčů a vlastními kořeny důvěry. Stejný produkt nainstalovaný na obou místech jsou dvě instance s různými identifikátory uživatele, i když jsou ikony spouštěče a názvy produktu shodné.

Zřízení se eviduje proti volajícímu balíčku v daném uživateli. Aplikace pro zřízení běžící v osobním profilu tedy vytvoří osobní tunel a pracovní aplikace v pracovním profilu z něj nic nevidí. Platí to i obráceně, a proto je tunel pracovního profilu pro osobní aplikace neviditelný, dokud výslovná politika neříká jinak.

Kontroler politiky zařízení může zřizovat jménem spravovaného profilu, což vysvětluje záznam, o kterém si v kanceláři nikdo nepamatuje, že ho vytvořil. Pokud telefon auditujete, to je pravděpodobný vlastník zešedlého profilu a není na vás ho mazat jako experiment.

Tři brány, než se paket pohne

První brána je oprávnění: správa musí VPN vůbec povolit a některá nasazení omezují i typ vedle existence. Druhá je identita: klientský certifikát nebo přihlašovací údaje musí být dostupné v uživateli, který profil vlastní, protože certifikát importovaný do osobního úložiště není pro pracovní profil viditelný.

Třetí je souhlas a politika. Uživatel obvykle připojení schválí při prvním použití a správce ho navíc může zafixovat jako vždy zapnuté, volitelně se zámkem, aby provoz nemohl vyjít mimo tunel. Tato nastavení rozhodují, co se stane, když tunel spadne, a to je část, které si uživatelé všimnou.

Rozsah je místo, kde se všechny tři potkávají. Profil určuje bránu a identitu, zatímco vrstva politiky rozhoduje, které aplikace smějí tunel používat a zda je provoz nucen přes něj. Dva telefony se shodnými adresami brány se proto mohou chovat velmi různě.

Proč osobní připojení nepokryje pracovní aplikace

Provoz z pracovní aplikace vzniká v pracovním uživateli a platná síťová politika je ta v tomto uživateli. Tunel zřízený v osobním profilu ho nenese, ať indikátor vypadá jakkoli zdravě. Tento jediný fakt vysvětluje většinu hlášení, kde uživatel přísahá, že VPN je připojená, a jedna konkrétní aplikace přesto nedosáhne na interní službu.

Překlad jmen sleduje stejnou hranici. Soukromé sufixy DNS a kořeny důvěry jsou pro každého uživatele, takže interní jméno hostitele, které se přeloží v osobním profilu, může v pracovním selhat i s navenek rovnocenným tunelem, protože politika překladače a úložiště CA jsou různé objekty.

Ověřujte na skutečné registraci, ne na laboratorním telefonu

Na zařízení nejdřív určete vlastníka záznamu: který uživatel, který balíček a zda profil přišel od zřizovatele platformy, nebo od aplikace s vlastní VPN službou. Pak potvrďte, že identita, kterou profil očekává, je v úložišti klíčů daného uživatele skutečně přítomná.

Testujte životní cyklus, ne jen připojení. Přihlaste se, odemkněte úložiště přihlašovacích údajů, nechte pracovní profil na večer usnout, pak ho vraťte a zkontrolujte, zda se tunel vrátí bez ručního klepnutí. Pracovní profil, který se po pracovní době vypne, si tunel odnese, a to je očekávané chování, ne závada, pokud je očekávaný nedostupný stav zapsaný.

Nakonec otestujte samotnou pracovní aplikaci proti známému internímu koncovému bodu a porovnejte s výsledkem osobního profilu. Ty dvě se lišit smějí; lišit se nesmí model vlastnictví. Pokud tunel patří špatnému uživateli, žádné opětovné vydání certifikátů to nespraví.

Neřešte to násilím spouštěním skrytých aktivit nastavení, abyste odhalili menu, a nekopírujte soukromé klíče mezi profily, aby se připojení objevilo. Referenční stránka VpnManager dokumentuje, co volající smí zřídit; pokud schválená cesta váš případ nezahrnuje, je to rozhodnutí správce, ne problém nastavení.