IPSec / IKEv2 深度系列：从正确分层到 Linux xfrm
内容提要
本文介绍IPSec系列文章，对比WireGuard的cryptokey routing，详解SPD/SAD分层、IKEv2握手、ESP/NAT-T、Linux xfrm实现及strongSwan配置。强调IPSec在证书合规、互通性上的优势，但需权衡复杂度。提供8篇阅读路径，涵盖架构、协议、运维与后量子扩展，适合网络工程师深入理解IPSec机制与排障。
延伸解读
SPD/SAD 分层的代价与调试要点
文章指出，IPSec 的 SPD/SAD 分层在理论上合理，但运维上可能变成“多命名空间的拼图”。调试时，握手成功但 ping 不通，需要同时核对 IKE、policy 方向与 state。这提醒工程师，IPSec 的故障排查往往涉及用户态与内核态的多个层面，而 WireGuard 的 cryptokey routing 则简化了这种映射。
IKEv2 与 WireGuard 的握手差异
IKEv2 通过两个交换（四条消息）完成 IKE SA 和首个 Child SA 的建立，而 WireGuard 只需 1.5 RTT。文章强调 IKEv2 的握手更复杂，但支持证书认证和更灵活的协商。对于需要 X.509 生命周期管理或广泛互通的场景，这种复杂度是值得的；否则，WireGuard 可能更轻量。
Linux xfrm 的观测与排障
strongSwan 通过 netlink 将配置安装为内核 xfrm policy/state。排障时，必须确保 `swanctl --list-sas` 与 `ip xfrm state/policy` 一致，否则用户态与内核脱节。文章建议使用 netns 实验复现“能握手不通”的问题，并提供了排障命令台账，帮助工程师定位策略或状态配置错误。
Q&A
IPSec的SPD和SAD分别负责什么？为什么说这种分层在运维上可能造成调试困难？
SPD（安全策略数据库）根据选择器决定是否保护流量，SAD（安全关联数据库）用SPI等参数定位具体的SA（安全关联）。这种分层将策略与密钥分离，灵活但调试时若握手成功却ping不通，需同时核对IKE、策略方向和状态，增加了复杂度。
IKEv2握手过程是怎样的？与IKEv1相比有何优势？
IKEv2使用两个交换（IKE_SA_INIT和IKE_AUTH）共四条消息建立IKE SA并携带首个Child SA。IKE_SA_INIT建立加密通道和DH材料，IKE_AUTH完成身份认证并携带SA和TS载荷。相比IKEv1的多模式，IKEv2更简洁高效。
ESP、anti-replay和NAT-T是如何协同工作的？
数据面通常使用ESP（AEAD或加密+ICV）。NAT后使用UDP/4500封装，改变外层五元组，但内层选择器和SPI查找语义不变。anti-replay窗口挂在SA上，与策略表是不同故障面。
strongSwan如何将配置转换为内核中的xfrm状态和策略？
strongSwan的charon守护进程通过VICI接口接收swanctl配置，然后通过kernel-netlink插件向内核安装xfrm policy和state。排障时需确保swanctl --list-sas与ip xfrm state/policy一致，否则用户态与内核脱节。
在什么情况下仍然应该选择IPSec而不是WireGuard？
当需要X.509证书生命周期管理、广泛互通性或监管认可时，IPSec仍是默认选择。但需权衡协商面和扩展组合爆炸的成本。Cremers分析指出会话密钥保密性大体稳定，认证属性有边界；RFC 9370提供混合KE框架支持后量子。
本系列文章推荐的阅读路径有哪些？
有四种路径：1）只想理解复杂度：01→05→08；2）读协议字段：01→02→03→04；3）落地部署与排障：01→06→07；4）完整路线：01→02→03→04→05→06→07→08，并对照WireGuard系列和第75篇。
