Android 12 și IKEv1 VPN: versiunea de lansare, IKEv2, aplicații terțe

Două telefoane arată amândouă Android 12 în Setări, și doar unul dintre ele mai pornește vechiul profil IPsec XAuth oferit de gateway. Diferența nu este o setare la care utilizatorul poate ajunge: garda care blochează calea legacy nativă IKEv1 se uită la nivelul SDK cu care a fost livrat dispozitivul, nu doar la versiunea pe care o rulează acum. Acest singur detaliu decide dacă o comparație de flotă are sens și decide și care dintre cele trei căi de migrare îți trebuie cu adevărat.

Două telefoane Android 12 nu sunt același caz de test

Modificarea din AOSP care a oprit dispozitivele noi să pornească profiluri IKEv1 legacy compară DEVICE_INITIAL_SDK_INT cu Android S, adică API 31. În calea legacy nativă de pornire, un profil eligibil ridică o eroare de operațiune neacceptată înainte să existe vreo conexiune utilă. Un telefon livrat cu Android 11 și actualizat ulterior trece încă de acea gardă; un model lansat cu Android 12 nu trece.

Poți citi cele două numere pe un dispozitiv cu depanare activată:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

Prima valoare este nivelul de lansare de care îi pasă gărzii, a doua este ce rulează telefonul astăzi. Unde proprietatea lipsește, sprijină-te pe documentația de suport a modelului în loc să ghicești după numele de marketing, și nu presupune că o compilare a producătorului păstrează fiecare cale de compatibilitate pe care o avea versiunea de bază.

Încă o distincție economisește o oră de timp de suport irosit: un profil salvat, încă listat în setările VPN, nu dovedește nimic despre dacă platforma îl va porni. Reintroducerea PSK sau editarea rutelor nu poate elimina o verificare de suport de protocol care rulează mai devreme, iar eșecul arată ca o problemă de acreditări atunci când nu este.

Calea întâi: păstrează stiva legacy nativă acolo unde încă rulează

Stiva legacy este cea care citește profiluri IPsec XAuth PSK, IPsec Hybrid RSA și L2TP/IPsec PSK din ecranul VPN al sistemului. Pe un dispozitiv livrat sub API 31 rămâne o cale viabilă după actualizare, de aceea un pilot pe un aparat mai vechi poate reuși în timp ce un aparat nou eșuează pe același profil.

Comparația care contează este pe clasă de dispozitiv, nu pe versiune de Android: listează modelele din flotă, citește nivelurile API de lansare și împarte-le în dispozitive care încă pornesc profilul și dispozitive care nu pot. Orice altceva produce o politică de suport care se contrazice în momentul în care un utilizator cumpără un telefon nou.

Calea a doua: profiluri IKEv2 de platformă

Modelul public de provisioning al Android pentru IKEv2 este alt obiect, nu un profil IKEv1 redenumit. API-ul de platformă pentru profiluri IKEv2 a apărut cu API 30 și așteaptă IKEv2 cu metoda de autentificare oferită de gateway, de obicei pe bază de certificat sau EAP. Nu există un upgrade compatibil pe fir de la IKEv1 XAuth sau Hybrid la IKEv2: gateway-ul trebuie configurat pentru noul protocol, iar profilul trebuie să poarte identitatea potrivită.

Aceasta este calea cu cea mai lungă viață și tot cea care expune munca reală. Validarea identității, autentificarea utilizatorilor, DNS, rutele de tunel divizat și autorizarea resurselor trebuie toate să supraviețuiască migrării; dacă doar handshake-ul reușește, utilizatorii rămân conectați la un tunel care nu ajunge nicăieri.

Implementarea trece de obicei printr-un MDM sau o configurație gestionată, nu printr-un utilizator care tastează câmpuri. Dacă infrastructura aceea încă nu există, planul de migrare trebuie să o includă, pentru că reintroducerea manuală a unui profil IKEv2 pe fiecare dispozitiv nu este o operațiune pe care un help desk să o absorbă.

Calea a treia: o aplicație client terță

Unele aplicații VPN vin cu propria implementare de protocol și nu depind deloc de stiva legacy nativă. Asta le face o soluție temporară legitimă pentru o flotă care nu poate migra rapid, dar întrebarea de compatibilitate se mută la aplicație: dacă implementează exact modul IKEv1 pe care îl vorbește gateway-ul, cu autentificarea și suitele de cifrare cerute de gateway.

Tratează matricea de suport a aplicației ca autoritate, nu descrierea din magazin, și testează un dispozitiv real împotriva gateway-ului real înainte de a o recomanda. Rootarea unui telefon pentru a restaura o cale de platformă eliminată nu este nici ea o soluție întreținută; mută problema într-o configurație neacceptată pe care următoarea actualizare de sistem o poate rupe în tăcere.

Alege după ce poate oferi gateway-ul

Decizia se îngustează când știi două lucruri: care dispozitive au fost lansate pe API 31 sau după, și dacă gateway-ul poate prezenta un serviciu IKEv2 cu același model de înrolare. Dacă poate, migrează și oprește investiția în profilul legacy. Dacă încă nu poate, păstrează IKEv1 pentru dispozitivele care îl mai pornesc și dă dispozitivelor noi un client terț ca excepție documentată, cu termen, în loc de o soluție ocolitoare nedeclarată.

Două puncte fac planul defensabil. Primul, notează motivul fiecărei excepții împreună cu modelul și nivelul de lansare, ca un auditor să vadă că granița este o gardă de platformă și nu o preferință neexplicată. Al doilea, tratează migrarea ca muncă planificată: IKEv1 este depreciat pe linia standardelor (RFC 9395), ceea ce înseamnă că dispozitivele rămase vor continua să scadă, iar excepțiile ar trebui să expire odată cu ele.