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 的 提议文档 涵盖两份列表的语法。