Android 12 と IKEv1 VPN：出荷時の SDK レベル、IKEv2、サードパーティ製アプリ

二台のスマートフォンはどちらも設定に Android 12 と表示されますが、ゲートウェイが提供する古い IPsec XAuth プロファイルを起動できるのは片方だけです。違いはユーザーが触れる設定ではありません。ネイティブの IKEv1 経路を制御するガードは、端末が出荷されたときの SDK レベルを見ており、現在実行しているバージョンだけを見ているわけではありません。この一点が、フリート比較に意味があるかどうか、そして三つの移行経路のどれが本当に必要かを決めます。

二台の Android 12 端末は同じ試験条件ではない

新しい端末が古い IKEv1 プロファイルを起動できなくなった AOSP の変更は、DEVICE_INITIAL_SDK_INT を Android S、つまり API 31 と比較します。ネイティブの起動経路では、条件を満たすプロファイルは有用な接続ができる前に未サポート操作の失敗を発生させます。Android 11 で出荷され後に更新された端末はこのガードを通過しますが、Android 12 で登場したモデルは通過しません。

デバッグを有効にした端末で二つの数値を読めます。

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

最初の値がガードの見る出荷時レベル、二番目が今日端末が実行しているレベルです。プロパティが存在しない場合は、マーケティング名から推測せずモデルのサポート文書に当たってください。また、製造元のビルドが基本リリースの互換経路をすべて保持していると仮定しないでください。

もう一つの区別が一時間の無駄なサポート時間を節約します。VPN 設定にまだ表示されている保存済みプロファイルは、プラットフォームがそれを起動するかどうかを何も証明しません。PSK の再入力やルートの編集では、より早く実行されるプロトコル対応チェックを外せません。障害は認証情報の問題に見えますが、そうではありません。

経路その一：まだ動く場所でネイティブスタックを維持する

古いスタックとは、システムの VPN 画面から IPsec XAuth PSK、IPsec Hybrid RSA、L2TP/IPsec PSK プロファイルを読むものです。API 31 未満で出荷された端末では、更新後も有効な経路として残ります。だからこそ古い端末での試験は成功し、新しい端末では同じプロファイルを起動できないことがあります。

重要な比較は Android のバージョン別ではなく端末クラス別です。フリート内のモデルを列挙し、出荷時の API レベルを読み、プロファイルをまだ起動できる端末とできない端末に分けてください。それ以外のやり方は、ユーザーが新しい端末を買った瞬間に自己矛盾するサポート方針を生みます。

経路その二：プラットフォームの IKEv2 プロファイル

IKEv2 に関する Android の公開プロビジョニングモデルは別のオブジェクトであり、名前を変えた IKEv1 プロファイルではありません。IKEv2 プロファイルのプラットフォーム API は API 30 で登場し、ゲートウェイが提供する認証方式、通常は証明書ベースか EAP を伴う IKEv2 を想定しています。IKEv1 XAuth や Hybrid から IKEv2 へのワイヤ互換のアップグレードはありません。ゲートウェイを新しいプロトコル用に設定し、プロファイルが対応する識別情報を持つ必要があります。

これが最も寿命の長い経路であり、実際の作業を明らかにする経路でもあります。識別情報の検証、ユーザー認証、DNS、スプリットトンネルのルート、リソース認可のすべてが移行を生き延びなければなりません。ハンドシェイクだけ成功させても、どこにも届かないトンネルにユーザーをつなぎ止めるだけです。

展開は通常、ユーザーが項目を入力するのではなく、MDM や管理された構成を通じて行います。その基盤がまだない場合、移行計画に含める必要があります。すべての端末で IKEv2 プロファイルを手入力し直すのは、ヘルプデスクが吸収できる作業ではないからです。

経路その三：サードパーティ製クライアントアプリ

一部の VPN アプリは独自のプロトコル実装を搭載し、ネイティブスタックにまったく依存しません。そのため急速に移行できないフリートにとって正当な一時しのぎになりますが、互換性の問いはアプリに移ります。ゲートウェイが話す IKEv1 モードを正確に実装しているか、ゲートウェイが要求する認証と暗号スイートを備えているかです。

ストアの説明ではなくアプリ自身のサポートマトリクスを根拠とし、推奨する前に実機を実際のゲートウェイに対して試してください。削除されたプラットフォーム経路を取り戻すために端末を root 化するのも維持された解決策ではありません。次のシステム更新で静かに壊れうる非サポート構成に問題を移すだけです。

ゲートウェイが提供できるものから選ぶ

二つのことが分かれば判断は絞られます。どの端末が API 31 以降で登場したか、そしてゲートウェイが同じ登録モデルで IKEv2 サービスを提供できるかです。できるなら移行し、古いプロファイルへの投資をやめてください。まだできないなら、まだ起動できる端末には IKEv1 を残し、新しい端末にはサードパーティ製クライアントを文書化された期間限定の例外として与えてください。暗黙の回避策にしてはいけません。

二つの点が計画を擁護可能にします。第一に、各例外の理由をモデルと出荷時レベルとともに記録し、監査人がその境界を説明のない好みではなくプラットフォームのガードだと分かるようにします。第二に、移行を計画された作業として扱います。IKEv1 は標準の流れで非推奨であり（RFC 9395）、残る端末は減り続け、例外もそれに合わせて期限切れになるべきです。