DDoS防护中流量回注时的路由策略与ACL控制

DDoS防护体系里，流量回注的成败往往不取决于清洗设备有多强，而在于路由策略和ACL控制是否足够精细。很多看似“清洗无效”的故障复盘到最后，根因都是回注流量被二次丢弃，或者路由环路把清洗中心本身打瘫。直接讲问题核心：流量回注本质上是一次人为制造的路由劫持，你要把原本去往目标服务器的流量“骗”到清洗设备，洗完后再“塞”回正常路径。这个过程涉及BGP、IGP、策略路由以及接口ACL的精密配合，任何一个环节的疏忽都会造成业务中断。

回注流量从清洗设备出来时，源IP是真实客户端地址，目的IP是被防护业务的真实地址。如果这台清洗设备与核心路由器之间跑的是动态路由协议，清洗设备必须对外宣告它拥有到达被防护地址的路由，而且这条路由的优先级要足够高，才能把流量吸过来。但问题在于，清洗设备宣告的路由不能无限制地扩散，否则会把全网的正常流量也牵引过来，造成路由环路或者非清洗流量绕行。

常见的做法是在清洗设备与上游路由器之间建立BGP邻居，通过BGP community或MED值精确控制路由的传播范围。比如只向特定的上游设备宣告/32位的主机路由，并打上no-export community，确保这条路由不会传出本地AS。同时，上游路由器需要配置入站路由策略，只接受来自清洗设备的特定前缀，拒绝其他无关路由，防止清洗设备被攻陷后向外发布恶意路由。

更隐蔽的陷阱在于回注流量的下一跳可达性。清洗设备把流量回注给核心路由器时，如果下一跳地址是通过IGP学习到的，而清洗设备本身又宣告了更优路由，就可能出现“路由递归查询死循环”。比如清洗设备要回注流量给目标服务器，查路由表发现目标服务器在自己宣告的/32路由范围内，下一跳指向自己，流量就出不去了。解决方法是清洗设备必须使用静态路由或者策略路由，强制将回注流量的下一跳指向物理出口的对端地址，而不是依赖动态路由表的递归查询。

流量回注最怕的是非对称路径。清洗后的流量从清洗设备出去走路径A到达服务器，但服务器回复的流量却走了路径B，绕过了清洗设备。这在多出口、多链路的网络环境中几乎是必然发生的事。一旦出现非对称，基于状态检测的防火墙或会话表就会把回程流量当成无效会话丢弃，业务表现为时断时续。

策略路由（PBR）是解决这个问题的核心工具。在服务器侧的交换机或路由器上，不能简单地用目的地址来路由回程流量，必须根据源地址来强制下一跳。具体做法是：在连接服务器的三层设备上配置入站策略路由，匹配源IP为被防护地址的流量，强制其下一跳指向清洗设备的回注接口。这样无论正常路由表怎么变化，服务器的回程流量一定会原路返回清洗设备，再由清洗设备转发给真实客户端。

这里有一个极易忽略的细节：策略路由必须同时考虑清洗设备本身的源地址。如果清洗设备与服务器之间还有健康检查、监控探针等流量，这些流量的源地址是清洗设备自身的管理IP或接口IP，不能也被策略路由强行送回清洗设备自己，否则会造成这类流量在接口间死循环。正确的做法是在策略路由的ACL匹配条件中，明确deny掉清洗设备自身发出的流量源地址，只匹配被防护业务的真实服务器IP作为源。

回注链路上的ACL控制不是可有可无的附加项，而是决定防护效果和安全边界的关键手段。三个位置必须部署ACL：清洗设备出方向、回注流量进入核心网络前的入方向、以及服务器前端交换机的入方向。

清洗设备出方向的ACL主要承担“白名单”职责。理论上清洗设备已经把攻击流量过滤干净了，但现实中清洗设备本身可能存在漏判，或者某些攻击流量伪装成正常协议穿透了清洗规则。出方向ACL要根据业务实际开放的协议和端口，严格限制回注流量的特征。比如业务只提供TCP 443端口服务，那么回注ACL就应该只放行目的端口为443的TCP流量，其余全部丢弃。这个ACL要配置在清洗设备的回注物理接口或逻辑子接口的出方向，作为最后一道防线。

核心网络入方向的ACL则是为了防止回注流量被利用进行反射攻击。假设清洗设备被入侵，攻击者可以通过清洗设备向核心网络内部注入任意流量。在核心路由器接收回注流量的接口入方向，必须配置反向路径转发检查或者严格的源地址过滤。如果回注流量的源地址是互联网上的真实客户端地址，那么这些源地址不应该出现在核心网络内部接口的入方向。因此，核心路由器应该只允许源地址属于互联网地址段的流量从清洗设备接口进入，拒绝源地址为内网地址、保留地址或广播地址的流量。这个措施能有效阻断利用回注通道发起的内部渗透。

服务器前端交换机的入方向ACL则要解决一个更精细的问题：防止清洗设备本身成为攻击跳板。清洗设备在回注流量时，如果目标服务器前面还有一层交换机，这台交换机应该配置端口ACL，只允许来自清洗设备特定接口MAC地址的流量进入服务器网段，拒绝其他MAC地址的流量。这样即使有人伪造了清洗设备的IP地址，也无法通过MAC地址的校验。

当清洗设备和目标服务器不在同一个二层网络甚至不在同一个数据中心时，GRE隧道回注是常见方案。清洗设备将清洗后的流量封装进GRE报文，外层源地址是清洗设备出口IP，外层目的地址是服务器前端路由器的IP，内层报文保持原始客户端到服务器的通信内容。这种方式可以跨越中间网络，避免在每一跳都配置复杂的路由策略。

但GRE隧道回注会带来新的ACL问题。中间网络的路由器和防火墙只能看到GRE封装后的外层头部，无法对内层流量进行有效过滤。如果清洗设备被攻陷，攻击者可以把任意恶意流量封装在GRE隧道里，直接穿透中间网络的所有安全策略，直达服务器内部网络。因此，在GRE隧道终结点，也就是服务器前端路由器上，必须在隧道解封装后的虚拟接口上配置严格的入站ACL。这个ACL要检查内层流量的源地址、目的地址、协议和端口，逻辑上与清洗设备出方向ACL保持一致，相当于把安全边界从清洗设备延伸到了隧道终点。

路由层面，GRE隧道的建立需要保证隧道两端路由可达，但不能让隧道本身的路由影响到正常流量路径。通常的做法是使用独立的逻辑接口建立隧道，隧道接口不参与IGP，只配置静态路由指向对端。清洗设备上的回注路由下一跳指向隧道接口，而不是物理接口。服务器前端路由器上则配置策略路由，将来自隧道接口的流量强制转发给服务器网段，同时保证服务器的回程流量也进入隧道接口。这里的关键是隧道接口的MTU设置，封装GRE头部会增加报文长度，如果中间链路MTU不足会导致分片，而分片报文在很多安全设备上会被直接丢弃。因此隧道接口的IP MTU必须设置为中间链路MTU减去GRE头部长度，通常建议设置为1400字节以下。

大规模防护架构中，多个清洗节点同时工作，通过Anycast方式宣告相同的被防护地址。流量被最近的清洗节点吸引并清洗后，回注流量如何保证不跑到另一个清洗节点上形成二次清洗甚至环路，这是路由策略设计中最复杂的部分。

核心矛盾在于：清洗节点A回注的流量，目的地址是被防护服务器，而所有清洗节点都在宣告这条路由。如果回注流量经过的路由器恰好在另一个清洗节点B的覆盖范围内，节点B会再次把流量吸走，形成清洗环路。解决这个问题的根本方法是在回注流量上打标记，让其他清洗节点能够识别并放行。

具体实现上，可以在清洗设备回注流量时，在IP报文的DSCP字段或ToS字段设置特定值，比如DSCP 46。然后在所有清洗节点的入方向配置ACL或路由策略，匹配DSCP值为46的流量，直接按正常路由转发，不进入清洗流程。这要求清洗设备本身支持基于DSCP的策略路由，并且上游路由器能够识别并信任这个标记。另一种更可靠的方法是利用MPLS标签，在核心网络内部为回注流量分配专用LSP，通过标签转发来隔离清洗流量和待清洗流量。不过MPLS方案对网络基础设施要求较高，一般适用于运营商级或大型企业自有骨干网。

对于没有MPLS环境的场景，还可以使用源地址约束来避免环路。清洗节点A回注流量时，将源地址设置为清洗节点A独有的回注接口地址，而不是保持原始客户端地址。在服务器侧再通过SNAT还原。这样其他清洗节点看到源地址是节点A的回注地址，就可以通过ACL直接放行。这种方法的代价是损失了原始客户端源地址的可见性，需要在清洗设备上做好日志记录，以便事后溯源。

静态配置ACL和路由策略在业务频繁变更的环境下很容易成为瓶颈。一旦有新业务上线、服务器IP变更或端口调整，手工修改所有相关设备上的ACL和策略路由，不仅效率低下，还极易因遗漏造成防护缺口。自动化联动的核心思路是将清洗设备、路由器和交换机的策略配置统一抽象为模板，通过API或脚本实现联动下发。

清洗设备在检测到攻击并启动防护时，会生成一条包含被防护地址、业务端口、防护策略的清洗任务。这个任务信息应该通过清洗设备的管理接口或syslog推送到一个集中的策略编排系统。编排系统根据预先定义好的模板，自动生成对应的BGP路由宣告配置、策略路由ACL条目、以及各节点接口ACL规则，然后通过NETCONF、RESTCONF或设备厂商API下发到相关网络设备上。攻击结束后，清洗任务撤销，编排系统再自动回收这些配置，避免长期残留的策略条目影响正常业务或留下安全隐患。

在实施自动化时，必须注意配置下发的顺序和回滚机制。正确的顺序是：先下发服务器侧的策略路由和ACL，确保回程路径已经就绪；再下发清洗设备的出方向ACL；最后下发BGP路由宣告，开始牵引流量。如果顺序反了，流量先被牵引到清洗设备，但回程路径还没准备好，就会造成瞬时业务中断。回滚机制则要保证在任何环节下发失败时，能够自动撤销已下发的配置，恢复到防护前的状态，而不是留下一个半成品的策略环境。

流量回注的路由策略与ACL控制，本质上是在可用性、安全性和可维护性之间寻找平衡点。过于宽松的策略会导致安全边界模糊，过于严格的策略又可能误伤正常业务。真正有效的做法是理解每一台设备在回注链路中的角色，针对性地配置最小权限的ACL，同时用策略路由强制保证流量路径的对称性，再通过自动化手段解决运维复杂度。这三者缺一不可，任何单点上的疏忽，都会让前面投入的清洗能力大打折扣。