Android の IKEv2 VPN プロファイルは端末単位ではなくユーザー単位

Android における「内蔵 VPN」という表現は、無関係な二つを指しています。プラットフォームがあなたに代わって動かすプロトコル実装と、製造元が表示すると決めた設定画面の形です。両者は同じ対象ではなく、どちらもトンネルがそれを必要とするアプリの利用者に属することを保証しません。作成は特定のユーザーと特定の呼び出しパッケージの組み合わせで行われ、その後のすべてはその文脈を引き継ぎます。設定画面を読む前に所有の連鎖を確認してください。

プラットフォームが用意するもの

Android 11 以降、プラットフォームは VpnManager を通じて VPN の作成を公開しています。承認されたアプリは IKEv2 プロファイルを記述し、IPsec と IKE の交換はプラットフォーム自身が実行するため、アプリがパケットに触れることはありません。これが、VpnService を実装して自プロセスでトンネルを構築する独自 VPN アプリとの本質的な違いです。

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

上の呼び出しは形の概略であり、そのまま貼り付けるブロックではありません。ビルダーには複数の認証手段があり、API レベルによって異なり、プロファイルはサーバー証明書の信頼情報も保持します。所有の議論で重要なのは、構文よりも狭い範囲です。

この設計から二つの性質が導かれます。プロファイルはデータなので、手入力ではなく管理者が作成できます。そしてトンネルはプラットフォームのネットワークなので、アプリからは VPN トランスポートを持つネットワークとして見え、他アプリのソケットとしては見えません。

所有者はまずユーザー、次にパッケージ

Android のマルチユーザーはラベルではなく実際の分離です。仕事用プロファイルは別のユーザーであり、独自のインストール済みパッケージ、アプリデータ、キーストア、信頼アンカーを持ちます。両方にインストールされた同じ製品は、起動アイコンと製品名が同じでも、ユーザー ID の異なる二つの実体です。

作成はそのユーザー内の呼び出しパッケージに対して記録されます。したがって個人プロファイルで動く作成アプリは個人用トンネルを作り、仕事用プロファイルの仕事用アプリはそれを一切見ません。逆も同じで、明示的に別段を定めるポリシーがなければ、仕事用プロファイルのトンネルは個人用アプリから見えません。

デバイスポリシーコントローラは管理対象プロファイルの代理として作成できます。社内で誰も作った覚えのない項目の説明はこれです。端末を監査するなら、灰色表示のプロファイルの所有者はおそらくそれであり、実験として削除するのはあなたの役目ではありません。

パケットが動く前の三つの関門

第一の関門は権限です。管理側が VPN 自体を許可している必要があり、配備によっては存在だけでなく種類も制限されます。第二は身元です。クライアント証明書や資格情報はプロファイルを所有するユーザーに存在しなければなりません。個人のキーストアに取り込んだ証明書は仕事用プロファイルから見えないからです。

第三は同意とポリシーです。利用者は通常、初回利用時に接続を承認し、管理者はさらに常時接続として固定でき、必要ならロックダウンを付けてトンネル外への通信を禁じられます。これらの設定がトンネル停止時の挙動を決め、そこが利用者の気づく部分です。

範囲は三つが出会う場所です。プロファイルがゲートウェイと身元を決め、ポリシー層がどのアプリにトンネルの使用を許すか、通信を強制的に通すかを決めます。同じゲートウェイアドレスの二台でも挙動が大きく異なり得るのはこのためです。

個人の接続が仕事用アプリを覆わない理由

仕事用アプリの通信は仕事用ユーザーで生成され、適用されるネットワークポリシーはそのユーザーのものです。個人プロファイルで確立したトンネルはそれを運びません。表示がどれほど正常に見えても同じです。この一事実が、VPN は接続済みだと利用者が断言するのに特定のアプリだけ社内サービスに届かない、という報告の大半を説明します。

名前解決も同じ境界に従います。プライベート DNS サフィックスと信頼アンカーはユーザーごとなので、個人プロファイルで解決する社内ホスト名が、同等に見えるトンネルがあっても仕事用プロファイルで失敗することがあります。リゾルバのポリシーと CA ストアが別の対象だからです。

実験用の端末ではなく、実際の登録で検証する

端末上でまず項目の所有者を特定します。どのユーザー、どのパッケージ、そしてプロファイルがプラットフォームの作成機能から来たのか、独自の VPN サービスを実装するアプリから来たのか。次に、プロファイルが期待する身元がそのユーザーのキーストアに実際にあることを確認します。

接続だけでなくライフサイクルを試します。サインインし、資格情報ストアを解錠し、仕事用プロファイルを夜のあいだ停止させ、戻してから手動操作なしにトンネルが復帰するか確認します。勤務時間後に切れる仕事用プロファイルはトンネルも連れて行きますが、これは不具合ではなく想定された挙動です。ただし想定される利用不可状態が文書化されている場合に限ります。

最後に、仕事用アプリ自体を既知の社内エンドポイントに対して試し、個人プロファイルの結果と比較します。両者が異なることは許されますが、異なってはならないのは所有のモデルです。トンネルが誤ったユーザーに属するなら、証明書を再発行しても直りません。

メニューを出すために隠し設定アクティビティを起動して強行せず、接続が見えるようにプロファイル間で秘密鍵をコピーしないでください。VpnManager のリファレンスは呼び出し側が作成できる範囲を記述しています。承認された経路があなたの事例を含まないなら、それは設定の問題ではなく管理者の判断です。