Android 12 ve IKEv1 VPN: sürüm anı, IKEv2, üçüncü taraf uygulamalar

İki telefon da Ayarlar'da Android 12 gösteriyor ve yalnızca biri ağ geçidinizin sunduğu eski IPsec XAuth profilini hâlâ başlatıyor. Fark, kullanıcının erişebileceği bir ayar değil: yerleşik eski IKEv1 yolunu kapatan koruma, cihazın birlikte geldiği SDK düzeyine bakıyor, yalnızca şu anda çalıştırdığı sürüme değil. Bu tek ayrıntı, filo karşılaştırmasının anlamlı olup olmadığına karar veriyor ve gerçekte üç geçiş yolundan hangisine ihtiyacınız olduğuna da karar veriyor.

İki Android 12 telefon aynı test vakası değil

Yeni cihazların eski IKEv1 profillerini başlatmasını durduran AOSP değişikliği, DEVICE_INITIAL_SDK_INT ile Android S'yi, yani API 31'i karşılaştırıyor. Yerleşik eski başlatma yolunda, uygun bir profil herhangi bir yararlı bağlantı oluşmadan önce desteklenmeyen işlem hatası veriyor. Android 11 ile gelen ve sonradan güncellenen bir telefon bu korumayı hâlâ geçiyor; Android 12 ile piyasaya çıkan bir model geçmiyor.

İki sayıyı hata ayıklaması açık bir cihazda okuyabilirsiniz:

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

İlk değer, korumanın önemsediği sürüm düzeyi; ikincisi telefonun bugün çalıştırdığı şey. Özelliğin olmadığı yerde, pazarlama adından tahmin etmek yerine modelin destek belgelerine dayanın ve üretici derlemesinin temel sürümün sahip olduğu her uyumluluk yolunu koruduğunu varsaymayın.

Bir ayrım daha, boşa harcanan bir saatlik desteği kurtarır: VPN ayarlarında hâlâ listelenen kayıtlı bir profil, platformun onu başlatıp başlatmayacağı konusunda hiçbir şey kanıtlamaz. PSK'yı yeniden girmek veya rotaları düzenlemek, daha önce çalışan bir protokol desteği denetimini kaldıramaz ve hata, olmadığı halde kimlik bilgisi sorunu gibi görünür.

Yol bir: yerleşik eski yığını hâlâ çalıştığı yerde tutun

Eski yığın, sistem VPN ekranından IPsec XAuth PSK, IPsec Hybrid RSA ve L2TP/IPsec PSK profillerini okuyan yığındır. API 31'in altında gelen bir cihazda yükseltmeden sonra da geçerli bir yol olarak kalır; bu yüzden eski bir ahizedeki pilot başarılı olabilirken yeni ahize aynı profilde başarısız olur.

Önemli olan karşılaştırma Android sürümüne göre değil, cihaz sınıfına göredir: filodaki modelleri listeleyin, sürüm anındaki API düzeylerini okuyun ve bunları profili hâlâ başlatan cihazlar ile başlatamayan cihazlar olarak bölün. Başka her şey, kullanıcı yeni bir telefon aldığı anda kendisiyle çelişen bir destek politikası üretir.

Yol iki: platform IKEv2 profilleri

Android'in IKEv2 için herkese açık sağlama modeli başka bir nesnedir, yeniden adlandırılmış bir IKEv1 profili değil. IKEv2 profilleri için platform API'si API 30 ile geldi ve ağ geçidinin sunduğu kimlik doğrulama yöntemiyle IKEv2 bekliyor, genellikle sertifika tabanlı veya EAP. IKEv1 XAuth veya Hybrid'den IKEv2'ye kablo düzeyinde uyumlu bir yükseltme yok: ağ geçidinin yeni protokol için yapılandırılması ve profilin eşleşen kimliği taşıması gerekir.

Bu, en uzun ömürlü yoldur ve gerçek işi de ortaya çıkaran yoldur. Kimlik doğrulama, kullanıcı kimlik doğrulaması, DNS, bölünmüş tünel rotaları ve kaynak yetkilendirmesi geçişten sağ çıkmalıdır; yalnızca el sıkışma başarılı olursa kullanıcılar hiçbir yere ulaşmayan bir tünele bağlı kalır.

Dağıtım genellikle bir MDM veya yönetilen yapılandırma üzerinden yürür, kullanıcının alanları yazmasıyla değil. Bu altyapı henüz yoksa geçiş planı onu içermelidir, çünkü her cihazda IKEv2 profilini elle yeniden girmek bir yardım masasının kaldırabileceği bir işlem değildir.

Yol üç: üçüncü taraf istemci uygulaması

Bazı VPN uygulamaları kendi protokol uygulamalarını getirir ve yerleşik eski yığına hiç bağlı değildir. Bu, onları hızlı geçiş yapamayan bir filo için meşru bir geçici çözüm yapar, ancak uyumluluk sorusu uygulamaya kayar: ağ geçidinizin konuştuğu tam IKEv1 modunu, ağ geçidinin istediği kimlik doğrulama ve şifreleme paketleriyle uyguluyor mu.

Mağaza açıklaması yerine uygulamanın kendi destek matrisini yetkili sayın ve önermeden önce gerçek bir cihazı gerçek ağ geçidine karşı test edin. Kaldırılan bir platform yolunu geri getirmek için telefonu rootlamak da sürdürülen bir çözüm değildir; sorunu bir sonraki sistem güncellemesinin sessizce bozabileceği desteklenmeyen bir yapılandırmaya taşır.

Ağ geçidinin sunabileceğine göre seçin

İki şeyi bildiğinizde karar daralır: hangi cihazlar API 31 veya sonrasında çıktı ve ağ geçidi aynı kayıt modeliyle bir IKEv2 hizmeti sunabiliyor mu. Sunabiliyorsa geçin ve eski profile yatırım yapmayı bırakın. Henüz sunamıyorsa, onu hâlâ başlatan cihazlar için IKEv1'i koruyun ve yeni cihazlara üçüncü taraf istemciyi belgelenmiş, süreli bir istisna olarak verin, dile getirilmemiş bir geçici çözüm olarak değil.

İki nokta planı savunulabilir kılar. Birincisi, her istisnanın nedenini model ve sürüm düzeyiyle birlikte kaydedin, böylece bir denetçi sınırın açıklanamayan bir tercih değil platform koruması olduğunu görsün. İkincisi, geçişi planlı iş olarak ele alın: IKEv1 standartlar hattında kullanımdan kaldırılmıştır (RFC 9395), bu da kalan cihazların küçülmeye devam edeceği ve istisnaların onlarla birlikte sona ermesi gerektiği anlamına gelir.