先週、同僚が iPhone を差し出してきました。設定には VPN の項目が二つあり、ひとつはプロバイダーのアプリが残したもの、もうひとつはサポートページから貼り付けた IKEv2 プロファイルによるものでした。同じものの競合する二つのバージョンではありません。プロバイダーのアプリは独自のトンネルコードを持ち込めるコンテナであり、Apple の内蔵クライアントは手動またはプロファイルで構成する IKEv2 クライアントです。プロトコル、資格情報の扱い、デバイス管理、復旧が選択を決めます。

アプリとネイティブクライアントは別の層にある

Apple の内蔵 VPN クライアントは実質的に IKEv2 クライアントです。手動フォームには今も非推奨の IPsec 上の L2TP と Cisco IPsec の選択肢が並びますが、ベンダー独自トランスポートの欄も、OpenVPN や WireGuard の構成を貼る場所もなく、「設定 > 一般 > VPN & デバイス管理」でフォームに入力するか、VPN ペイロードを含むプロファイルを読み込むかです。画面にあるのはサーバーアドレス、二つの識別子、認証方法、任意のオンデマンドルールだけです。

プロバイダーのアプリは一層上で動きます。Network Extension のパケットトンネルプロバイダーを同梱するため、プロトコルのコードとルーティングの論理はアプリ側にあり、iOS はパケットを通過させるだけです。WireGuard や OpenVPN を実装するアプリもあれば、独自の難読化トランスポートを実装するものもあり、少数は IKEv2 プロファイルをインストールするだけで、より見栄えのよい画面からネイティブクライアントを操作します。最後のグループのせいで、アプリかプロファイルかという選択がときに偽の二択になります。

結果は実務的で、.ovpn や WireGuard のファイルは、ハンドシェイクが別のプロトコルであるためこれらの欄の代わりにはなりません。

機能を比べる前にペイロードを読む

プロファイルが IKEv2 の場合、ペイロードのキーはどんな機能比較よりも多くの障害を説明します。Apple の IKEv2 設定リファレンス が各キーを説明しており、省略したペイロードは次のとおりです:

<key>VPNType</key><string>IKEv2</string>
<key>RemoteAddress</key><string>vpn.example.net</string>
<key>RemoteIdentifier</key><string>vpn.example.net</string>
<key>LocalIdentifier</key><string>[email protected]</string>
<key>AuthenticationMethod</key><string>Certificate</string>
<key>ServerCertificateIssuerCommonName</key><string>Example Issuing CA</string>

診断の重みの大半を三つのフィールドが担います。RemoteIdentifier はクライアントがサーバーに提示を期待する名前で、NAT の背後にあるゲートウェイや、証明書がアドレスではなくプールを名指すロードバランサーは、アドレスが正しくても失敗します。LocalIdentifier はサーバーが考えるあなたの身元で、証明書認証ではアカウントに紐づく識別子と一致しなければなりません。ServerCertificateIssuerCommonName は発行 CA を固定するため、証明書が再発行された日にプロファイルが失敗することがあり、そのエラーメッセージに証明書の話は出てきません。

もし AuthenticationMethod が SharedSecret なら、サーバーは EAP ユーザー認証を行っており、渡されたシークレットは実質的にアカウントの資格情報です。プロバイダーが二通の文書、つまりユーザー名とパスワード用と証明書用を送り、読み込んだ内容に合うのが片方だけのときに重要になります。

アプリにできてネイティブクライアントにできないこと

プロトコルの選択が明らかな利点です。サーバーが WireGuard や OpenVPN を話すなら、アプリがそれを使える唯一の iOS クライアントであり、ネイティブフォームを編集してもネゴシエートされません。アプリはほかに、宛先別やアプリ別の分割トンネリング、独自の DNS 処理、キルスイッチ風の遮断、サーバー選択、自前のネットワークに合わせた再接続を実装できます。

代償は、監査していないソフトウェアがネットワーク拡張の権限で動くことです。品質のばらつきはストアの説明以上です。あるアプリはきれいに再接続する一方、別のアプリはネットワーク変更後に数秒間漏れ、アプリ内のキルスイッチはそのアプリの機能であって iOS の機能ではありません。管理対象デバイスでは、まず承認済みリストを確認してください。

ネイティブ IKEv2 プロファイルの利点

可動部品が少ないことがすべての論拠です。IKEv2 クライアントとその IPsec スタックは OS に付属するため、クラッシュする拡張も、生かしておくアプリ別プロセスも、あなたと動作するトンネルの間のサードパーティ更新サイクルもありません。プロファイルはロックもできます。監督下のデバイスでは、ユーザーは管理側がインストールしたものを削除できず、ユーザー操作なしでどのネットワークでも再接続する Always On VPN は、その監督下でプロファイル管理された形にしか存在しません。

ネイティブの道が与えないのは柔軟性です。管理対象アプリなしのアプリ別 VPN も、ユーザー向けキルスイッチも、IPsec を遮断するネットワークで HTTPS に見えるトランスポートもありません。UDP 500 と 4500 を落とすホテルのネットワークでは、ネイティブ IKEv2 に代替手段はありません。

ほとんどのケースを決める判断表

実際には、機能が問題になる前にプロトコルの問いがほとんどのケースを決めます。

What you were givenDevice situationWhat to use
An .ovpn or WireGuard configPersonal phoneProvider app; the native form cannot load it
IKEv2 host plus CA namePersonal or managedProfile, or the app's own IKEv2 mode
IKEv2 with username and secretPersonal phoneEither; the profile is simpler if you never switch servers
A management-installed profileSupervised, MDMNative client; do not add a second app entry
A per-app tunnelling requirementPersonal phoneApp, or accept a full tunnel; iOS cannot split by app without management
IPsec blocked on your main networkAnyApp with a transport that survives the block

二行は二度見する価値があります。個人の電話でのアプリ別要件は、人が読み違えるケースです。 設定は iOS に存在しますが、管理側が動かしていますそのため管理されていないデバイスでは提供されません。ネットワークが遮断されていることは IKEv2 を疑う理由ではなく、プロバイダーのアプリが存在する理由です。

一度のテストで選択を検証する

接続ボタンではなく、失敗の仕方を試します。一度接続し、VPN インジケーターが出ることを確認してから、公共アドレスを返すページを開いて前のものと比べます。VPN に触れずに Wi-Fi からモバイル通信へ切り替えて再接続を待ち、次に機内モードを通します。再起動してトンネルがひとりでに戻るか見ます。OnDemandEnabled を含むプロファイルなら戻るはずで、多くのアプリは先に開く必要があります。

戻らないときは、トンネルが存在するかどうかで故障を分けます。VPN インジケーターがなければトンネルは一度も上がっていません。RemoteIdentifier、固定した CA、資格情報のいずれかでハンドシェイクが失敗したか、オンデマンドルールが一致せずどのアプリも接続を開始しなかったかです。インジケーターがあって通信が失敗するなら、ルーティング、DNS、サーバー側ポリシーの問題で、クライアントの再インストールはどれにも触れません。

次の人がデバイスを理解できるようにする短いリスト:

  • VPN の項目は一つだけ、二つではない;
  • プロファイルやアプリは接続先サーバーの名前を付ける;
  • 識別子の値は見つけられる場所に書き留める。

表のプロトコルの行から始め、それで答えが出るならそこで止めます。

関連記事