Android 12 at IKEv1 VPN: bersyon ng paglulunsad, IKEv2, mga app ng third party

Dalawang telepono ang parehong nagpapakita ng Android 12 sa Mga Setting, at isa lamang sa kanila ang nagbubukas pa ng lumang IPsec XAuth profile na inaalok ng iyong gateway. Ang pagkakaiba ay hindi setting na maabot ng user: ang guard na humaharang sa native legacy na IKEv1 path ay tumitingin sa SDK level na kasama ng device, hindi lamang sa release na pinapatakbo nito ngayon. Ang isang detalyeng iyon ang nagtatakda kung may saysay ang paghahambing ng fleet, at nagtatakda rin kung alin sa tatlong landas ng migration ang talagang kailangan mo.

Dalawang teleponong Android 12 ay hindi isang test case

Ang pagbabago sa AOSP na pumigil sa mga bagong device na magbukas ng legacy IKEv1 profile ay naghahambing ng DEVICE_INITIAL_SDK_INT sa Android S, na API 31. Sa native legacy na startup path, ang karapat-dapat na profile ay naglalabas ng unsupported-operation failure bago pa man magkaroon ng anumang kapaki-pakinabang na koneksyon. Ang teleponong kasama ng Android 11 at na-update kalaunan ay pumapasa pa rin sa guard na iyon; ang modelong inilunsad kasama ng Android 12 ay hindi.

Mababasa mo ang dalawang numero sa device na may naka-enable na debugging:

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

Ang unang halaga ay ang launch level na pinapahalagahan ng guard, ang pangalawa ay ang pinapatakbo ng telepono ngayon. Kung wala ang property, umasa sa dokumentasyon ng suporta ng modelo sa halip na manghula mula sa pangalan sa marketing, at huwag ipagpalagay na pinapanatili ng vendor build ang bawat landas ng compatibility ng base release nito.

Isa pang pagkakaiba ang nagtitipid ng isang oras na nasayang na oras ng suporta: ang naka-save na profile na nakalista pa rin sa mga setting ng VPN ay walang pinapatunayan tungkol sa kung bubuksan ito ng platform. Ang muling pagpasok ng PSK o pag-edit ng ruta ay hindi makakapag-alis ng pagsusuri ng suporta sa protocol na tumatakbo nang mas maaga, at ang kabiguan ay mukhang problema sa credential kung hindi naman.

Landas isa: panatilihin ang native legacy stack kung saan tumatakbo pa ito

Ang legacy stack ang nagbabasa ng IPsec XAuth PSK, IPsec Hybrid RSA at L2TP/IPsec PSK na profile mula sa system VPN screen. Sa device na may mas mababa sa API 31, nananatili itong praktikal na landas pagkatapos ng upgrade, kaya ang pilot sa mas lumang handset ay maaaring magtagumpay habang ang bagong handset ay tumatanggi sa parehong profile.

Ang paghahambing na mahalaga ay ayon sa klase ng device, hindi ayon sa bersyon ng Android: ilista ang mga modelo sa fleet, basahin ang kanilang launch API level, at hatiin sa mga device na nagbubukas pa ng profile at mga device na hindi kaya. Anumang iba ay gumagawa ng patakaran sa suporta na sumasalungat sa sarili nito sa sandaling bumili ang user ng bagong telepono.

Landas dalawa: mga IKEv2 profile ng platform

Ang pampublikong modelo ng provisioning ng Android para sa IKEv2 ay ibang bagay, hindi pinangalanang muli na IKEv1 profile. Ang platform API para sa IKEv2 profile ay dumating kasama ng API 30 at inaasahan ang IKEv2 na may paraan ng authentication na inaalok ng gateway, kadalasan batay sa certificate o EAP. Walang wire-compatible na upgrade mula sa IKEv1 XAuth o Hybrid papuntang IKEv2: kailangang i-configure ang gateway para sa bagong protocol, at ang profile ay dapat magdala ng tugmang identity.

Ito ang landas na may pinakamahabang buhay, at ito rin ang naglalantad ng tunay na trabaho. Ang validation ng identity, authentication ng user, DNS, split-tunnel na ruta at authorization ng resource ay dapat lahat na makalampas sa migration; kung ang handshake lamang ang magtagumpay, mananatiling konektado ang mga user sa tunnel na walang naaabot.

Karaniwang dumadaan ang deployment sa isang MDM o managed configuration, hindi sa user na nagta-type ng mga field. Kung wala pa ang infrastructure na iyon, dapat isama ito ng plano sa migration, dahil ang manu-manong muling pagpasok ng IKEv2 profile sa bawat device ay hindi operasyong kayang absorbihin ng help desk.

Landas tatlo: isang client app ng third party

May mga VPN app na may sariling implementasyon ng protocol at hindi umaasa sa native legacy stack. Ginagawa silang lehitimong pansamantalang solusyon para sa fleet na hindi makakapag-migrate nang mabilis, ngunit lumilipat ang tanong ng compatibility sa app: kung ipinapatupad nito ang eksaktong IKEv1 mode na sinasalita ng iyong gateway, kasama ang authentication at cipher suite na hinihingi ng gateway.

Ituring na awtoridad ang sariling support matrix ng app at hindi ang paglalarawan sa tindahan, at subukan ang isang tunay na device laban sa tunay na gateway bago ito irekomenda. Ang pag-root ng telepono upang ibalik ang tinanggal na platform path ay hindi rin maintained na solusyon; inililipat nito ang problema sa isang unsupported na configuration na maaaring tahimik na sirain ng susunod na update ng system.

Pumili batay sa kayang ialok ng gateway

Lumiliit ang desisyon kapag alam mo ang dalawang bagay: aling mga device ang inilunsad sa API 31 o pagkatapos, at kung kayang magpakita ng IKEv2 service ang gateway na may parehong modelo ng enrollment. Kung kaya, mag-migrate at itigil ang pag-invest sa legacy profile. Kung hindi pa kaya, panatilihin ang IKEv1 para sa mga device na nagbubukas pa nito, at bigyan ang mga bagong device ng third-party client bilang dokumentado at may takdang-panahong exception sa halip na hindi sinasabing paraan.

Dalawang punto ang nagpapalakas ng depensa ng plano. Una, itala ang dahilan ng bawat exception kasama ang modelo at launch level, upang makita ng auditor na ang hangganan ay guard ng platform sa halip na isang kagustuhang hindi maipaliwanag. Pangalawa, ituring ang migration na planadong trabaho: ang IKEv1 ay deprecated sa standards track (RFC 9395), na nangangahulugang patuloy na liliit ang natitirang device at dapat ding mag-expire ang mga exception kasama nila.