iPhone の VPN の Remote ID：この欄が実際に意味するもの
Remote ID はサーバーが iPhone に証明すべき身元、Local ID はクライアントが主張する身元です。どちらの欄にどの文字列を入れるかを説明します。
設定で IKEv2 構成を追加していると、二つの欄が誰も渡していない文字列を求めます。Remote ID と Local ID です。どちらもユーザー名ではなく、どちらも Server 欄の二つ目の写しでもありません。Remote ID はゲートウェイがあなたの iPhone に証明すべき身元、Local ID はあなたの iPhone がゲートウェイに主張する身元です。どちらかを間違えると、サーバーがすでに応答したあとでトンネルが切れます。だからこの失敗はパスワードの問題に見えて、実際はそうではありません。
iOS で欄がどこにあるか
設定 > 一般 > VPN とデバイス管理 > VPN を開き、IKEv2 構成を追加します。認証の下でユーザー名か証明書を選ぶと、そのとき初めて Remote ID と Local ID が自由入力欄として現れます。これらは識別子であり、アドレスではありません。iOS はこれらを IKE_AUTH の交換で運び、そこでは IKEv2 が開始側の身元を IDi、応答側の身元を IDr と呼びます。
保存すると iOS は構成を一行にまとめ、値を表示しなくなります。欄が空だと結論づける前に、情報ボタンを押すかプロファイルを開き直してください。MDM から配布された構成では欄が完全に灰色になることがあり、その場合は誰が直せるかが変わります。
Remote ID はゲートウェイの名前
これはあなたの iPhone がサーバーに証明を求める値です。証明書認証では サーバー証明書の名前と比較され、通常は subject か subjectAltName の項目です。証明書が vpn.example.com に対して発行されているなら、そのホスト名が Remote ID です。裸の IP アドレスで機械に到達している場合でも同じです。
この不一致が典型的な失敗です。パケットは届き、サーバーも応答するのに、証明書の身元がプロファイルの要求と一致しないため接続は崩れます。Server 欄を生の IP に向けても解決せず、多くのゲートウェイでは一致できない身元への応答をサーバーが単にやめます。
ゲートウェイ側にも対応する設定があります。strongSwan サーバーは leftid で自分の身元を送り、rightid でクライアントの身元を制限できます。両側で文字列が食い違えば IKE_AUTH は双方向で失敗します。ブラウザーのアドレス欄から URL を写すのではなく、証明書がどの身元に対して発行されたかを運用者に確認してください。
Apple はペイロードのキーを RemoteIdentifier と LocalIdentifier として IKEv2 設定のリファレンスに記載しています。どちらも単なる文字列なので、大文字小文字や末尾の空白が影響することがあります。
Local ID は iPhone が主張するもの
ユーザー名認証では EAP が名前とパスワードを確認し、Local ID は一部のゲートウェイがさらに強制する別個の IKE 身元です。ゲートウェイは Local ID がユーザー名と等しいこと、メールアドレスであること、接続ポリシーの項目と一致することを求める場合があり、無視するものもあります。空のままにして安全なのは運用者がそう言ったときだけです。
証明書認証では、Local ID はゲートウェイがそのクライアント証明書に対して受け入れる身元と一致すべきで、多くの場合証明書のコモンネームか、デバイス記録に対応づけられた値です。同僚のプロファイルをコピーすると相手の身元もコピーされます。最良でもゲートウェイは誤った機器を記録し、最悪では機器ごとのポリシーがあなたを拒否します。
罠は、空欄が身元なしを意味すると決めつけることです。未完成に見えるからといって、空欄を自分のメールアドレスで埋めないでください。意図された値を確認し、渡されたとおりに正確に入力してください。
保存前の五分間チェック
順番に進め、最初に失敗した手順を直してください。
- 運用者からサーバー証明書の名前、想定される Local ID、認証方式の三つを得ます。
- 認証方式を合わせます。Remote ID と Local ID はユーザー名とパスワードの代わりにはならず、証明書プロファイルはパスワードを受け付けません。
- 大文字小文字を含め、末尾に空白を入れずに値を正確に入力します。
- 証明書の検証は有効なままにします。警告を黙らせるために無関係なルート証明書を入れるのは、名前の不一致を隠すだけで直しません。
- キャプティブポータルや分割 DNS が身元の問題に見えないよう、事務所の Wi-Fi ではなくモバイルデータで試してください。
| Field | What belongs there | What a wrong value looks like |
|---|---|---|
| Remote ID | The DNS name in the gateway certificate | Server answers, then the tunnel drops with a certificate or identity error |
| Local ID | The identity the gateway policy expects for you | IKE_AUTH or user authentication fails after the server responds |
| Server | A reachable hostname or IP | Timeout with no identity exchange at all |
表は上から読んでください。Server の行でタイムアウトするなら、身元の欄は一度も試されていません。そこで止めます。サーバーの応答後にだけ現れるエラーは、ほぼ常に Remote ID か Local ID の不一致です。
間違った欄を指すエラー
"User authentication failed" のようなメッセージは資格情報か EAP の話で、Remote ID ではありません。証明書の警告は証明書の名前の話で、そこが Remote ID と Server 欄の接点です。"The VPN server did not respond" は通常、UDP 500 と 4500 が完了しなかった、または NAT 越えが失敗したという意味で、身元は一度も比較されていません。
ゲートウェイ側では身元の失敗は違って見え、IKE_AUTH の途中でピアが拒否されるか、ログがクライアントの送った ID を示してどの接続にも一致しないと述べます。そのログ行が議論を決着させる最短の方法です。電話が送った正確な文字列が示されるからです。
パスワードを再設定しても想定されたサーバー身元は直らず、Remote ID を変えても誤ったパスワードは直りません。まず段階を切り分け、その段階に属する欄を編集してください。
プロファイルが管理されている場合
欄が灰色なら構成は MDM から来ています。電話は直す場所ではありません。VPN ペイロードが識別子を運ぶので、正しい変更は管理サーバー上のプロファイルにあり、そのあと端末に再インストールします。
設定 > 一般 > VPN とデバイス管理で、プロファイルが管理されているか、誰が署名したかを確認します。削除できないなら識別子をローカルで編集できません。二つ目のローカルプロファイルを作ると、競合する構成が増えるだけです。
設定を閉じる前に、入力した三つの文字列とその出所を書き留めてください。次にトンネルが失敗したら、ゲートウェイのログが受け取った ID をそのメモと比べます。違っていれば、見ているのはパスワードではなく欄です。