Android 12 IKEv1 VPN: Versi Pelancaran, IKEv2, Aplikasi Pihak Ketiga

Dua telefon kedua-duanya melaporkan Android 12 dalam Tetapan, dan hanya satu daripadanya masih memulakan profil IPsec XAuth lama yang ditawarkan oleh gerbang anda. Perbezaannya bukan tetapan yang boleh dicapai pengguna: pengawal yang mengawal laluan IKEv1 legasi asli melihat tahap SDK yang dibekalkan bersama peranti, bukan hanya keluaran yang dijalankannya sekarang. Satu butiran itu menentukan sama ada perbandingan armada itu bermakna, dan ia juga menentukan laluan migrasi mana antara tiga yang anda benar-benar perlukan.

Dua telefon Android 12 bukan kes ujian yang sama

Perubahan AOSP yang menghentikan peranti baharu daripada memulakan profil IKEv1 legasi membandingkan DEVICE_INITIAL_SDK_INT dengan Android S, iaitu API 31. Dalam laluan permulaan legasi asli, profil yang layak menimbulkan kegagalan operasi tidak disokong sebelum sebarang sambungan berguna wujud. Telefon yang dibekalkan dengan Android 11 dan kemudian dikemas kini masih melepasi pengawal itu; model yang dilancarkan dengan Android 12 tidak.

Anda boleh membaca kedua-dua nombor pada peranti dengan penyahpepijatan diaktifkan:

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

Nilai pertama ialah tahap pelancaran yang diambil kira oleh pengawal, yang kedua ialah apa yang dijalankan telefon hari ini. Jika sifat itu tiada, rujuk dokumentasi sokongan model dan bukannya meneka daripada nama pemasaran, dan jangan andaikan binaan vendor mengekalkan setiap laluan keserasian yang dimiliki oleh keluaran asasnya.

Satu lagi perbezaan menjimatkan sejam masa sokongan yang terbuang: profil yang disimpan dan masih tersenarai dalam tetapan VPN tidak membuktikan apa-apa tentang sama ada platform akan memulakannya. Memasukkan semula PSK atau menyunting laluan tidak boleh menghapuskan semakan sokongan protokol yang berjalan lebih awal, dan kegagalan itu kelihatan seperti masalah kelayakan sedangkan ia bukan.

Laluan satu: kekalkan stak legasi asli di tempat ia masih berjalan

Stak legasi ialah yang membaca profil IPsec XAuth PSK, IPsec Hybrid RSA dan L2TP/IPsec PSK daripada skrin VPN sistem. Pada peranti yang dibekalkan di bawah API 31 ia kekal sebagai laluan yang berdaya maju selepas naik taraf, sebab itu percubaan pada telefon lama boleh berjaya manakala telefon baharu menggagalkan profil yang sama.

Perbandingan yang penting ialah mengikut kelas peranti, bukan mengikut versi Android: senaraikan model dalam armada, baca tahap API pelancaran mereka, dan pisahkan kepada peranti yang masih memulakan profil dan peranti yang tidak boleh. Apa-apa yang lain menghasilkan dasar sokongan yang bercanggah dengan dirinya sendiri sebaik sahaja pengguna membeli telefon baharu.

Laluan dua: profil IKEv2 platform

Model peruntukan awam Android untuk IKEv2 ialah objek yang berbeza, bukan profil IKEv1 yang dinamakan semula. API platform untuk profil IKEv2 tiba bersama API 30 dan menjangka IKEv2 dengan kaedah pengesahan yang ditawarkan gerbang, biasanya berasaskan sijil atau EAP. Tiada naik taraf serasi wayar daripada IKEv1 XAuth atau Hybrid kepada IKEv2: gerbang mesti dikonfigurasikan untuk protokol baharu, dan profil mesti membawa identiti yang sepadan.

Inilah laluan dengan hayat paling panjang, dan juga yang mendedahkan kerja sebenar. Pengesahan identiti, pengesahan pengguna, DNS, laluan terowong berpecah dan kebenaran sumber semuanya mesti bertahan dalam migrasi; jika hanya jabat tangan berjaya, pengguna kekal bersambung ke terowong yang tidak mencapai apa-apa.

Penggunaan biasanya melalui MDM atau konfigurasi terurus dan bukannya pengguna menaip medan. Jika infrastruktur itu belum wujud, pelan migrasi mesti memasukkannya, kerana memasukkan semula profil IKEv2 secara manual pada setiap peranti bukan operasi yang mampu ditampung oleh meja bantuan.

Laluan tiga: aplikasi klien pihak ketiga

Sesetengah aplikasi VPN membawa pelaksanaan protokol mereka sendiri dan tidak bergantung pada stak legasi asli sama sekali. Itu menjadikan mereka penyelesaian sementara yang sah untuk armada yang tidak dapat berhijrah dengan cepat, tetapi persoalan keserasian berpindah ke aplikasi: sama ada ia melaksanakan mod IKEv1 tepat yang dituturkan gerbang anda, dengan pengesahan dan suite sifer yang diperlukan gerbang.

Anggap matriks sokongan aplikasi itu sendiri sebagai pihak berkuasa dan bukannya penerangan kedai, dan uji satu peranti sebenar terhadap gerbang sebenar sebelum mengesyorkannya. Mengakar telefon untuk memulihkan laluan platform yang telah dibuang juga bukan penyelesaian yang diselenggara; ia memindahkan masalah ke konfigurasi tidak disokong yang boleh dipecahkan secara senyap oleh kemas kini sistem seterusnya.

Pilih mengikut apa yang gerbang boleh tawarkan

Keputusan menyempit apabila anda tahu dua perkara: peranti mana yang dilancarkan pada atau selepas API 31, dan sama ada gerbang boleh membentangkan perkhidmatan IKEv2 dengan model pendaftaran yang sama. Jika boleh, berhijrahlah dan berhenti melabur dalam profil legasi. Jika belum boleh, kekalkan IKEv1 untuk peranti yang masih memulakannya, dan beri peranti baharu klien pihak ketiga sebagai pengecualian berdokumen dan terhad masa dan bukannya penyelesaian tidak dinyatakan.

Dua perkara menjadikan pelan itu boleh dipertahankan. Pertama, catat sebab bagi setiap pengecualian bersama model dan tahap pelancaran, supaya juruaudit dapat melihat bahawa sempadan itu ialah pengawal platform dan bukannya keutamaan yang tidak dijelaskan. Kedua, anggap migrasi sebagai kerja terancang: IKEv1 telah ditamatkan oleh landasan piawaian (RFC 9395), yang bermaksud peranti yang tinggal akan terus mengecil dan pengecualian sepatutnya tamat bersamanya.