【网络工程】WireGuard 内部实现：Cryptokey Routing、Noise IK 握手与内核数据路径
内容提要
WireGuard以约5000行内核代码实现VPN，对比IPSec的30万行，通过Cryptokey Routing将公钥与IP绑定、固定Noise IKpsk2握手及多核并行加密，简化设计并提升安全性。它拒绝证书、算法协商等复杂机制，但适用于L3隧道场景，不适合L2桥接或需证书合规的环境。
延伸解读
设计取舍的代价
WireGuard 通过拒绝证书、算法协商和 SPD/SAD 分层，将代码量压缩至约 5000 行，但这也意味着它只适用于 L3 隧道。若需要 L2 桥接、证书合规或动态路由集成，IPSec/IKEv2 仍是更合适的选择。这种极简设计在缩小攻击面的同时，也限制了其应用场景。
1.5 RTT 的安全含义
WireGuard 的 1.5 RTT 并非协议规范定义，而是安全边界推导的结果。响应方需等待发起方的第一条传输消息，才能确认对方已切换到新会话，从而获得强前向保密。这一属性已由 Dowling & Paterson 的形式化分析确认，体现了设计对安全性的严谨考量。
内核数据路径的并行与保序
WireGuard 通过设备级并行加密和 peer 级串行发送，解决了吞吐量与保序的矛盾。每个 peer 拥有独立的队列和 NAPI 实例，使得不同 peer 的加解密可并行执行，而单个 peer 的发送顺序不受影响。这种设计避免了全局 SA 的串行 rekey 瓶颈，提升了多 peer 场景下的性能。
Cookie 机制与 DoS 防御
WireGuard 的 DoS 防御通过 MAC1 和 MAC2 两级过滤，确保攻击者无法让服务器执行昂贵的 DH 运算。正常负载下仅验证 MAC1，高负载时要求携带 cookie，而 cookie 由服务器密钥生成，攻击者无法伪造。这种无状态设计以极小的代码量（约 150 行）实现了有效的攻防不对称。
Q&A
WireGuard 相比 IPSec 在代码规模上有何优势？
WireGuard 内核实现约 5000 行 C 代码，而 IPSec 协议栈（如 StrongSwan）源码约 30 万行，代码量显著减少。
WireGuard 的 Cryptokey Routing 是如何工作的？
Cryptokey Routing 将公钥与 AllowedIPs 绑定，每个 peer 是一个 (公钥, AllowedIPs, Endpoint) 三元组。发送时根据目的 IP 在 AllowedIPs trie 中查找对应 peer，并用该 peer 的密钥加密；接收时验证源 IP 是否在 peer 的 AllowedIPs 中，不匹配则丢弃。
WireGuard 使用哪种握手协议？为什么是 1.5 RTT？
WireGuard 使用 Noise IKpsk2 握手。名义上是 1-RTT，但响应方需要收到发起方的第一条 transport 消息后才能安全发送数据，因此实际安全数据延迟为 1.5 RTT。
WireGuard 如何实现多核并行加密并保持数据包顺序？
WireGuard 使用设备级并行加密和 peer 级串行发送。加密任务通过 ptr_ring 分发到多个 CPU 核上的 worker 并行处理，而每个 peer 的 tx_queue 使用 prev_queue 保证发送顺序与入队顺序一致。
WireGuard 如何防御 DoS 攻击？
WireGuard 使用 MAC1 和 MAC2 两层防御。正常负载下只验证 MAC1；高负载时要求客户端携带 cookie（MAC2），cookie 由服务器用 secret 对源 IP 和端口计算，攻击者无法伪造，从而避免服务器进行昂贵的 DH 运算。
WireGuard 的密钥轮换机制是怎样的？
每个 peer 维护三个 keypair 槽位：current、previous、next。触发 rekey 时创建 next_keypair，握手成功后 previous 变为 current，current 变为 next，旧密钥在 REJECT_AFTER_TIME（180秒）后清零。触发条件包括时间（120秒）、消息数（2^60）或活性检测。
WireGuard 有哪些不适合的使用场景？
WireGuard 不适合 L2 桥接、需要证书体系的合规环境、UDP 被封锁的网络、以及需要动态路由协议（如 OSPF/BGP）的场景。此外，它基于 Curve25519，不抗量子计算攻击。
