StrongSwan 内存泄漏问题分析与修复：重载配置时原始公钥的处理缺陷

在 StrongSwan 项目中，当使用原始公钥（raw public keys）并频繁重载配置时，系统会出现内存持续增长的问题。本文将深入分析这一问题的技术根源，解释其影响机制，并介绍官方的修复方案。

问题现象

用户在使用 StrongSwan 时发现，当配置中包含原始公钥并频繁执行配置重载操作（特别是通过 vici 接口的 load-conn 命令）时，系统的内存消耗会持续上升。经过测试确认，内存增长的速率与配置重载的频率成正比。

技术背景

在 StrongSwan 中，原始公钥是通过 pubkey 插件进行处理，并被封装在 certificate_t 对象中。这种设计使得公钥能够像证书一样被统一管理，包括被存储在内存中的证书存储区。这种机制的主要目的是避免重复加载相同的证书（例如在每个加载的配置中重复存储），通过引用计数来管理证书对象的生命周期。

问题根源分析

问题的核心在于原始公钥的处理流程存在两个关键缺陷：

1. 身份标识不匹配问题：

   • 当 vici 插件解析 pubkeys 设置时，会加载并封装原始公钥，此时这些公钥还没有关联的身份标识（identity）
   • 因此生成的 certificate_t 对象的主题（subject）默认使用公钥的密钥ID（即哈希值）
   • 该对象被添加到证书存储区时，由于没有重复项，会直接存储新对象
   • 当完整解析配置的 local/remote 部分并配置了 id 时，系统会查找原始公钥并将证书对象的主题更改为该身份标识

2. 重复存储问题：

   • 由于第一次存储时使用的是密钥ID，而后续使用时使用的是配置的身份标识，导致系统无法识别这是同一个公钥
   • 每次 load-conn 调用都会向存储区添加两个新的公钥证书对象（一个使用密钥ID，一个使用身份标识）

3. 潜在的线程安全问题：

   • 当证书已经在共享存储区中时，修改其主题（identity）的操作存在潜在的竞态条件
   • 其他线程可能在主题被替换的过程中尝试访问 identification_t 对象，虽然发生概率不高，但确实存在风险

影响评估

这一缺陷会导致：

• 内存持续增长，影响系统稳定性
• 随着配置重载频率增加，内存消耗呈线性增长
• 在极端情况下可能导致内存耗尽
• 存在潜在的线程安全问题，可能引发不可预知的行为

解决方案

StrongSwan 官方已经提供了修复方案（vici-duplicate-pubkeys 分支）。作为临时解决方案，用户可以：

1. 定期使用 clear-creds 命令清除所有加载的凭据（包括共享证书存储区中的证书）
2. 然后重新加载私钥

这种方法不会影响配置中的引用，但可以释放重复存储的公钥对象。

技术启示

这一案例展示了在安全通信系统中处理加密材料时需要注意的几个重要方面：

1. 对象标识一致性：在基于哈希或标识符的存储系统中，必须确保对象的标识方式在整个生命周期中保持一致

2. 资源管理：即使是使用引用计数等高级内存管理技术，也需要考虑所有可能的对象创建路径

3. 线程安全：共享资源的修改操作必须考虑并发访问的场景

4. 配置重载设计：支持动态配置重载的系统需要特别注意重复加载相同资源时的处理逻辑

对于使用 StrongSwan 的开发者和系统管理员，建议在频繁修改配置的场景下密切关注内存使用情况，特别是在使用原始公钥时。及时更新到包含修复的版本可以避免这一特定问题的发生。