iPhone IKEv2 から RouterOS へ：どの識別子をどこに置くか

MikroTik ゲートウェイに到達できても、IKEv2 導入の輸送半分が片付くだけで、それ以上ではありません。そのあと、トンネルが成立するかどうかは四つの別々の主張で決まります。電話がダイヤルするアドレス、期待するサーバー識別子、自分が名乗る識別子、そしてその主張を裏付ける証明書の材料です。この順序で確認し、ゲートウェイが提示する内容と食い違う最初の項目で止めてください。それぞれ編集する場所が違うため、誤った編集はたいてい障害を直すのではなく移動させます。

プロファイルの各項目を、交換が使う順序で確認する

リモートアドレスは最初の IKE パケットの宛先であり、それ以上の意味はありません。リモート識別子は、電話がゲートウェイに対して証明を期待する相手であり、経路ではなく名前です。両方に同じホスト名を入れるのは、ゲートウェイの証明書がその名前を持つ場合だけ機能し、持たない場合は経路の問題に見える形で失敗します。プロファイルは記入する項目の一覧ではなく、主張の連なりとして読んでください。

ローカル識別子は電話自身の主張であり、電話が提示するクライアント証明書に対して RouterOS の識別子エントリが受け入れる名前でなければなりません。両者が食い違うと、証明書自体の検証が通ったあとでゲートウェイが接続を拒否し、ログは命名の問題ではなく認可の問題のように見えます。

識別子を、ゲートウェイが提示する内容と突き合わせる

証明書認証向けに構成された RouterOS のピアエントリは自分の証明書を提示し、別段の設定をしていなければその識別子は証明書から取られます。電話のリモート識別子がゲートウェイの DNS 名を指定するなら、ゲートウェイの証明書にはその名前が、電話が受け入れる場所、通常はサブジェクト代替名に必要です。別のコモンネームで発行された証明書は、鍵とチェーンが完璧でも検証に通りません。

管理対象の Apple プロファイルは、識別子の項目に加えて評価される証明書名の制約を持つこともあります。設定画面の表示から検証名を推測するのではなく、ペイロードを確認してください。両者は同じ設定ではありません。

クライアント証明書が鍵であり、信頼のアンカーだけではないことを確認する

CA 証明書を取り込むと、電話はゲートウェイを検証する手段を得ます。しかしクライアント識別子は得られません。証明書認証にはクライアントのリーフ証明書とその秘密鍵を、承認された登録経路で一緒に届ける必要があります。秘密鍵なしで作った PKCS#12 は、きれいにインストールされて何も認証しないプロファイルになります。

クライアントのリーフには、RouterOS 側が期待する識別子も必要です。つまりサブジェクトまたはサブジェクト代替名が、対応する識別子の設定と一致していなければなりません。同じ CA からクライアントとサーバーの証明書を発行するとチェーンは便利になりますが、二つのリーフが交換可能になるわけではありません。

RouterOS のポリシーがその名前を受け入れることを確認する

ゲートウェイでは、ピアエントリが交換モードと認証方式を設定し、識別子エントリが受け入れるリモート識別子を証明書と後続のポリシーに結び付けます。RouterOS v7 ではこの組は IPsec のピアと識別子のエントリで表され、たとえば auth-method=digital-signature を伴う IKEv2 ピアです。古い版向けに書かれた手順ではなく、導入済みの版の実際のメニュー内容を確認してください。

ここは不一致を最も安く直せる場所でもあります。ゲートウェイは受け取った識別子と欲しかった識別子の両方を教えてくれるからです。エラーを黙らせるために受け入れる識別子を広げると、導入に意味を与えていた結び付きが失われます。

何かを編集する前に、どの段階で失敗したかを確認する

両端で試行を読み、提案を変える前に分類してください。提案の不一致、署名鍵の欠落、信頼できない発行者、誤ったピア識別子、拒否されたクライアント認可は、どれも電話側からは死んだトンネルに見え、それぞれ担当が違います。五つの設定を一度に変えれば、結果から何も学べないことが確実になります。

提示された識別子、期待する識別子、証明書の発行者とシリアル番号、該当するポリシー名を記録し、秘密鍵とプロファイルの機密はその記録の外に置きます。認証が通ったら、プライベートなサービスとその応答を試すべきです。IKE の交換が終わっても、アドレス割り当て、セレクタ、DNS、アクセス ポリシーはまだ機能している必要があるからです。