WireGuard 抗重放机制：滑动窗口与乱序数据包投递

在评估加密网络隧道协议时，工程人员的注意力通常集中在加密套件的强度以及数据认证算法上。诸如 ChaCha20-Poly1305（RFC 8439）这类前沿算法，能够在数学层面上确保未授权的第三方无法解密通信内容或伪造载荷数据。然而，加密机制本身并不能解决无连接 IP 网络中普遍存在的底层威胁：数据包重放攻击（Replay Attack）。

监听物理链路的攻击者无须破解密钥。通过录制捕获合法的已加密 UDP 数据包并在稍后重新注入网络，攻击者就能扰乱活跃会话、触发重复的资金指令，或诱发上层应用协议的状态机错误。更严重的是，对于 ChaCha20 这类流加密算法，如果在同一对称密钥下对两个不同数据包重复使用相同的初始化随机数（Nonce），简单的异或运算就会直接泄漏密钥流，造成灾难性破坏。

为了在抵御重放风险的同时，确保高抖动网络环境下的极致吞吐性能，WireGuard 采用了源自 RFC 6479 的抗重放架构。通过将 64 位单调递增传输计数器与高效的位图滑动窗口相结合，WireGuard 既杜绝了数据重放，又避免了因网络乱序到达而造成的数据包误丢弃。

+-----------------------------------------------------------------------------+
|               WIREGUARD RFC 6479 位图滑动窗口工作原理                       |
|                                                                             |
|      已过期丢弃区域                  活跃位图窗口范围（2048 位）            |
|  ◄───────────────────────────┤──────────────────────────────────────────►   |
|   计数器 < (T - 2048)        │               (T - 2048) 至 T 之间       │  |
|                              │                                           │  |
|  ... [数据包 k] [包 k+1] ... │ [位 0]  [位 1]  ...  [位 i]  ... [位 2047]│  |
|                              │    │       │           │           │      │  |
|                              │ 窗口内最   │       当前到达数据包  │      │  |
|                              │ 旧数据记录 │       （检查并标记）  │      │  |
|                              └────────────┴───────────┬───────────┴──────┘  |
|                                                       │                     |
|                                                       ▼                     |
|                                            若对应位 == 1：丢弃（检测到重放）|
|                                            若对应位 == 0：接收并置位为 1    |
|                                            若计数器 > T ：向前滑动窗口      |
+-----------------------------------------------------------------------------+

Nonce 复用危机与 64 位传输计数器

ChaCha20-Poly1305 认证加密体系需要三项输入：256 位对称密钥、明文载荷以及唯一的 Nonce。WireGuard 在封装传输数据包时，直接将一个 64 位单调递增的整数计数器作为 Nonce，配合 Poly1305 生成的 16 字节认证标签共同工作。

Nonce 的唯一性在密码学中是绝对红线。如果发送端在同一密钥下使用相同 Nonce 加密了两个不同明文：

$$C_1 = P_1 \oplus Keystream(K, N)$$ $$C_2 = P_2 \oplus Keystream(K, N)$$

窃听者计算两个密文的异或和，即可完全消除密钥流：

$$C_1 \oplus C_2 = P_1 \oplus P_2$$

这一代数抵消特性让攻击者能够开展明文恢复与伪造标签攻击。为杜绝此类风险，WireGuard 发送端在每个数据通道会话建立时将计数器归零，此后每发送一个数据包便自增 1。

64 位计数器的容量高达 $1.8 \times 10^{19}$ 个数据包，在常规应用周期中根本无法被耗尽。即便在 100 Gbps 线路全速饱和传输，也需要数十年才能跑满。不仅如此，WireGuard 内置的 Noise IKpsk2 握手每隔数分钟便会触发临时密钥轮换，将计数器在新密钥下平滑复位。

网络乱序传输的现实挑战：为何简单单调判定不可行

虽然发送端严格按照顺序自增计数器（$0, 1, 2, 3, \dots$），但互联网底层基础设施在转发 UDP 报文时是完全无状态且独立的。在实际网络环境中，数据流经常遇到：

等价多路径路由（ECMP）： 骨干交换机将同一流向的数据分散至不同光纤路径，导致微小的物理传输时延差。
网卡多队列接收（RSS）： 现代网卡硬件将并发数据帧分发至不同的 CPU 核心，造成调度时间微差。
蜂窝网络与无线信道抖动： 移动 5G 基站切换或 Wi-Fi 动态调频都会形成毫秒级的数据暂存队列。

这些因素导致接收端经常收到逆序到达的数据包：

$$\text{发送序列：} \quad [1, 2, 3, 4, 5, 6]$$ $$\text{到达序列：} \quad [1, 3, 2, 5, 4, 6]$$

如果接收端采取严苛的单调递增判定（仅接收编号大于已知最大值的数据包），那么在数据包 3 先到达后，稍晚几毫秒到达的数据包 2 就会被当作异常报文丢弃。这种因短暂乱序而导致的弃包，会给内部封装的 TCP 流带来严重冲击。

一旦 TCP 察觉丢包，便会接连触发重复确认（dupACK）、激活快速重传机制并将拥塞窗口减半，导致传输速率断崖式下跌。因此，健壮的抗重放算法必须在精确剔除恶意重放的同时，包容合法的网络乱序。

+-----------------------------------------------------------------------------+
|                      到达数据包计数器判定逻辑矩阵                           |
+--------------------------+----------------------------+---------------------+
| 接收计数器值（$C$）      | 相对于当前窗口的判定区间   | 内核处理策略        |
+--------------------------+----------------------------+---------------------+
| $C > T_{\text{顶端}}$     | 超过已知最大序列号         | 窗口向前滑动推进    |
|                          |                            | 在位图中标记置位    |
+--------------------------+----------------------------+---------------------+
| $T_{\text{顶端}} - W \le$| 处于当前活跃滑动窗口内     | 若该位为 0：接受    |
| $C \le T_{\text{顶端}}$  |                            | 若该位为 1：丢弃    |
+--------------------------+----------------------------+---------------------+
| $C < T_{\text{顶端}} - W$| 落后于滑动窗口有效下限     | 直接丢弃            |
|                          |                            | （认定为陈旧或重放）|
+--------------------------+----------------------------+---------------------+

RFC 6479 算法：无需内存位移的位图滑动窗口

为化解乱序与防重放之间的矛盾，早期 IPsec 规范（RFC 4303）提出了基于位图的滑动窗口方案，窗口宽度通常为 32 或 64 位。当收到更高序列号的数据包时，系统便在内存中将整个位图向左物理平移若干位。

然而，在每秒需要吞吐数百万数据包的高速线路上，频繁对 1024 或 2048 位的大数组进行内存平移，会严重消耗处理器指令周期并导致 CPU 缓存失效。WireGuard 创新地引入了 RFC 6479 所定义的环形位图算法。

循环索引与数学映射

RFC 6479 抛弃了传统的数据物理平移机制，改用固定长度的环形数组。在 WireGuard 的设计中，抗重放窗口跨度为 $W = 2048$ 位，由 32 个 64 位无符号长整型字组成（$32 \times 64 = 2048$ 位）：

#define COUNTER_WINDOW_SIZE 2048
#define COUNTER_BITS_PER_WORD 64
#define COUNTER_WORDS (COUNTER_WINDOW_SIZE / COUNTER_BITS_PER_WORD) // 32 个字

struct noise_replay_counter {
    u64 counter;
    unsigned long backtrack[COUNTER_WORDS];
    spinlock_t lock;
};

当到达数据包携带计数器 $C$ 时，算法利用取模逻辑定位具体负责该区间的机器字：

$$\text{字索引} = \left(\frac{C}{64}\right) \pmod{32}$$ $$\text{位偏移} = C \pmod{64}$$

由于机器字数量为 2 的幂次方，取模运算在汇编级别被极致简化为单条位与（AND）指令：

unsigned long word_index = (counter / 64) & (COUNTER_WORDS - 1);
unsigned long bit_mask = 1UL << (counter & (COUNTER_BITS_PER_WORD - 1));

窗口平滑滑动逻辑

针对接收到的数据帧，算法将其归入三种状态之一进行处理：

处于活跃窗口内部（$T - W < C \le T$）： 检查对应字中的目标位。若该位已为 1，说明是重复数据包，立即丢弃；若该位为 0，则接受该数据包，并将该位翻转为 1。
超越已知上限（$C > T$）： 该数据包属于最新序列。窗口需要向前推进。算法无须平移内存，只需将旧顶端到新顶端之间的中间字批量重置为 0，将顶端游标更新为 $T = C$，并完成置位。
严重落后于窗口下限（$C \le T - W$）： 序列号已落后最新记录超过 2048 个包。系统在解密前即刻丢弃，不占用密码学算力。

该机制实现了 $O(1)$ 常数级时间复杂度，杜绝了频繁的内存分配，保持了高效的处理器缓存命中率。

环形位图数组在系统内存中的物理排布（32 个 64 位字）：
字 0         字 1         字 2               字 31
[64 位]      [64 位]      [64 位]     ...    [64 位]
    ▲
    │
    └── 逻辑指针循环递进，无需在内存中移动数据字节

多核并行解密与原子同步机制

在高性能网关架构下，单核心处理海量 UDP 报文会造成明显的吞吐瓶颈。在 Linux 内核原生实现中，WireGuard 借助并行工作队列 padata 将密码学开销均匀分摊至所有可用的 CPU 核心。

数据处理管线逻辑清晰：

报文接入： 驱动层将收到的 UDP 报文推入接收缓冲区。
多核心并行解密： WireGuard 将 ChaCha20-Poly1305 解密任务并发分派给各个 CPU 核心独立计算。
序列化抗重放校验： 由于多核心并发完成的时间有先有后，抗重放窗口的判定被安排在轻量化的串行收尾阶段（wg_packet_consume_data_done），依靠原子锁保障一致性。

将算力繁重的解密任务并行化，而将精炼的窗口校验串行化，使 WireGuard 在数十吉比特每秒的高吞吐状态下依然能彻底规避竞态冲突。