IKEv2プロファイルが定義済みで未接続: 連鎖をたどる

保存されたIKEv2プロファイルはオブジェクトであり、経路ではありません。フェーズ2をデバッグする前に、キーリング、プロファイル、crypto mapまたはIPsecプロファイル、インターフェースへの接続を順にたどってください。

IKEv2プロファイルは保存済みコンフィギュレーションにあり、キーリングもそこにありますが、トンネルは上がりません。Cisco IOS XEでは、プロファイルはIDマッチングと認証の選択肢を運ぶオブジェクトであり、別のオブジェクトがそれを参照し、インターフェースがそのオブジェクトを経路に接続するまで、オブジェクトは何も行いません。失敗したフェーズ1のデバッグの多くは、この参照のどれか一つを飛ばしています。提案やポリシーを変更する前に、キーリングから外側へ連鎖を読んでください。

プロファイルオブジェクトとは何か

IKEv2プロファイルは、リモートIDのマッチング、ローカルとリモートの認証方式、および事前共有キー方式のためのキーリングへの参照を保持します。ピアがどう識別され、どう自身を証明するかを記述し、インターフェースを名指ししません。

キーリングは事前共有キーを保持する別のオブジェクトです。crypto mapまたはIPsecプロファイルは、IKEv2プロファイルを参照して保護設定を提供する三番目のオブジェクトです。インターフェースへの接続は四番目の手順で、ここでcrypto mapが適用されるか、トンネル保護が有効になります。各ホップは独立した参照であり、一つ欠けると、どのオブジェクトも単体では正しく見えます。

参照の連鎖を順にたどる

プロファイルが名指しするキーリングから始め、次にcrypto mapまたはIPsecプロファイルが参照するプロファイル名を確認し、最後にそのオブジェクトを使うインターフェースを見つけます。各名前を使うオブジェクトの横に書き出してください。この短い一覧は、期待する設定ブロックがコンフィギュレーションのどこかにあるかを確認するより役立ちます。

よくある破綻は機械的です。プロファイル名がcrypto mapの参照する名前と一文字違う。crypto mapは存在するがインターフェースに適用されていない。tunnel protectionコマンドが別のIKEv2プロファイルを参照するIPsecプロファイルを指している。明示的な接続のないresponderは文書化されたケースですが、接続のないinitiatorはそもそもその経路向けに設定されていません。

crypto ikev2 keyring KR-SITE
 peer SITE-B
  address 203.0.113.9
crypto ikev2 profile IKEV2-SITE
 match identity remote address 203.0.113.9 255.255.255.255
 keyring local KR-SITE
crypto ipsec profile IPSEC-SITE
 set ikev2-profile IKEV2-SITE
interface Tunnel100
 tunnel protection ipsec profile IPSEC-SITE

この抜粋はテンプレートではなく連鎖として読んでください。インターフェースがIPsecプロファイルを名指しし、IPsecプロファイルがIKEv2プロファイルを名指しし、IKEv2プロファイルがキーリングを名指しします。どれか一つの名前を壊してもコンフィギュレーションは解析されるため、ルーターは受け入れ、トンネルは上がらないままです。

crypto mapとトンネル保護は選択肢

Ciscoは二つの接続方式を文書化しています。crypto mapはインターフェースに適用でき、setコマンドでIKEv2プロファイルを参照できます。トンネル保護はIPsecプロファイルをトンネルインターフェースに接続します。どちらも有効で、二重の保険として併用するためのものではありません。

トンネルの送信元と宛先は外側の配送方式を決めるもので、保護の接続とは別です。LANインターフェース、トンネルインターフェース、外側の送信元インターフェースは三つの異なる役割を担います。LANインターフェースのcrypto mapはトンネルを保護せず、保護が有効でも到達可能な送信元アドレスがないトンネルはピアにパケットを送りません。

テキストだけでなく、ロード済みの状態を確認してください。インストールされたリリースには、設定済みオブジェクトをネゴシエート済みセッションに結び付けるコマンドがあり、チケットにはそれを引用します。 保存されたコンフィギュレーションは意図を証明する；セッションテーブルは経路を証明する。

responderの例外はinitiatorの規則ではない

IOS XEのガイドは、responderでは明示的なIKEv2プロファイルの接続が任意になり得ると述べています。その例外は認証やIDの確認をなくすものではなく、接続を開始する側でプロファイルが任意になるわけでもありません。

ルーターが開始するなら、接続を必須として端から端までたどってください。ルーターが応答するだけなら、どのプロファイルが実際に受信ピアと一致したかを確認してください。responderはインターフェース参照ではなくIDでプロファイルを選べるからです。

保存された設定ではなく経路を確認する

接続が揃ったら、許可されたアプリケーションを一つ試し、その内側の送信元、宛先、経路を記録します。ルーターが起こした要求は、LANから転送されるトラフィックと異なる送信元アドレスを使うことがあり、保護範囲はその一方しか覆わないかもしれません。

正しく接続された定義は、セレクタ、戻り経路、インターフェースポリシーがフローを覆っていることを証明しません。実際のトラフィックを送ってネゴシエート済みの状態を読み、再接続後にも繰り返して、連鎖が新しいネゴシエーションを生き延びることを確かめてください。説明はIOS XE IKEv2の範囲にとどめてください。過去のIKEv1 crypto mapの配備はオブジェクトモデルが異なり、この連鎖でデバッグすべきではありません。

トンネルが動いたら、その四つの名前を変更記録に書いてください。次にcrypto mapを触る人が必要としますし、連鎖は実行中のコンフィギュレーションが説明しない設計部分です。

関連記事