DDoS防护中遇到GRE隧道封装和IPIP协议的流量清洗，核心问题在于：隧道封装会把原始数据包的真实源IP和目标IP隐藏在外层头部里，清洗设备如果只看外层IP，根本无法判断流量是否合法。解决办法是在清洗节点上做"解封装—识别—清洗—重新封装"的完整流程，让清洗设备能看到内层真实流量，再根据策略做精准过滤。下面我把整个技术链路、关键步骤和实际部署要点全部拆开讲清楚。

一、为什么GRE和IPIP隧道会让DDoS清洗变复杂

GRE（Generic Routing Encapsulation）和IPIP（IP in IP）都是隧道封装协议，它们的作用是把一个IP数据包整个塞进另一个IP数据包里面传输。在正常业务场景下，比如跨运营商互联、多数据中心组网，这种封装很常见。但一旦遭遇DDoS攻击，问题就来了：攻击者可以利用隧道把大量恶意流量伪装成正常的隧道流量，直接打到你的业务服务器上。清洗设备收到的是外层封装包，如果不做解封装，就看不到里面到底是什么内容，清洗策略也就无从下手。

更麻烦的是，GRE隧道本身支持多协议承载，可以跑IPv4、IPv6甚至MPLS标签，而IPIP相对简单，就是纯IPv4套IPv4。两种隧道在清洗时的处理逻辑有差异，但核心思路一致：必须先剥掉外层，再做清洗。

二、GRE隧道封装的结构和清洗难点

GRE头部结构比较特殊，它有一个可选的Key字段和Sequence Number字段。标准GRE头至少4个字节，如果带Key就是8个字节。外层是IP头，内层又是一个完整的IP头加原始数据。清洗设备面对的是这样一个嵌套结构：

外层IP头 (20字节)
GRE头 (4~8字节，含可选Key)
内层IP头 (20字节)
原始数据 (TCP/UDP/ICMP等)

难点在于：第一，GRE没有固定端口号，它用IP协议号47来标识，不像TCP/UDP有端口可以做五元组过滤；第二，如果GRE带了Key字段，这个Key值可能被用来做负载均衡或标识不同业务，清洗时需要保留这个Key信息；第三，多层嵌套的情况下（比如GRE里面再套IPIP），解封装的顺序和层级判断会变得更复杂。

三、IPIP协议的结构和清洗特点

IPIP比GRE简单得多，它就是在原始IP包外面再加一个IP头，协议号是4。没有额外的Key字段，没有序列号，结构非常干净：

外层IP头 (20字节)
内层IP头 (20字节)
原始数据 (TCP/UDP/ICMP等)

IPIP的清洗优势在于解封装简单，直接剥掉外层20字节就能看到内层。但它的问题是：因为没有任何标识字段，当一条链路上跑了多条IPIP隧道时，清洗设备很难区分不同隧道的流量，容易把A隧道的合法流量误判为B隧道的攻击流量。所以实际部署中，IPIP隧道通常需要配合外层IP的源目地址或者DSCP标记来做区分。

四、完整的隧道流量清洗流程

整个清洗流程可以分为五个阶段，每个阶段都有具体的技术动作：

1. 流量牵引与识别阶段

首先要把隧道流量牵引到清洗设备上。常用方式有BGP引流、策略路由、或者在交换机上做端口镜像。牵引过来之后，清洗设备需要快速识别这是GRE还是IPIP流量。识别方法很直接：看外层IP头的Protocol字段，47就是GRE，4就是IPIP。如果是GRE，还要进一步判断是否带Key、是否有校验和等。

2. 解封装阶段

这是最关键的一步。清洗设备需要在硬件或软件层面把外层头部剥离。对于硬件清洗设备（比如基于FPGA或ASIC的清洗盒），解封装通常在芯片流水线里完成，延迟极低。对于软件清洗方案，可以用DPDK或者XDP在内核态做快速解封装。解封装后，设备就能看到内层的真实源IP、目标IP、协议类型、端口号等信息。

// 伪代码：GRE解封装逻辑
if (outer_ip.protocol == 47) {
    if (gre_header.flags & CHECKSUM_BIT) {
        verify_checksum(gre_header);
    }
    if (gre_header.flags & KEY_BIT) {
        extract_key(gre_header);
    }
    inner_packet = gre_header.payload;
    // 对inner_packet进行后续清洗
} else if (outer_ip.protocol == 4) {
    inner_packet = outer_ip.payload; // IPIP直接剥外层
}

3. 流量分类与清洗阶段

拿到内层真实流量后，就可以按照常规DDoS清洗逻辑来处理了。包括：基于五元组的速率限制、SYN Flood检测、UDP反射放大识别、ICMP Flood过滤等。这里有一个重要细节：清洗策略需要区分"隧道内的正常业务流量"和"通过隧道打进来的攻击流量"。比如，如果你的业务是通过GRE隧道跑的Web服务，那内层TCP 80端口的流量应该放行，但如果内层是大量UDP 53的放大包，就该清洗掉。

另外，对于GRE隧道，如果Key字段被用来标识不同租户或业务线，清洗策略还需要基于Key值做分流，不同Key走不同的清洗策略。

4. 重新封装与回注阶段

清洗完成后，合法流量需要重新封装回隧道格式，然后发回原始链路。这一步不能丢信息：GRE的Key值、序列号、校验和都要原样恢复；IPIP的外层源目IP也要还原成原来的值。如果清洗过程中修改了内层数据包（比如做了NAT），那外层的相关字段也要同步调整，否则回注的包会被对端设备丢弃。

5. 状态监控与策略调整

清洗不是一次性的事。隧道流量的攻击模式会变化，清洗策略需要动态调整。监控指标包括：隧道总带宽、内层各协议占比、清洗命中率、误杀率等。好的清洗系统会自动学习正常流量基线，当隧道内某类流量突然飙升时自动触发清洗规则。

五、硬件清洗和软件清洗的选择

在隧道流量清洗场景下，硬件和软件方案各有优劣。硬件清洗盒（比如基于NP的设备）解封装速度快，能处理几十G甚至上百G的隧道流量，适合大带宽场景。但硬件方案灵活性差，新增隧道类型或修改清洗逻辑需要固件升级。软件清洗方案（比如基于DPDK+eBPF的架构）灵活性强，可以快速适配新协议，但对CPU性能要求高，单核处理能力有限，需要多核并行。

实际部署中，很多企业采用混合方案：前端用硬件做粗粒度的隧道识别和大流量清洗，后端用软件做精细化的内层流量分析和策略调整。这种架构既保证了性能，又保留了灵活性。

六、部署中的常见坑和避坑建议

第一个坑：MTU问题。隧道封装会增加额外头部，导致数据包变大。如果原始链路MTU是1500，封装后可能超过，造成分片。分片后的包在清洗时更难处理，因为需要先重组再清洗。建议在隧道两端配置合适的MTU，或者开启DF位禁止分片，让大包直接丢弃并触发PMTUD。

第二个坑：多层嵌套。实际网络中经常出现GRE套IPIP、IPIP套GRE的情况。清洗设备需要支持递归解封装，而且要设定最大解封装层数防止死循环。一般建议最多解封装3层，超过的直接丢弃。

第三个坑：清洗设备成为瓶颈。隧道解封装和重新封装都消耗资源，如果清洗设备性能不够，反而会成为网络瓶颈。选型时一定要看设备的隧道处理能力，而不只是看总吞吐量。

七、总结与展望

DDoS防护中的GRE和IPIP隧道清洗，本质上是一个"先拆后洗再装"的过程。核心难点不在清洗本身，而在解封装的完整性和回注的准确性。随着云原生和边缘计算的发展，隧道流量会越来越多，清洗技术也在往智能化方向走——基于机器学习的隧道流量异常检测、自动化策略生成、实时流量画像等能力正在成为新的竞争点。企业在选型和部署时，不仅要关注当前的清洗能力，还要考虑未来协议演进和流量增长的扩展性。