iOS 拒绝了你的 strongSwan 隧道：比对 IKE 提议

证书或地址都无法解释：去年还能连接 strongSwan 的 iPhone，今年为什么失败。地址、预共享密钥和客户端身份都未必变过。真正变的是手机内置客户端愿意协商的变换列表；一旦它与服务器的列表不再有交集，交换会在检查任何一方身份之前就结束。

决定成败的那行日志

为这条连接打开详细日志，找到决定结果的两条记录：手机提供了什么，服务器选中了什么。如果日志在未选中提议处结束，并报告没有匹配项，那么认证根本没有开始。此时换新证书、改新密码都没有用，因为两者都在更晚的阶段才会被用到。它们都无法影响一个在检查身份之前就已定下的结果。

动手前先把两种失败形态分开。改变换救不了被拒的凭据，修凭据也救不了被拒的变换。日志里那条写明已选中提议的记录，会告诉你属于哪一种。没有那条记录，你就是在猜。

被选中的那行用变换集来命名提议，而不是友好的标签。 比对加密、完整性和分组字段 与手机发来的列表，因为任何一个字段不匹配都足以失败。

手机上发生了什么变化

有一个 iOS 版本削减了客户端愿意使用的算法。弱完整性哈希、小 Diffie-Hellman 群组，以及把旧选项排在前面的提议，都不再被接受。

列表更长在这里并不更安全。选择遵循手机接受集及其自身的优先顺序，所以即使服务器的目录很宽，只要被选中的不是现代条目，仍然会输掉协商。优先用短列表，并把现代条目放在前面。以旧选项开头的长列表，恰恰会招来你想避免的失败。接受集是一道外部约束，客户端一更新就会变动，所以昨天能用的配置只证明昨天。

仍然可以协商的一组配置

对当前手机来说，一套现代组合就够。能协商的一组看起来是这样：

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

ike 行承载密钥交换运行期间的加密、完整性和 Diffie-Hellman 群组。esp 行只覆盖数据通道，因为群组在它生效之前就已确定。重新加载连接或重启守护进程，然后重连手机。只有当你在服务的所有客户端仍然接受这个群组值时，才保留它；不要因为一个旧对端需要更多，就对所有人放宽提议。

三个可以修的地方，其中一个通常不可行

• 为所有对端用同一套现代提议。 当所有客户端都是当前的手机和桌面时，这是正确的做法。它删除旧变换，而不是围着它们协商。
• 为 Apple 客户端增加第二条连接定义。 让一个旧对端继续活着，同时给手机一个它接受的提议。代价是多一个连接块，并且让这个例外变得可见。
• 更换客户端。 通常轮不到你：当管理系统或某个应用下发配置文件时，没有提议编辑器可动，内置客户端也不暴露它。

当有一台你控制之外的设备无法更新时，选第二种。当你能淘汰旧对端、并且愿意只维护一套策略时，选第一种。

无论哪种，选择都应当体现在配置里，这才是重点。悄悄回落到旧变换的自动降级比显式阻断更糟，因为任何评审都不会让它浮现。

先证明，再记录

重连后，在服务器上核对三件独立的事实：提议已被选中、连接显示为已建立、客户端拿到了地址。握手已建立却没有远端地址，问题指向地址池或流量选择器，那属于另一项改动。把两者混在一起处理，会让已经解决的协商看起来仍未解决。

记下被接受的变换集、你何时改的、以及你验证过哪个客户端版本。下一次更新可能再次移动要求，而那些曾经可用的值，是你最想放在新值旁边的东西。