Profily VPN IKEv2 v Androide patria používateľovi, nie zariadeniu

Pojem vstavaná VPN pokrýva v Androide dve nesúvisiace veci: implementáciu protokolu, ktorú platforma spúšťa vo vašom mene, a tú podobu nastavení, ktorú sa výrobca rozhodol zverejniť. Nie je to ten istý objekt a ani jedno nezaručuje, že tunel patrí používateľovi, ktorého aplikácie ho potrebujú. Zriadenie prebieha v konkrétnom používateľovi s konkrétnym volajúcim balíkom a všetko ďalšie ten kontext dedí. Prečítajte si reťazec vlastníctva skôr, než si prečítate obrazovku nastavení.

Čo za vás platforma postaví

Od Androidu 11 platforma sprístupňuje zriaďovanie VPN cez VpnManager. Schválená aplikácia opíše profil IKEv2 a platforma sama vykoná výmenu IPsec a IKE, takže aplikácia sa packetov nikdy nedotkne. To je podstatný rozdiel oproti vlastnej VPN aplikácii, ktorá implementuje VpnService a buduje tunel vo vlastnom procese.

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

Uvedené volanie je náčrt tvaru, nie blok na kopírovanie: builder má niekoľko variantov autentifikácie, líšia sa podľa úrovne API a profil nesie aj materiál dôvery certifikátu servera. Pre otázku vlastníctva je dôležité niečo užšie než syntax.

Z tohto dizajnu vyplývajú dve vlastnosti. Profil sú dáta, takže ho môže zriadiť administrátor namiesto ručného písania. A tunel je sieť platformy, takže sa aplikáciám javí ako sieť s transportom VPN, nie ako socket inej aplikácie.

Vlastníctvo je najprv používateľ, potom balík

Viacpoužívateľský režim Androidu je skutočné oddelenie, nie označenie. Pracovný profil je samostatný používateľ s vlastnými nainštalovanými balíkmi, vlastnými dátami aplikácií, vlastným keystore a vlastnými kotvami dôvery. Ten istý produkt nainštalovaný na oboch miestach sú dve inštancie s rôznymi identifikátormi používateľa, aj keď sú ikony v spúšťači a názvy produktu rovnaké.

Zriadenie sa zaznamenáva na volajúci balík v tom používateľovi. Aplikácia na zriaďovanie spustená v osobnom profile teda vytvorí osobný tunel a pracovné aplikácie v pracovnom profile z neho nič nevidia. Opak je tiež pravdou, a preto je tunel pracovného profilu neviditeľný pre osobné aplikácie bez výslovnej politiky, ktorá hovorí inak.

Kontrolér politiky zariadenia môže zriaďovať v mene spravovaného profilu, a to vysvetľuje záznam, o ktorom si nikto v kancelárii nepamätá, že ho vytvoril. Ak robíte audit telefónu, to je pravdepodobný vlastník zosiveného profilu a vymazať ho ako experiment nie je vaša vec.

Tri brány, kým sa packet pohne

Prvá brána je oprávnenie: správa musí VPN vôbec povoliť a niektoré nasadenia obmedzujú aj typ, nielen existenciu. Druhá je identita: klientsky certifikát alebo prihlasovacie údaje musia byť dostupné v používateľovi, ktorý profil vlastní, pretože certifikát importovaný do osobného keystore nie je pre pracovný profil viditeľný.

Tretia je súhlas a politika. Používateľ zvyčajne pripojenie schváli pri prvom použití a administrátor ho môže navyše pripnúť ako vždy zapnuté, prípadne so zámkom, aby premávka nemohla ísť mimo tunela. Tie nastavenia rozhodujú, čo sa stane, keď tunel padne, a to je časť, ktorú používatelia zaregistrujú.

Rozsah je miesto, kde sa všetky tri stretávajú. Profil určuje bránu a identitu, zatiaľ čo vrstva politiky určuje, ktoré aplikácie môžu tunel používať a či je premávka cez neho vynútená. Dva telefóny s rovnakými adresami brány sa preto môžu správať veľmi rozdielne.

Prečo osobné pripojenie nepokrýva pracovné aplikácie

Premávka z pracovnej aplikácie vzniká v pracovnom používateľovi a platná sieťová politika je tá v tomto používateľovi. Tunel vytvorený v osobnom profile ju neprenáša, nech indikátor vyzerá akokoľvek zdravo. Tento jediný fakt vysvetľuje väčšinu hlásení, v ktorých používateľ prisahá, že VPN je pripojená, a jedna konkrétna aplikácia napriek tomu nedosiahne internú službu.

Rozklad názvov sleduje rovnakú hranicu. Súkromné prípony DNS a kotvy dôvery sú pre používateľa, takže interné meno hostiteľa, ktoré sa rozloží v osobnom profile, môže v pracovnom profile zlyhať aj pri zdanlivo rovnocennom tuneli, pretože politika resolvera a úložisko CA sú rôzne objekty.

Overujte na skutočnej registrácii, nie na laboratórnom telefóne

Na zariadení najprv určite vlastníka záznamu: ktorý používateľ, ktorý balík a či profil prišiel od poskytovateľa platformy alebo od aplikácie implementujúcej vlastnú službu VPN. Potom potvrďte, že identita, ktorú profil očakáva, je skutočne prítomná v keystore toho používateľa.

Testujte životný cyklus, nielen pripojenie. Prihláste sa, odomknite úložisko prihlasovacích údajov, nechajte pracovný profil na večer pozastaviť, potom ho vráťte a skontrolujte, či sa tunel vráti bez ručného ťuknutia. Pracovný profil, ktorý sa po pracovnom čase vypne, si tunel zoberie so sebou, a to je očakávané správanie, nie porucha, ak je očakávaný nedostupný stav zapísaný.

Nakoniec otestujte samotnú pracovnú aplikáciu voči známemu internému koncovému bodu a porovnajte s výsledkom osobného profilu. Tie dve sa môžu líšiť; líšiť sa nesmie model vlastníctva. Ak tunel patrí nesprávnemu používateľovi, opätovné vydávanie certifikátov to nespraví.

Netlačte na vec spúšťaním skrytých aktivít nastavení, aby ste odhalili menu, a nekopírujte súkromné kľúče medzi profilmi, aby pripojenie vyzeralo. Referencia VpnManager dokumentuje, čo smie volajúci zriadiť; ak schválená cesta nezahŕňa váš prípad, je to rozhodnutie administrátora, nie problém nastavení.