IPsec提案には何が含まれる？ IKEとESPのフィールド

IKEが始まり、両方のピアがAESを通知しても、トンネルはNO_PROPOSAL_CHOSENで失敗します。ログは提案の名前を示しますが、一致しなかったフィールドは示しません。提案は一つの完全なオファーであり、一つの非互換フィールドがその行だけでなく組み合わせ全体を無効にします。これを独立したアルゴリズム選択の寄せ集めとして読むことが、不一致が見えないまま残る通常の理由です。

別々の提案リストを持つ二つの交渉

IKEv2は二つのセキュリティアソシエーションを構築します。一つ目は制御交換自体を保護するIKE SA、二つ目はESPを通じてトラフィックを運ぶCHILD SAです。それぞれに独自の提案リストがあり、ピアは一方を受け入れて他方を拒否できます。

この分離はよくある混乱を説明します。つまり、動作しているIKE SAは制御チャネルのアルゴリズムが一致したことだけを証明するのであり、CHILD提案が失敗すれば、第一フェーズが完了してログの上部が健全に見えても、トンネルはパケットを一つも運びません。

各リスト内の順序も重要です。応答側は開始側の順序付きオファーから選ぶため、広く互換性のある項目を狭い項目より上へ移すと、アルゴリズム名を一つも変えずに、導入されるスイートが変わります。その順序は既定値に頼らず構成で固定してください。安定した順序は、拠点間のログ比較を意味あるものにもします。

どのフィールドがどの提案に属するか

フィールドの集合は小さいものの、二つの交渉で同一ではありません。一方の列にあって他方にないフィールドがあるため、表は行ごとに読んでください。strongSwanの提案ドキュメントが一つの具体的な参照先です。

暗号化フィールドは暗号方式を、ほとんどの構文ではその鍵長も示します。整合性フィールドは暗号文の認証に使うハッシュを示し、PRFはIKE SAの鍵素材を導出する関数を示します。DHグループは新しい共有秘密素材を確立するため、両側に現れますが目的は異なります。

拡張シーケンス番号はデータ経路にのみ属します。シーケンス空間を広げ、CHILD提案の一部として交渉されるため、そこでの不一致はCHILDオファーを拒否し、IKE SAはそのまま残ります。

一つの完全なオファーがどう選ばれるか

各提案は集合であり、応答側は必須の全フィールドが受け入れ可能な集合を探します。二つのリストがどちらもAESとSHA-256を含んでいても、鍵長、PRF、DHグループが異なるため互換性のある項目がないことがあります。比較はアルゴリズム単位ではなく提案単位で行われます。

何も一致しない場合、応答側は失敗したSA種別とともにNO_PROPOSAL_CHOSENを送ります。構成を編集する前に通知がどの提案リストを指すのかを読み、IKE提案が拒否されたのにESPアルゴリズムを変えるのはデバッグの一手を無駄にします。

プロファイルを調整するときは、選択の振る舞いを知っておく価値があります。開始側の順序を好む実装もあれば、ローカルポリシーで並べ替える実装もあり、二つのベンダー間で機能するスイートが消えることが、接続を開始する側を逆にすると起こります。

AEADはフィールドを追加するのではなく削除する

AES-GCMとChaCha20-Poly1305は一つの処理で認証と暗号化を行います。どちらかをESPに選ぶと、AEAD構造がすでに覆っているため、整合性アルゴリズムは別途交渉されません。したがってAES-GCMとSHA-256を組み合わせた提案は、最良でも冗長であり、最悪では拒否されます。

PRFはIKE側では依然として別です。制御チャネルの鍵を導出するのであってペイロードを保護するわけではないため、IKE提案はAEAD暗号とPRFとDHグループを正当に組み合わせられますが、対応するESP提案はAEAD暗号と任意のPFSグループだけを列挙します。

鍵長は暗号化トークンの一部なので、AES-128-GCMとAES-256-GCMは別のオファーです。256-bit鍵を前提としたガイドからコピーしたプロファイルは、両方の行がAES-GCMと書いていても、128-bit向けに構成されたエンドポイントとは一致しません。二つのピアは暗号ファミリーで合意しても、ハイフンの後の数字で互いを拒否することがあります。

構成ではなく導入済みのSAを読む

構成された提案リストがオファーで導入されたSAが結果であり、strongSwanとLinuxカーネルでは両方の表示が利用できます。

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sasはSAごとに交渉されたアルゴリズムを出力し、CHILDがAEADを使うかどうかも含みます。 ip xfrm state カーネルが実際に何を導入したかを示し、鍵更新が文書化したものと別のスイートに戻っていないことを確認する場所です。

修正後はその出力を構成の隣に保存してください。クライアントの更新が既定値を変えたとき、記録したスイートが比較の基準線になり、比較は調査を最初からやり直す代わりに、動いたフィールドを指し示します。