AndroidからVPNプロファイルをエクスポートする操作はバックアップの一手に見えますが、そのメニューはその印象を正すことは何もしてくれません。手元に残るのはパーサーへの入力、OSが二度と返さないかもしれない鍵、そしてその端末に発行された認可です。この三つを分けて考えると、有用な問いが浮かびます。新しい端末にまだ欠けているのはどの部分でしょうか。

ファイルは簡単な部分です。残る二つが移行の成否を決めます。

エクスポートしたプロファイルに実際に含まれるもの

信頼する前にテキストエディタでファイルを開いてください。OpenVPNプロファイルは小さな設定言語です。remote、proto、data-ciphers、そして多くの場合、クライアントがTLSスタックに渡すインラインの<ca>、<cert>、<key>、<tls-crypt>ブロックが含まれます。WireGuardの設定はより平坦で、[Interface]がPrivateKeyとAddressを保持し、続いてエンドポイントごとに一つの[Peer]がPublicKey、AllowedIPs、Endpointを持ちます。IKEv2は鍵ブロックの代わりにペイロード辞書を伴う.mobileconfigとして届きます。

これらのテキストはどれも単独では資格情報ではありません。資格情報は秘密鍵であり、どの形式もそれをインラインに貼るか、作成したクライアントの内部でしか解決されないエイリアスを指します。

Androidで鍵が実際に住む場所

Androidはアプリのデータを/data/data/<package>の下に置き、そのアプリのUIDだけが読めます。root化していない端末から別アプリのプライベートディレクトリをコピーする公式な方法はなく、Android 12が非推奨にしてクライアントがallowBackup="false"を宣言し始めてから、adb backupは一般的な答えではなくなりました。つまりAndroidクライアントからのエクスポートは、そのクライアントが実装しているものの意味であり、ファイルシステムのコピーではありません。

IDの層はアプリの下にあります。クライアントが鍵をAndroid Keystoreに取り込んだ場合、素材はそこで生成またはラップされ、後のエクスポートはバイトではなくKeystoreのエイリアスへの参照を持つことがあります。ハードウェア保護の鍵は、所有するアプリでさえ読み出せないように作られており、Keystore documentationが説明するとおりです。そのためそのエイリアスを指すプロファイルは同じ端末ではきれいに取り込め、他のどこでも失敗します。

それは壊れたエクスポートではありません。プラットフォームに求められた性質そのものです。

プロファイルが持ち運べないもの

移行先が受け入れるものとオブジェクトを突き合わせます。

オブジェクト移るか理由
プロトコルとエンドポイントはい、移行先のクライアントが対応していればプロファイル内の平文
CA証明書とホスト名の検証通常は移る公開情報だが、ホスト名は証明書と一致している必要がある
クライアント証明書はい、端末ごとに紐付けられていなければ証明書は持ち運べる。何台で使えるかは発行元が決める
秘密鍵Keystoreの外で生成した場合のみハードウェア保護の鍵はエクスポートできず、交換しかできない
アカウント、MFA、SSOセッションいいえトークンは失効し、取得した端末に紐付いたままになる
ルート、DNS、アプリの範囲設定テキストとしてのみAndroidは接続時にVpnService.Builderを通じて適用する
スプリットトンネルのアプリ一覧ほとんど移らないパッケージ名は端末ごとに異なり、一覧はクライアントの状態である

混乱の多くは二つの行から生じます。端末で生成されエクスポート不可とされた鍵はアプリデータとともに本当に消えるため、代替は新しい鍵とそれに対して発行された証明書です。新しい端末にコピーしたセッショントークンは通常、最初の更新で死に、それは取り込み失敗のように見えます。

取り込みは解析であり、その後に同意の確認が続く

受け取る側では、取り込みは解析の後にコミットが続きます。クライアントは設定を読み、参照されたすべてのブロックが存在することを確認し、トンネル定義を自分のサンドボックスに書き込みます。だからダウンロードから選んだファイルが、その後接続するものではないのです。

次に、どのファイルも飛ばせない認可の段階があります。Androidはトンネルを確立する前にアプリがVpnService.prepare()を呼び、あなたの同意を得ることを要求するため、取り込んだばかりのプロファイルでもシステムダイアログが一度は表示されます。その後トンネルはaddAddress、addRoute、addDnsServer、そしてアプリ単位のルーティングにはaddAllowedApplicationまたはaddDisallowedApplicationによって明示的に構築されます。これらはいずれもエンドポイントから導かれるものではないため、同じプロファイルでも二つのクライアントで異なる実効ルート集合になり得ます。

証明書ベースの構成はもう一つの分岐を加えます。サーバーが特定の端末に証明書を発行する場合、MDMやSCEPの登録がそうするように、二台目の端末での再利用は、サーバーがIDごとに一つのセッションを強制するまで機能するか、TLSハンドシェイクで失敗します。再利用を計画する前に発行元のポリシーを確認してください。

古い端末を退役させる前に新しい端末を検証する

新しい端末が緑のアイコンよりましな何かに合格するまで、古い端末は接続したままにします。新しい端末からの出口アドレスと、実際に使ったDNSリゾルバーを確認します。split tunnelingが重要なら、トンネルを迂回すべきアプリとそうでないアプリを起動し、どちらがプロバイダーに届くかを見ます。

一つの確認で出口アドレスは決まります。端末のブラウザでhttps://ifconfig.meを開き、同じWi-Fi上のノートPCからcurl -s https://ifconfig.meを実行し、両方の答えをプロバイダーが割り当てたアドレスと比べます。

それから初めて古いIDを退役させ、それは発行元を通じて行います。証明書を失効させるか、アカウントから端末を外します。ダウンロードからファイルを消しても何も終わりません。同じ証明書を持つ二台の端末はサーバーログで同じに見えるからです。

エクスポートが持ち運べないと分かった場合、解決策は公開設定バンドルではなく新規登録です。二台目の端末用プロファイルを頼むか、新しい端末で鍵ペアを生成してCSRを提出します。遅い方法ですが、発行元が支持する道です。

何かを消す前にチェックリストを実行します。新しい端末が接続する、出口アドレスとDNSが一致する、アプリ単位の範囲が意図どおり、古いIDが失効している、保存した設定ファイルが暗号化ストレージにある。

関連記事