Profilurile VPN IKEv2 din Android sunt pe utilizator, nu pe dispozitiv
Tunelul este creat pentru fiecare utilizator și pentru pachetul apelant, așa că o intrare de pe telefon poate fi cea greșită. Verifică proprietatea înainte de setări.
Expresia VPN încorporat acoperă pe Android două lucruri fără legătură: o implementare de protocol pe care platforma o rulează în numele tău și forma de setări pe care producătorul a decis să o expună. Nu sunt același obiect, iar niciuna nu garantează că tunelul aparține utilizatorului ale cărui aplicații au nevoie de el. Provisionarea se face într-un anumit utilizator cu un anumit pachet apelant, iar tot ce urmează moștenește acest context. Citește lanțul de proprietate înainte de ecranul de setări.
Ce construiește platforma pentru tine
Începând cu Android 11 platforma expune provisionarea VPN prin VpnManager. O aplicație aprobată descrie un profil IKEv2, iar platforma execută singură schimbul IPsec și IKE, astfel încât aplicația nu atinge niciodată pachetele. Aceasta este diferența semnificativă față de o aplicație VPN proprie, care implementează VpnService și construiește tunelul în propriul proces.
val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
.setAuthUsernamePassword(user, secret, rootCa)
.build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)Apelul de mai sus este o schiță a formei, nu un bloc de copiat: constructorul are mai multe variante de autentificare, ele diferă în funcție de nivelul API, iar profilul poartă și materialul de încredere al certificatului serverului. Ceea ce contează pentru întrebarea proprietății este mai îngust decât sintaxa.
Din acest design decurg două proprietăți. Profilul este date, așa că poate fi creat de un administrator în loc să fie tastat manual. Iar tunelul este o rețea a platformei, așa că apare aplicațiilor ca o rețea cu transport VPN, nu ca socket-ul altei aplicații.
Proprietatea este utilizatorul, apoi pachetul
Modul multi-utilizator din Android este separare reală, nu o etichetă. Un profil de lucru este un utilizator separat, cu pachetele lui instalate, datele lui de aplicații, propriul keystore și propriile ancore de încredere. Același produs instalat în ambele locuri înseamnă două instanțe cu identificatori de utilizator diferiți, chiar și atunci când pictogramele din launcher și numele produsului sunt identice.
Provisionarea este înregistrată pe pachetul apelant din acel utilizator. Așa că o aplicație de provisionare care rulează în profilul personal creează un tunel personal, iar aplicațiile de lucru din profilul de lucru nu văd nimic din el. Și invers este adevărat, de aceea un tunel din profilul de lucru este invizibil pentru aplicațiile personale fără o politică explicită care să spună altfel.
Un controlor de politică de dispozitiv poate face provisionare în numele unui profil administrat, și asta explică intrarea pe care nimeni din birou nu își amintește că a creat-o. Dacă auditezi un telefon, acela este proprietarul probabil al unui profil gri, și nu este treaba ta să îl ștergi ca experiment.
Trei porți înainte ca un pachet să se miște
Prima poartă este autoritatea: administrarea trebuie să permită VPN deloc, iar unele implementări restricționează și tipul, nu doar existența. A doua este identitatea: certificatul de client sau acreditările trebuie să fie disponibile în utilizatorul care deține profilul, pentru că un certificat importat în keystore-ul personal nu este vizibil pentru profilul de lucru.
A treia este consimțământul și politica. Utilizatorul aprobă de obicei conexiunea prima dată când este folosită, iar administratorul o poate fixa suplimentar ca mereu activă, opțional cu blocare, astfel încât traficul să nu poată ieși în afara tunelului. Acele setări decid ce se întâmplă când tunelul cade, iar aceasta este partea pe care utilizatorii o observă.
Domeniul este locul unde se întâlnesc toate trei. Profilul determină gateway-ul și identitatea, în timp ce stratul de politică decide ce aplicații pot folosi tunelul și dacă traficul este forțat prin el. Două telefoane cu adrese de gateway identice se pot comporta deci foarte diferit.
De ce o conexiune personală nu acoperă aplicațiile de lucru
Traficul dintr-o aplicație de lucru este generat în utilizatorul de lucru, iar politica de rețea aplicabilă este cea din acel utilizator. Un tunel stabilit în profilul personal nu îl transportă, oricât de sănătos ar arăta indicatorul. Acest singur fapt explică majoritatea raportărilor în care utilizatorul jură că VPN-ul este conectat, iar o aplicație anume tot nu ajunge la un serviciu intern.
Rezolvarea numelor urmează aceeași graniță. Sufixele DNS private și ancorele de încredere sunt pe utilizator, așa că un nume de gazdă intern care se rezolvă în profilul personal poate eșua în profilul de lucru chiar și cu un tunel aparent echivalent, pentru că politica resolver-ului și depozitul de CA sunt obiecte diferite.
Verifică pe o înrolare reală, nu pe un telefon de laborator
Pe dispozitiv, identifică mai întâi proprietarul intrării: ce utilizator, ce pachet și dacă profilul a venit de la provisionerul platformei sau de la o aplicație care își implementează propriul serviciu VPN. Apoi confirmă că identitatea pe care o așteaptă profilul este într-adevăr prezentă în keystore-ul acelui utilizator.
Testează ciclul de viață, nu doar conectarea. Autentifică-te, deblochează depozitul de acreditări, lasă profilul de lucru să pauzeze pentru o seară, apoi adu-l înapoi și verifică dacă tunelul revine fără o atingere manuală. Un profil de lucru care se oprește după program își ia tunelul cu el, iar asta este comportament așteptat, nu o defecțiune, cu condiția ca starea de indisponibilitate așteptată să fie scrisă.
În final, testează aplicația de lucru în sine împotriva unui endpoint intern cunoscut și compară cu rezultatul profilului personal. Cele două au voie să difere; ceea ce nu are voie să difere este modelul de proprietate. Dacă tunelul aparține utilizatorului greșit, reemiterea certificatelor nu îl repară.
Nu forța lucrurile lansând activități ascunse de setări pentru a dezvălui un meniu și nu copia chei private între profiluri pentru ca o conexiune să apară. Referința VpnManager documentează ce are voie un apelant să provisioneze; dacă calea aprobată nu include cazul tău, aceea este o decizie a administratorului, nu o problemă de setări.