DiffServ RFC 2983 与 VPN 隧道 DSCP 元数据泄漏防范

隐蔽的侧信道：服务质量（QoS）如何暴露通信特征

当现代应用程序发起网络通信时，操作系统会依据 RFC 2474 标准在 IP 报文头中标记区分服务代码点（DSCP，即 IPv4 的 Type of Service 或 IPv6 的 Traffic Class 字段）。例如，网络语音会议（VoIP）应用常标记加速转发类（DSCP EF，二进制 101110，数值 46），高清远程视频流常设置确定转发类（如 AF41，数值 34），而即时在线游戏则设置低延迟优先级标记。

在理想的安全设计中，将数据载荷封装在加密隧道（如 WireGuard、IPsec ESP 或 OpenVPN）内部旨在完全隐藏用户的通信意图。在外部观察者看来，加密后的传输数据应呈现为不可区分的统计随机流。

然而，许多常规隧道的默认实现存在架构设计疏漏：网卡在将内部原始报文封装进外部隧道 IP 报文时，直接且机械地复制了内部报文的 ToS/DSCP 字节。

当本地局域网监听者或中间网络服务提供商（ISP）对加密 VPN 的外层报文头进行嗅探时，他们虽然无法解密载荷内容，但由于外层 DSCP 标记忠实复刻了内层特征，监听者便能轻而易举地对加密流量展开高精度的类别研判：

运营商能够精准识别加密语音通话的起始时刻、持续时长与通话频率。
中间路由器可直接区分大文件后台下载（DSCP CS1 / Best Effort 000000）与交互式 SSH 终端连接（DSCP AF11）。
深度报文检测（DPI）系统将报文大小、数据突发间隔以及外露的 DSCP 标记进行特征关联，无需解密即可构建出准确的用户行为画像。

存在泄漏隐患的隧道（Uniform 模型）：
[ 内部报文: VoIP (DSCP 46 / EF) ] ---> [ 封装加密 ] ---> [ 外层 IP (DSCP 46 / EF) ]
                                                                     |
                                                                     v
                                                   运营商直观识别语音通话！

具备隔离能力的隧道（RFC 2983 Pipe 模型）：
[ 内部报文: VoIP (DSCP 46 / EF) ] ---> [ 封装加密 ] ---> [ 外层 IP (DSCP 0 / Best Effort) ]
                                                                     |
                                                                     v
                                                   运营商仅观察到均一数据流

RFC 2983 区分服务隧道模型：Uniform 与 Pipe

为了规范多层网络封装与区分服务之间的交互准则，互联网工程任务组（IETF）发布了 RFC 2983（《区分服务与隧道》），正式确立了三种隧道交互模型：

1. 统一模型（Uniform Model）

在 Uniform 模型下，网络视整个转发链路为单一连续的管理域：

报文进入隧道时，外层报文头直接复制内层报文的 DSCP 值。
中间传输路由基于该复制的优先级对隧道报文进行队列调度。
报文抵达隧道出口解封装时，中间网络可能做出的 DSCP 修改将被反向写回内部原始报文头。

尽管 Uniform 模型在可信跨域网络中维持了端到端 QoS 策略的一致性，但在公共网络中却破坏了隐蔽性，向不可信环境暴露了应用层通信特征。

2. 管道模型（Pipe Model）

在 Pipe 模型下，隧道被视为一条具有独立 QoS 策略的专用虚拟线路：

在进入节点，外层报文头的 DSCP 严格按照隧道服务商的外层策略设置，完全忽略内部报文原有的 DSCP。
外层 DSCP 通常统一固定为尽力而为（Best Effort 0x00）或约定的批量传输等级。
中间节点的调整仅作用于外层载荷在公共网络上的传输顺序。
在出口解封装时，外层报文头被直接剥离废弃，内部报文原汁原味地保留初始的 DSCP 标记。

Pipe 模型在网络层建立了彻底的元数据隔离：外部观察者只能看到特征均一的单一外层优先级。

3. 短管道模型（Short-Pipe Model）

Short-Pipe 模型在公网中继段的表现与 Pipe 模型完全一致。其区别在于出口解封装节点：网关在将报文注入最终内网时，其本地调度队列依据的是外层传输等级，随后再将恢复内层标记的报文送达终端。

商业网络部署中使用 Uniform 模型的风险分析

商业 VPN 服务与企业远程网关频繁部署在不可信的公网中。在此类场景中延用 Uniform 模型会引入多项风险：

风险维度	Uniform 模型的弊端	严格 Pipe 模型的防护表现
流量特征提取	严重：网络管理者可区分语音、视频及文本流	无：外层统一呈现为单一尽力而为等级
差别化限速	运营商识别特定视频标记（AF4x）并降级	所有数据包作为标准 UDP 流同等对待
侧信道指纹分析	依据敲击键盘时触发的交互标记推测按键	均匀的外部特征平抑了细微时延差异
外部恶意篡改	传输节点篡改外层标记将污染内部 QoS	外部所有修改在解封装阶段被丢弃

当中间网络可以读取外层 DSCP 时，他们即可在不触碰底层密码学算法的前提下，实施精细化的业务限速与流分类阻断。

解耦 ECN（RFC 6040）与 DSCP（RFC 2474）的数据清洗

在消除 DSCP 元数据泄漏时，常见的操作失误是将整个 ToS 字节直接置零。实际上，8 位字段由两个功能截然不同的逻辑单元组成：

 0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|          DSCP         |  ECN  |
+---+---+---+---+---+---+---+---+
       服务代码点          显式拥塞通知
      (位 0 到 5)         (位 6 和 7)

DSCP（第 0-5 位）：负责报文优先级控制。外层必须将其置为 000000 以消除元数据泄漏。
ECN（第 6-7 位）：依据 RFC 3168 与 RFC 6040 负责显式拥塞通知。这些位允许中间路由器在不发生丢包的情况下向端点通告网络拥塞（00 = 不支持，01 = ECT(1)，10 = ECT(0)，11 = CE 遭遇拥塞）。

若管理者直接将整字节写零（ToS = 0x00），便会误伤并屏蔽 ECN 机制。现代主动队列管理算法（如 CoDel、FQ-CoDel 和 CAKE）依赖 ECN 标记来预防缓冲区膨胀（Bufferbloat）。一旦丢失 ECN，中间节点只能被动丢包，导致延迟增加与吞吐骤降。

RFC 6040 明确规范了隧道内 ECN 的传递原则：

封装时，外层 ECN 必须准确映射内层的 ECN 能力。
解封装时，若外层收到了“遭遇拥塞”（CE，11）标记，必须将其正确合并回内层报文头中。

因此，规范的安全隧道系统应当清洗 DSCP（高 6 位），同时严谨保留并传递 ECN 拥塞信号（低 2 位）。

Linux 内核实现：XFRM、WireGuard 与 Netfilter Mangle

1. Linux IP-XFRM（IPsec）实现模式

在使用 ip xfrm 配置的 Linux IPsec 体系中，内核状态结构体（struct xfrm_state）默认会保留内层 ToS 并在封装时复制到外层。管理员可通过 iproute2 强制指定外层固定 ToS：

# 查看当前生效的 XFRM 状态
ip xfrm state show

# 固定外层 ToS 为 0 以符合 RFC 2983 管道模型规范：
ip xfrm state update src 203.0.113.10 dst 198.51.100.20 \
    proto esp spi 0x1000 reqid 1 mode tunnel \
    tos 0x00

2. WireGuard 内核模块的处理机制

在 Linux 原生 WireGuard 驱动（drivers/net/wireguard/send.c）中，数据发送逻辑如下：

/* WireGuard 外层报文头处理核心逻辑摘录 */
static void wg_send_packet(struct wg_device *wg, struct sk_buff *skb)
{
    ...
    /* WireGuard 提取内层 ECN 信号，同时将外部 DSCP 置零 */
    u8 ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb);
    ...
}

WireGuard 默认采用了安全的 Pipe 模型变体：外层 UDP 始终使用纯净的零值 DSCP，同时兼容传递正确的 ECN 状态。然而，运行在其他系统平台的用户态封装程序有时因继承宿主套接字标记而无意偏离此规范。

运用 eBPF 与 Nftables 实施出口流量规范化

为了确保所有类型的加密隧道在出口处均实现元数据隔离，可在 Linux 过滤层建立清洗机制。

1. 基于 Nftables 的规则定义

通过以下 nftables 规则，系统可拦截指定隧道端口（如 51820）的外发 UDP 报文，将其 ToS 高 6 位归零，同时完整保留低 2 位 ECN：

table inet vpn_sanitizer {
    chain egress_filter {
        type filter hook postrouting priority mangle; policy accept;

        # 将外层 DSCP 设为 cs0，保留第 6-7 位 ECN
        udp dport 51820 ip dscp set cs0
        udp dport 51820 ip6 dscp set cs0
    }
}

2. 基于 eBPF（tc-bpf）的高性能改写

在处理万兆级吞吐的核心网关上，挂载于 clsact 出口钩子处的 eBPF 程序能以极低资源损耗在内核环形缓冲区中直接重写报头：

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <bpf/bpf_helpers.h>

SEC("classifier/egress_dscp")
int sanitize_outer_dscp(struct __sk_buff *skb)
{
    void *data = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;
    struct ethhdr *eth = data;

    if ((void *)(eth + 1) > data_end)
        return BPF_OK;

    if (eth->h_proto == __constant_htons(ETH_P_IP)) {
        struct iphdr *iph = (void *)(eth + 1);
        if ((void *)(iph + 1) > data_end)
            return BPF_OK;

        /* 判断是否为目标隧道端口的 UDP 流量 */
        if (iph->protocol == IPPROTO_UDP) {
            /* 保留低 2 位 ECN（掩码 0x03），高 6 位 DSCP 置零 */
            __u8 old_tos = iph->tos;
            __u8 new_tos = old_tos & 0x03;

            if (old_tos != new_tos) {
                bpf_l3_csum_replace(skb, offsetof(struct iphdr, check),
                                    old_tos, new_tos, sizeof(new_tos));
                iph->tos = new_tos;
            }
        }
    }
    return BPF_OK;
}

char _license[] SEC("license") = "GPL";

RiceGuard 协议在元数据防泄漏层面的工程实现

VPNRice 在 RiceGuard 传输架构的设计中将防范侧信道泄密置于核心位置。客户端与接入节点全面落地了 RFC 2983 严格 Pipe 模型：

[ 用户终端应用流量 ]
  - 远程视频会议: DSCP AF41 (0x22)
  - 竞技游戏通信: DSCP CS2  (0x10)
  - 网页常规浏览: DSCP CS0  (0x00)
             |
             v
[ RiceGuard 客户端封装引擎 ]
  1. 将内层 DSCP 与 ECN 状态记录在安全的会话上下文中。
  2. 使用 ChaCha20-Poly1305 强加密算法封装载荷。
  3. 构建外层 IP/UDP 报头，将外层 DSCP 强制固定为 CS0 (0x00)。
  4. 按照 RFC 6040 映射规则计算外层 ECN 标志位。
             |
             v
[ 公共互联网中继 / 运营商网络 ]
  - 外部可见表现: 统计特征高度均一、无分类标记的纯净 UDP 字节流。
  - 彻底规避基于时延差与优先级标签的流量行为逆向推断。
             |
             v
[ RiceGuard 服务端网关解封装 ]
  1. 验证密文标签并执行解密。
  2. 提取外层 ECN 拥塞通告并与内层状态安全合并。
  3. 还原内层原始 DSCP 标记，供目标内网调度使用。

统一的外部传输外貌：终端与 VPNRice 节点之间交互的所有加密报文均呈现标准 CS0 属性。监控系统无法在外部将高实时性业务与普通下载流割裂开来。
完整的拥塞感知：通过与 RFC 6040 标准的严密协同，系统完好保留了链路早期拥塞提示，协助队列管理程序抵御时延抖动，且无惧丢包惩罚。
内核层级强效收敛：通过底层机制约束外层报文属性，防止宿主环境配置漂移导致隐秘信息泄露。

通过在架构底层彻底消除 QoS 侧信道特征，VPNRice 帮助用户在复杂网络环境下构筑起坚固的数据隐私屏障。