Android 12 və IKEv1 VPN: buraxılış versiyası, IKEv2 və üçüncü tərəf tətbiqləri

İki telefonun hər ikisi Parametrlərdə Android 12 göstərir, amma onlardan yalnız biri şlüzünüzün təklif etdiyi köhnə IPsec XAuth profilini hələ də işə salır. Fərq istifadəçinin çata biləcəyi parametr deyil: native legacy IKEv1 yolunu idarə edən qoruyucu cihazın hansı SDK səviyyəsi ilə göndərildiyinə baxır, yalnız indi işlədiyi buraxılışa deyil. Bu tək detal donanma müqayisəsinin mənalı olub-olmadığını və üç miqrasiya yolundan hansına həqiqətən ehtiyacınız olduğunu müəyyən edir.

İki Android 12 telefonu eyni sınaq halı deyil

Yeni cihazların legacy IKEv1 profillərini işə salmasını dayandıran AOSP dəyişikliyi DEVICE_INITIAL_SDK_INT dəyərini Android S ilə müqayisə edir, yəni API 31. Native legacy başlatma yolunda uyğun profil hər hansı faydalı bağlantı yaranmadan əvvəl dəstəklənməyən əməliyyat xətası verir. Android 11 ilə göndərilib sonra yenilənən telefon bu qoruyucudan hələ də keçir; Android 12 ilə buraxılan model isə keçmir.

İki rəqəmi sazlama aktiv olan cihazda oxuya bilərsiniz:

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

Birinci dəyər qoruyucunun baxdığı buraxılış səviyyəsidir, ikincisi telefonun bu gün işlədiyi səviyyədir. Xüsusiyyət olmadıqda marketinq adından təxmin etmək əvəzinə model dəstəyi sənədlərinə güvənin və istehsalçı builinin baza buraxılışındakı bütün uyğunluq yollarını saxladığını güman etməyin.

Daha bir fərq bir saat boşa gedən dəstək vaxtına qənaət edir: VPN parametrlərində hələ də siyahıda olan saxlanmış profil platformanın onu işə salacağına dair heç nə sübut etmir. PSK-nı yenidən daxil etmək və ya marşrutları redaktə etmək daha əvvəl işləyən protokol dəstəyi yoxlamasını aradan qaldıra bilməz və nasazlıq etimad məlumatı problemi kimi görünür, halbuki deyil.

Birinci yol: native legacy stack hələ də işlədiyi yerdə saxlanılsın

Legacy stack sistemin VPN ekranından IPsec XAuth PSK, IPsec Hybrid RSA və L2TP/IPsec PSK profillərini oxuyan stackdir. API 31-dən aşağı göndərilən cihazda yeniləmədən sonra da işlək yol olaraq qalır, buna görə köhnə telefonda pilot uğur qazanır, yeni telefon isə eyni profili işə sala bilmir.

Əhəmiyyətli müqayisə Android versiyasına görə deyil, cihaz sinfinə görədir: donanmadaki modelləri siyahıya alın, onların buraxılış API səviyyələrini oxuyun və profili hələ də işə salanlarla sala bilməyənləri ayırın. Başqa hər hansı yanaşma istifadəçi yeni telefon alan kimi özünə zidd dəstək siyasəti yaradır.

İkinci yol: platforma IKEv2 profilləri

Android-in IKEv2 üçün ictimai təchizat modeli başqa bir obyektdir, yenidən adlandırılmış IKEv1 profili deyil. IKEv2 profilləri üçün platforma API-si API 30 ilə gəldi və şlüzün təklif etdiyi autentifikasiya üsulu ilə IKEv2 gözləyir, adətən sertifikat əsaslı və ya EAP. IKEv1 XAuth və ya Hybrid-dən IKEv2-yə naqil uyğun yüksəltmə yoxdur: şlüz yeni protokol üçün konfiqurasiya olunmalı, profil isə uyğun kimliyi daşımalıdır.

Bu, ən uzun ömürlü yoldur və eyni zamanda əsl işi üzə çıxaran yoldur. Kimlik doğrulaması, istifadəçi autentifikasiyası, DNS, split-tunnel marşrutları və resurs avtorizasiyası hamısı miqrasiyadan sağ çıxmalıdır; yalnız əl sıxışmanı uğurla keçirmək istifadəçiləri heç yerə çatmayan bir tunelə bağlı qoyur.

Yerləşdirmə adətən istifadəçinin sahələri yazması əvəzinə MDM və ya idarə olunan konfiqurasiya vasitəsilə gedir. Əgər bu infrastruktur hələ yoxdursa, miqrasiya planı onu əhatə etməlidir, çünki IKEv2 profilini hər cihazda əl ilə yenidən daxil etmək dəstək xidmətinin qəbul edə biləcəyi əməliyyat deyil.

Üçüncü yol: üçüncü tərəf müştəri tətbiqi

Bəzi VPN tətbiqləri öz protokol implementasiyalarını gətirir və native legacy stack-dən heç asılı deyil. Bu, onları tez miqrasiya edə bilməyən donanma üçün qanuni müvəqqəti həll edir, amma uyğunluq sualı tətbiqə keçir: şlüzünüzün danışdığı dəqiq IKEv1 rejimini, şlüzün tələb etdiyi autentifikasiya və şifr dəstləri ilə həyata keçirirmi.

Tətbiqin öz dəstək matrisini səlahiyyət kimi qəbul edin, mağaza təsvirini deyil, və tövsiyə etməzdən əvvəl bir real cihazı real şlüzə qarşı sınaqdan keçirin. Çıxarılmış platforma yolunu bərpa etmək üçün telefonu root etmək də saxlanılan həll deyil; problem növbəti sistem yeniləməsinin səssizcə poza biləcəyi dəstəklənməyən konfiqurasiyaya keçir.

Şlüzün nə təklif edə biləcəyinə görə seçin

Qərar iki şeyi bildikdən sonra daralır: hansı cihazlar API 31 və ya ondan sonra buraxılıb və şlüz eyni qeydiyyat modeli ilə IKEv2 xidməti təqdim edə bilirmi. Əgər bilirsə, miqrasiya edin və legacy profilə investisiya qoymağı dayandırın. Hələ bilmirsə, onu hələ də işə salan cihazlar üçün IKEv1 saxlayın və yeni cihazlara üçüncü tərəf müştərini sənədləşdirilmiş, vaxtla məhdud istisna kimi verin, açıqlanmamış yan keçid kimi deyil.

İki məqam planı müdafiə oluna bilən edir. Birincisi, hər istisnanın səbəbini model və buraxılış səviyyəsi ilə birlikdə qeyd edin ki, auditor sərhədin izahsız seçim deyil, platforma qoruyucusu olduğunu görsün. İkincisi, miqrasiyanı planlı iş kimi qəbul edin: IKEv1 standartlar trekində köhnəlmişdir (RFC 9395), yəni qalan cihazlar azalmağa davam edəcək və istisnalar da onlarla birlikdə bitməlidir.