アプリが Android や iOS で保存済み VPN プロファイルを有効にできない理由

まったく異なる二つの作業がプログラマティック VPN という名前でまとめられていますが、どちらか一方だけが、二つのモバイルプラットフォームのいずれでも普通のアプリに開放されています。一つ目はユーザーがすでに保存したプロファイルを有効にすること、二つ目は自前のプロセス内でトンネルを構築することです。Android は二つ目を VpnService で提供し、iOS は二つ目を Network Extension の権利で提供しますが、一つ目はシステム、デバイス所有者、または MDM サーバーの手元に残ります。実際にどちらが必要かを突き止めると、たいていプロジェクトは小さくなります。

同じ名前を持つ二つの作業

保存済みプロファイルの有効化とは、既存のトンネルに接続を立ち上げさせることです：ホスト、資格情報、プロトコルはすべて、ユーザーが見える場所ですでに設定されています。トンネルの構築とは、コードがインターフェース、パケットループ、プロトコルを所有することです。プロダクトバックログでは似て見えますが、実装はほとんど共有しません。

どちらのモバイルプラットフォームも、一つ目を SDK アプリに開放していません。ユーザーが何もしていないのに現れる接続はマルウェアと区別がつかないため、両システムとも通信を運ぶアプリの前に同意のゲートを置きます。

Android：同意のゲートがあり、プロファイル API はない

VpnService は Android 4.0 から存在し、アプリが tun インターフェースを作成してパケットを読み書きできるようにします。サービスは BIND_VPN_SERVICE で宣言する必要があり、VpnService.prepare() がユーザーに許可を求めるシステムダイアログを生成します。プラットフォームのサンプルである ToyVpn は、意図された形をもっとも明確に示しています：コードがインターフェースとそこを流れるすべてを所有するのです。

それがしないのは、システムの VPN 設定画面に項目を追加することです。そのための公開 API はなく、設定アプリはプロファイルを普通のアプリが届かない保存領域に置いています。通常のアプリから隠しクラスを呼ぶと、システムが決して一覧に載せないプロファイルが作られ、あるビルドで動いていたコードが次のビルドで黙って動かなくなるのはそのためです。

管理された経路は別です。デバイス所有者またはプロファイル所有者は、デバイスポリシー API を通じて常時接続の VPN パッケージを指定でき、企業向けツールはユーザーが後で承認するプロファイルを配布できます。これはデバイス管理の権限であり、アプリがインストール時に求める許可ではありません。顧客が組織ならこの経路を計画すべきで、顧客がストアからインストールする個人なら、これはまったく利用できません。

iOS：権利が境界になる

iOS は同じ作業を別の形で分割します。VPN クライアントは Network Extension フレームワークの下でパケットトンネルプロバイダまたはアプリプロキシを実装し、対応する権利を開発者アカウントに付与してもらう必要があります。NEVPNManager による個人 VPN 構成はより単純な場合のために存在し、同じ許可モデルの中で動きます。Apple はその全体を Network Extension リファレンス に文書化しており、作業範囲を決める前に読む価値があります。

VPN 設定画面を開いたり、ユーザーが保存した構成を読んだり、その一つを起動したりする、サポートされた方法はありません。クライアントにできるのは、ユーザーがインストールする構成プロファイルを配布し、その結果できたトンネルを通常のネットワーク呼び出しで使うことです。アプリごとのトンネルは MDM サーバーがオンデマンドルールで割り当てるもので、アプリが実行時に選ぶものではありません。

大手ベンダーの VPN クライアントは、あなたのアカウントが同じものを配布できる証拠にはなりません。それらの権利は開発者アカウントごとに申請して審査されるため、スケジュールのリスクは Apple 側にあり、あなたのスプリント計画にはありません。

デスクトップはもっと先へ届くが、所有権は変わらない

Windows は寛容な場合です。Add-VpnConnection は昇格した PowerShell セッションから電話帳の項目を作成し、rasdial がスクリプトから接続または切断します。アプリはベンダークライアントをその文書化されたコマンドラインで動かすこともできます。プロファイルの作成が依然として管理者操作なのは、項目がマシン全体の保存領域に住んでいるからです。

macOS も別の道具で同じように振る舞います。scutil --nc start と stop は既存のサービスに対して動作し、新しく作るのはシステム管理の作業です。ノート PC でプロセスを所有していても、構成の所有者にはなりません。

代わりに何を作るか

本当の要件がアプリから内部 API に届くことなら、ユーザーがすでに動かしているトンネルで足ります。通常の HTTPS リクエストを送り、経路はシステムに選ばせ、トンネルを制御しようとするのはやめてください。要件がアプリの通信だけをトンネルに通すことなら、管理チャネル経由でアプリごとの VPN を申請するか、それなしで到達できるサービスに対してアプリ内で TLS を終端してください。

隠し API は取る価値のある近道ではありません。リリースごとに変わり、アプリ審査で落ち、それが生む障害はコードを引き継いだ人には普通のネットワーク障害に見えます。比較すべきは Android 対 iOS ではなく、トンネルを所有することとプラットフォームに通信を経路選択させることの違いであり、あなたが作るべきは前者だけです。