Android 12 dan IKEv1 VPN: versi bawaan pabrik, IKEv2, dan aplikasi pihak ketiga

Dua ponsel sama-sama menampilkan Android 12 di Pengaturan, dan hanya satu yang masih menjalankan profil IPsec XAuth lama yang ditawarkan gateway Anda. Perbedaannya bukan pengaturan yang bisa dijangkau pengguna: penjaga yang mengatur jalur IKEv1 native melihat level SDK saat perangkat dikirim, bukan hanya versi yang berjalan sekarang. Satu detail itu menentukan apakah perbandingan armada masuk akal, dan juga menentukan jalur migrasi mana dari tiga yang benar-benar Anda butuhkan.

Dua ponsel Android 12 bukan kasus uji yang sama

Perubahan AOSP yang menghentikan perangkat baru menjalankan profil IKEv1 lama membandingkan DEVICE_INITIAL_SDK_INT dengan Android S, yaitu API 31. Di jalur boot native, profil yang memenuhi syarat memunculkan kegagalan operasi tak didukung sebelum ada koneksi berguna apa pun. Ponsel yang dikirim dengan Android 11 lalu diperbarui masih melewati penjaga itu; model yang diluncurkan dengan Android 12 tidak.

Anda dapat membaca kedua angka pada perangkat dengan debugging aktif:

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

Nilai pertama adalah level peluncuran yang diperhatikan penjaga, yang kedua adalah yang dijalankan ponsel hari ini. Bila properti tidak ada, andalkan dokumentasi dukungan model alih-alih menebak dari nama pemasaran, dan jangan berasumsi build pabrikan mempertahankan semua jalur kompatibilitas versi dasarnya.

Satu pembedaan lagi menghemat satu jam waktu dukungan yang terbuang: profil tersimpan yang masih terdaftar di pengaturan VPN tidak membuktikan apa pun tentang apakah platform akan menjalankannya. Memasukkan ulang PSK atau menyunting rute tidak dapat menghapus pemeriksaan dukungan protokol yang berjalan lebih awal, dan kegagalannya tampak seperti masalah kredensial padahal bukan.

Jalur satu: pertahankan tumpukan lama di tempat yang masih berjalan

Tumpukan lama adalah yang membaca profil IPsec XAuth PSK, IPsec Hybrid RSA, dan L2TP/IPsec PSK dari layar VPN sistem. Pada perangkat yang dikirim di bawah API 31, tumpukan itu tetap jalur yang layak setelah pembaruan, karena itu uji coba pada ponsel lama bisa berhasil sementara ponsel baru tidak menjalankan profil yang sama.

Perbandingan yang penting adalah per kelas perangkat, bukan per versi Android: daftarkan model di armada, baca level API peluncurannya, dan pisahkan menjadi perangkat yang masih menjalankan profil dan yang tidak bisa. Apa pun yang lain menghasilkan kebijakan dukungan yang bertentangan dengan dirinya sendiri begitu pengguna membeli ponsel baru.

Jalur dua: profil IKEv2 platform

Model penyediaan publik Android untuk IKEv2 adalah objek lain, bukan profil IKEv1 yang diganti nama. API platform untuk profil IKEv2 hadir bersama API 30 dan mengharapkan IKEv2 dengan metode autentikasi yang ditawarkan gateway, biasanya berbasis sertifikat atau EAP. Tidak ada peningkatan yang kompatibel secara kabel dari IKEv1 XAuth atau Hybrid ke IKEv2: gateway harus dikonfigurasi untuk protokol baru, dan profil harus membawa identitas yang sesuai.

Ini jalur dengan umur terpanjang, dan juga yang menyingkap pekerjaan sebenarnya. Validasi identitas, autentikasi pengguna, DNS, rute split-tunnel, dan otorisasi sumber daya semuanya harus bertahan melewati migrasi; membuat hanya jabat tangan berhasil akan meninggalkan pengguna tersambung ke terowongan yang tidak mencapai apa pun.

Penerapan biasanya lewat MDM atau konfigurasi terkelola alih-alih pengguna mengetik kolom. Jika infrastruktur itu belum ada, rencana migrasi harus memasukkannya, karena mengetik ulang profil IKEv2 secara manual di setiap perangkat bukan operasi yang bisa diserap meja bantuan.

Jalur tiga: aplikasi klien pihak ketiga

Sejumlah aplikasi VPN membawa implementasi protokol sendiri dan sama sekali tidak bergantung pada tumpukan native. Itu menjadikannya tambalan sementara yang sah bagi armada yang tidak bisa bermigrasi cepat, tetapi pertanyaan kompatibilitas berpindah ke aplikasi: apakah ia mengimplementasikan persis mode IKEv1 yang dipakai gateway Anda, dengan autentikasi dan rangkaian cipher yang diminta gateway.

Perlakukan matriks dukungan aplikasi itu sendiri sebagai otoritas, bukan deskripsi toko, dan uji satu perangkat nyata terhadap gateway nyata sebelum merekomendasikannya. Melakukan root pada ponsel untuk memulihkan jalur platform yang dihapus juga bukan solusi yang dipelihara; itu memindahkan masalah ke konfigurasi tak didukung yang bisa dirusak diam-diam oleh pembaruan sistem berikutnya.

Pilih berdasarkan apa yang bisa ditawarkan gateway

Keputusan menyempit setelah Anda tahu dua hal: perangkat mana yang diluncurkan pada atau setelah API 31, dan apakah gateway dapat menyediakan layanan IKEv2 dengan model pendaftaran yang sama. Jika bisa, bermigrasilah dan berhenti berinvestasi pada profil lama. Jika belum bisa, pertahankan IKEv1 untuk perangkat yang masih menjalankannya, dan beri perangkat baru klien pihak ketiga sebagai pengecualian terdokumentasi dan berbatas waktu, bukan sebagai jalan pintas yang tidak dinyatakan.

Dua hal membuat rencana itu bisa dipertahankan. Pertama, catat alasan setiap pengecualian bersama model dan level peluncuran, agar auditor melihat bahwa batasnya adalah penjaga platform, bukan preferensi tanpa penjelasan. Kedua, perlakukan migrasi sebagai pekerjaan terencana: IKEv1 sudah usang di jalur standar (RFC 9395), yang berarti perangkat yang tersisa akan terus menyusut dan pengecualiannya semestinya berakhir bersama mereka.