ike-scan 无法从正常工作的 IPsec 网关获得响应

这台网关每天都在为手机和笔记本电脑提供服务，但 ike-scan 却报告没有任何主机响应。这个输出看起来像是设备缺少 IPsec 的证据。通常它意味着设备丢弃了探测中的每一个提议，并选择什么都不回答。沉默也是一种响应，而且这是工具能给你的信息量最少的响应。

请分别弄清三个问题：数据包到达了吗，有提议匹配吗，是否有别的东西拒绝了对方？

第 1 步：阅读工具发送的提议

主模式以 SA 载荷开始，其中列出发起方愿意接受的转换，ike-scan 则从编译好的默认值填充这份列表。默认集故意做得很旧：加密用 DES 和 3DES，哈希用 MD5 和 SHA1，密钥交换用第 1 组和第 2 组，认证用预共享密钥。没有 AES，没有 SHA-2，没有第 14 组。为 AES-256、SHA-256 和 modp2048 配置的网关与它没有任何共同点。

有些实现会用 NO-PROPOSAL-CHOSEN 通知 回应不匹配的探测。另一些则直接丢弃，这在把未知对端当作噪声的设备上很常见。无论哪种情况，扫描都不会打印任何内容，而这种「什么都没有」与从外部看到的被过滤的 UDP 500 完全相同，ike-scan 项目文档 对默认集的说明也证实了这一点。

第 2 步：提供一个现代的提议

用 --trans 替换默认集。属性形式直接采用 IKE 属性编号：1 表示加密，2 表示哈希，3 表示认证，4 表示组，算法需要时 14 表示密钥长度。输出是一行可以在变更评审中大声念出来的内容。

位置形式按顺序携带相同的值，并避免使用括号，这在命令经过 shell 时很重要。

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

逐包发送一个提议在枚举时很慢，所以要对可能的值循环：加密 5、7/128、7/192、7/256；哈希 1、2、5、6、7；组 1、2、5、14、15、19、20、21；认证为预共享密钥用 1，为 RSA 签名用 3。运行前打印每一条命令，让记录显示提供了什么、按什么顺序。

第 3 步：解读应答

应答恰好证明两件事：该地址上有一个可达的 IKE 响应方，并且所提供的某个提议是可接受的。它没有说明预共享密钥、L2TP 层，也没有说明用户账户是否存在。扫描成功与后续每个阶段的失败完全兼容。

在你运营的网关上，这才是真正有用的部分。扫描告诉你设备仍然接受哪些提议，而结果仅限于旧式转换，这是关于设备策略的发现，而不是削弱客户端的理由。

第 4 步：解读沉默

沉默是比表面看起来更弱的证据。每个提议都可能被拒绝，UDP 500 和 4500 可能被过滤，源地址可能在突发之后被限速，或者服务监听的地址与你扫描的地址不同。在对这台设备下结论之前，先把网关的 IKE 日志与已经用有效凭据连接的客户端作比较。

突发行为也应列入其中，因为枚举会在短时间内产生大量数据包。先回应最初几次尝试、随后安静下来的网关，描述的是它的 anti-DoS 策略，而不是它的提议集。

第 5 步：记录你证明了什么

把被接受的组合写在固件版本旁边，然后与你关心的客户端默认提供的转换作比较。这两份列表之间的差距就是配置问题，扫描只是让它显现出来。如果唯一被接受的提议是那些你不会选择的，那么修复应属于网关策略或客户端配置文件，而不应属于探测。

一个从未得到回应的探测仍然回答了某些问题：它显示了这台设备愿意讨论哪些提议，以及宁愿把哪些提议丢在地上。