IKEv2 NO_PROPOSAL_CHOSEN：どの段階がスイートを拒否したのか

ログの NO_PROPOSAL_CHOSEN を見ると、人は事前共有鍵へ向かいますが、鍵を変えてもエラーは残ります。これは決して認証情報の問題ではありませんでした：ピアはその交換のために提示されたすべての提案を拒否しており、それは身元ではなくアルゴリズムについての表明です。最初に有用な問いは、どのアルゴリズムを編集するかではなく、どの交換が拒否されたかです。何かを比較する前にそれに答えてください。次に、提示されたスイート全体とピアが許可するスイート全体を比較します。

まず、どの交換が拒否されたか

IKEv2 は 二種類のアソシエーションを交渉します。IKE SA は交渉そのものを保護し、CHILD SA はトラフィックを保護します。それぞれに独自の提案セットがあり、それぞれが同じ通知で失敗することがあります。初期 IKE 交渉中の拒否と CHILD 交渉中の拒否では必要な修正が異なり、ログは通常、通知の 一～二行上で交換の名前を示します。その二行を一緒に読まないと、間違った提案リストを編集することになります。

通知だけでは交換を特定できません。その上の行が交渉中の SA を示し、その名前が検査すべき提案リストを指します。

単一のキーワードではなく、完全なスイートを比較する

提案は組み合わせです：暗号アルゴリズム、整合性または AEAD、鍵交換グループ、そして任意の疑似乱数関数です。暗号名だけを比較するのがよくある間違いで、二つのピアは AES-256 で合意しながら SHA-1 と SHA-256 では不一致のままかもしれません。失敗した段階で提示側と許可側のスイートを並べて書き、次に空の共通部分を探します。

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

また、両方の実装が設定した内容をサポートしているか確認してください。別のプラットフォームからコピーした名前は、構文的には見慣れたものに見えるかもしれません 一方でプラグインや実装が完全に欠けている場合があります。

IKE スイートと ESP スイートは別のオブジェクトです

IKE 提案を編集しても拒否された CHILD 提案は直らず、逆も同様です。strongSwan ではこれらは別々の設定で、おおよそ IKE SA には proposals = aes256-sha256-modp2048、CHILD SA には別の ESP リストです。失敗した交換に合うリストを変更し、修正が効いたと決めつけずにログを読み直してください。

CHILD SA では関連する設定は ESP 提案リストであり、IKE のリストではありません。IKE 行をそこへコピーすると、解析は通るが誤ったオブジェクトを交渉する設定になります。

稼働していたトンネルが鍵更新で失敗する

トンネルが一時間動いてから失敗したなら、初期交渉が問題ではありません。鍵更新は別の条件を試すことがあります：最初の交換の後に異なる鍵交換グループ、ピア間の有効期間の不一致、あるいは変更されたレスポンダのポリシーです。更新のタイムスタンプと両側のアソシエーション識別子を保存してください。そのパターンには更新時の提案比較が必要で、より長いタイムアウトではありません。タイムアウトの変更は症状を隠し、不一致をそのまま残します。

ipsec statusall は各アソシエーションと実際に交渉されたアルゴリズムを表示します。その出力はどのリストが使われたかを確認する最速の方法で、設定エラーと再交渉されなかった古いトンネルを切り分けます。

ipsec statusall | grep -E "IKE:|ESP:"

共通部分を選び、次に両方のフェーズを確認する

管理者に、両方のピアがサポートする文書化された現代的な共通部分を選ばせ、書き留めさせてください。すべての古いアルゴリズムを有効にしたり、身元確認を無効にしたりしてエラーを解決しないでください、どちらも拒否から導かれるものではないからです。変更後は新しい接続を確立し、その後に鍵更新を強制します。最初の接続だけでは更新経路が機能することを証明できません。

受け入れられた組み合わせをファームウェアのバージョンと一緒に保管してください。次のエラーがトラフィックセレクタに関するものなら別に扱ってください、暗号についての合意は、トンネルがどのサブネットを保護するかについては何も語らないからです。strongSwan の 提案ドキュメント は両方のリストの構文を扱っています。