在DDoS防护场景中，当清洗中心完成流量清洗后，需要将干净的流量回注到用户的源站网络，而GRE隧道是目前业界最主流、最高效的回注手段之一。它的核心逻辑非常简单：清洗中心把清洗完毕的合法流量封装进GRE隧道包中，通过隧道穿越公网或专线，送到用户侧的路由器或防火墙上解封装，再把原始流量还原后注入用户内网。这种方式避免了清洗中心需要直接掌握用户路由信息的尴尬，也解决了跨运营商、跨地域回注的路由可达性问题。下面我会从原理、架构、配置要点、常见坑点和优化策略几个层面，把这件事讲透。
为什么要用GRE隧道做流量回注
传统的DDoS防护方案中，清洗中心通常部署在运营商机房或者云清洗节点上。当攻击流量被牵引到清洗中心后，清洗设备会把攻击流量丢弃，把正常流量放行。问题来了：放行之后，这些流量怎么送回用户的真实服务器？如果清洗中心和用户在同一个AS（自治系统）内，直接通过BGP或者静态路由就能送回去。但现实中，清洗中心往往在不同的网络环境里，用户的源站IP可能是一个/24甚至更小的网段，清洗中心根本不知道怎么路由到这些地址。这时候，GRE隧道就派上用场了。GRE是一种通用路由封装协议，它可以把任何协议的数据包（包括IPv4、IPv6）封装在一个新的IP头里，像快递打包一样，外层地址指向用户侧的隧道终点，内层保留原始数据包不变。用户侧设备收到后解封装，原始包就原封不动地出来了，再根据本地路由转发到真正的服务器。
GRE隧道回注的整体架构
一个典型的GRE隧道回注架构包含三个核心节点：牵引点、清洗中心、回注点。牵引点负责把用户的流量（包括正常和攻击流量）通过BGP Flowspec、DNS牵引或者策略路由等方式引流到清洗中心。清洗中心完成清洗后，通过GRE隧道把干净流量送到回注点。回注点通常是用户侧的一台路由器、防火墙或者专用的回注设备，它负责解封装GRE包并将流量注入用户内网。整个链路可以是这样的：用户公网IP → 牵引设备 → 清洗中心（清洗） → GRE隧道封装 → 公网/专线传输 → 用户侧回注设备（解封装） → 用户内网服务器。关键点在于，清洗中心只需要知道回注点的公网IP地址，不需要知道用户内网的任何路由细节，这大大降低了部署复杂度。
GRE隧道配置的核心参数
在实际配置中，GRE隧道两端需要对齐几个关键参数。第一是隧道源地址和目的地址，这决定了外层IP头的src和dst。第二是隧道接口的MTU值，因为GRE封装会增加24字节的头部开销（如果还有IPsec加密则更多），如果不调整MTU，大包会被分片甚至丢弃。第三是keepalive机制，确保隧道链路的健康状态能被实时监控。下面给出一个典型的Cisco IOS配置示例，展示清洗中心侧的隧道接口配置：
interface Tunnel0 description To-User-Return-Path ip address 10.255.255.1 255.255.255.252 tunnel source 203.0.113.10 tunnel destination 198.51.100.50 tunnel mode gre ip ip mtu 1400 ip tcp adjust-mss 1360 keepalive 10 3
用户侧回注设备的配置类似，只需要把source和destination对调：
interface Tunnel0 description From-Scrubbing-Center ip address 10.255.255.2 255.255.255.252 tunnel source 198.51.100.50 tunnel destination 203.0.113.10 tunnel mode gre ip ip mtu 1400 ip tcp adjust-mss 1360
MTU和MSS调整的重要性
这是很多人踩坑最多的地方。标准以太网MTU是1500字节，GRE封装加了24字节后，如果原始包就是1500字节，封装后就变成1524字节，超过了出接口的MTU。如果路径上的设备不支持分片或者设置了DF（Don't Fragment）位，这个包就会被直接丢弃，表现为用户访问正常但大文件传输失败、网页加载慢等症状。解决方案有两个：一是在隧道接口上手动设置较小的MTU（比如1400），二是配合ip tcp adjust-mss命令，在TCP三次握手时把MSS值降下来（通常设为MTU-40），从源头避免大TCP段的产生。在高带宽场景下，建议MTU设为1400到1476之间，具体取决于路径上是否还有其他封装开销。
回注流量的路由控制
隧道建好之后，还需要解决一个关键问题：清洗后的流量怎么知道该往哪个方向走？通常有两种做法。第一种是在清洗中心的隧道接口上配置策略路由（PBR），根据原始目的IP地址做匹配，把不同网段的流量送到不同的隧道或者不同的回注点。第二种是利用BGP，清洗中心通过BGP向用户侧回注设备通告用户的源站网段，回注设备收到解封装后的流量后，根据本地路由表正常转发。第二种方式更优雅，但需要双方都支持BGP且有AS号资源。对于中小企业，PBR方案更实际。配置PBR的核心思路是：在隧道接口上应用一个route-map，匹配原始包的目的IP，然后set next-hop指向隧道对端。
access-list 100 permit ip any 10.1.1.0 0.0.0.255 route-map GRE-RETURN permit 10 match ip address 100 set interface Tunnel0
多隧道负载均衡与冗余设计
在大型DDoS防护场景中，单条GRE隧道往往不够用。一方面是带宽瓶颈，单条隧道可能只有1Gbps或10Gbps的承载能力；另一方面是可靠性，单点故障会导致所有回注流量中断。业界常见的做法是建立多条GRE隧道，通过ECMP（等价多路径）或者基于源目的IP的哈希做负载均衡。在Cisco设备上，可以通过在多个隧道接口上配置相同的目的网段路由、不同的next-hop来实现。更高级的方案是使用VXLAN或者LISP等 overlay技术，但GRE胜在简单、兼容性好、几乎所有网络设备都支持。建议至少部署两条隧道，一条主用一条备用，配合BFD（双向转发检测）实现毫秒级故障切换。
GRE隧道的安全隐患与加固
GRE本身是没有加密的，这意味着隧道内的流量在公网上传输时是明文的。虽然这些流量已经是清洗后的合法流量，但仍然存在被中间人窃听或篡改的风险。如果业务对数据保密性有要求，可以在GRE之上叠加IPsec加密。但要注意，IPsec会进一步增加包的大小（ESP头加IV大约50字节），MTU需要相应调低。另外，GRE隧道的源地址如果被伪造，可能导致流量被错误注入到其他地方。建议在回注设备上配置ACL，只允许来自清洗中心已知IP的GRE包通过，拒绝其他来源的GRE封装包。
实际部署中的常见问题排查
根据我的经验，GRE回注部署后最常见的问题有三个。第一是隧道通但流量不通，通常是路由问题——回注设备解封装后不知道怎么转发原始包，需要检查回注设备上是否有到用户内网的路由。第二是小包通大包不通，基本就是MTU/MSS没调好。第三是间歇性丢包，可能是隧道路径上某个中间设备对GRE包做了限速或者QoS策略不友好，建议用traceroute和mtr工具逐跳排查。还有一种容易被忽视的情况：清洗中心在高负载时CPU占用过高，GRE封装处理不过来导致延迟飙升，这时候需要评估清洗设备的转发性能是否匹配回注带宽需求。
GRE回注与其他回注方式的对比
除了GRE隧道，业界还有几种回注方式值得了解。一种是直接路由回注，适用于清洗中心和用户在同一运营商网络内的情况，配置最简单但灵活性差。一种是MPLS L3VPN回注，适合大型企业有MPLS专线的场景，但成本高。还有一种是基于SDN控制器的动态回注，通过控制器实时下发流表，适合云清洗场景。相比之下，GRE隧道的优势在于：部署快、兼容性强、不依赖特定网络架构、支持跨运营商回注。劣势是没有原生加密、需要手动维护隧道状态、大规模场景下管理复杂度上升。对于大多数中型企业和IDC用户来说，GRE隧道仍然是性价比最高的选择。
未来趋势与技术演进
随着DDoS攻击规模越来越大（动辄Tbps级别），传统GRE隧道的单点承载能力正在成为瓶颈。未来的方向包括：一是基于SRv6（Segment Routing over IPv6）的回注，利用IPv6扩展头实现更灵活的路径编排；二是结合eBPF和XDP技术在回注点实现内核级高速转发，降低解封装延迟；三是清洗中心和回注点之间采用专线直连加GRE备份的混合架构，兼顾性能和可靠性。另外，自动化运维也是趋势，通过Ansible、NetBox等工具实现隧道的批量配置和状态监控，减少人工出错的概率。
总结
GRE隧道回注是DDoS防护体系中不可或缺的一环。它用最简单的封装方式解决了跨网络回注的路由难题，但要真正用好它，必须在MTU调优、路由策略、安全加固、冗余设计这几个方面下功夫。不要以为建好隧道就万事大吉，实际运维中百分之八十的问题都出在细节配置上。建议在部署前做好流量模型评估，选择合适的隧道数量和带宽规格，上线后持续监控隧道健康状态和回注流量质量，才能让整个DDoS防护链路真正跑稳跑通。
