网站海外访问线路与DDoS清洗节点的协同

做海外业务的技术团队经常会陷入一个怪圈：花大价钱买了全球加速线路，用户访问速度确实快了，但DDoS攻击一来，整条线路瘫掉，连带正常用户一起遭殃。另一种情况是，清洗节点部署得很完善，攻击流量扛住了，但正常用户的访问却因为路由绕行变得奇慢无比，业务照样受损。问题的根源在于，海外访问线路和DDoS清洗节点在架构设计上往往是两条独立的技术栈，缺乏协同机制。

海外访问线路追求的是低延迟、高吞吐，通常采用BGP Anycast或智能DNS将用户流量引导至最近的边缘节点，然后通过专线回源。DDoS清洗节点的工作逻辑则是先牵引流量、再检测清洗、最后回注干净流量。当攻击发生时，如果清洗节点和加速线路没有协同，就会出现流量先经过加速节点，发现是攻击后再转去清洗中心，这个“发现-转送”的过程本身就消耗了加速线路的带宽资源，等于攻击流量已经打到了你的加速基础设施上。正确的做法是让清洗节点前置，在流量进入加速网络之前就完成过滤。

理想的协同架构应该是“清洗前置、加速后置”。具体实现上，可以在BGP宣告层面做文章。正常情况下，你的IP段由加速线路的AS号对外宣告，用户流量自然流入加速网络。当监测到攻击流量超过阈值时，自动触发路由切换，将受攻击IP段的BGP宣告切换到清洗中心的AS号上。这样所有发往该IP的流量，无论来自哪个国家或地区，都会先进入清洗中心，经过清洗后再通过内部专线回注到你的加速网络中。这个切换过程需要控制在秒级，否则业务中断时间过长就失去了意义。

实现这套机制的关键在于BGP Community属性的运用。你可以在加速网络和清洗中心之间建立对等互联，通过设置特定的Community值来控制路由的宣告范围和优先级。比如正常状态下，加速网络宣告的路由附带no-export community，确保只在局部范围内传播；攻击状态下，清洗中心宣告更具体的路由前缀，利用最长掩码匹配原则让流量优先进入清洗设备。这里给出一段简化的路由策略配置思路，以Juniper设备为例：

policy-statement ddos-mitigation {
    term normal-state {
        from {
            route-filter 203.0.113.0/24 exact;
        }
        then {
            community add normal-acceleration;
            accept;
        }
    }
    term under-attack {
        from {
            route-filter 203.0.113.0/24 exact;
        }
        then {
            community add scrub-center;
            local-preference 200;
            accept;
        }
    }
}

这只是一个逻辑示意，实际生产环境中需要结合流量检测系统的API来动态调用不同策略。关键在于让路由决策和攻击检测形成闭环，而不是靠人工判断后再去改配置。

除了BGP层面的协同，DNS策略同样重要。很多团队习惯用统一的DNS解析把全球用户指向同一组IP，这在平时没问题，但遭遇攻击时灵活性很差。更合理的做法是基于地理位置的DNS分区域解析，同时结合端到端的健康检查。比如你可以将海外用户划分为北美、欧洲、东南亚等区域，每个区域分配不同的加速节点IP，同时为每个IP绑定对应的清洗节点作为备份。

健康检查不能只做简单的ICMP Ping，那玩意儿太容易欺骗。需要针对业务特征做应用层探测，比如HTTPS服务的证书有效性检查、特定API端点的响应码验证。一旦某个区域的加速节点因攻击导致可用性下降，DNS服务器要在30秒内将该区域的解析切换到清洗节点的IP上。这里的关键参数是TTL，建议在攻击高发期将A记录的TTL降到60秒甚至30秒，虽然会增加DNS查询量，但换来的是更快的切换速度。

海外清洗节点和国内清洗节点面临的环境差异很大。国内BGP网络相对集中，三大运营商互联互通虽有瓶颈但总体可控。海外则完全不同，你需要面对几百个Tier 1和Tier 2运营商，不同地区的网络拓扑和互联关系错综复杂。选择海外清洗节点时，不能只看厂商宣传的清洗容量，更要关注其网络覆盖范围和Peering关系。

一个实用的判断标准是看清洗节点在目标市场的接入点数量。比如你的用户主要在东南亚，那清洗节点最好在新加坡、雅加达、曼谷等地有物理接入点，并且和当地的Telkomsel、AIS、Globe等主流运营商有直连Peering。否则清洗后的干净流量回注时还要绕行香港或东京，延迟直接翻倍。另外要关注清洗节点的国际带宽储备，很多区域性清洗厂商在本地区还行，但跨大洲的带宽有限，一旦遇到大流量攻击，清洗能力够但回注带宽不够，照样丢包。

清洗设备和加速设备在处理TCP连接时的逻辑不同。清洗设备为了抵御SYN Flood攻击，通常会启用SYN Cookie机制，不保存连接状态，靠算法验证客户端的真实性。但加速设备为了提高转发效率，需要维护完整的连接状态表。如果清洗后的流量直接交给加速设备，加速设备看到的是大量没有经过三次握手的TCP包，可能会当成异常流量再次丢弃。

解决这个问题需要在清洗节点和加速节点之间建立信任通道。一种方案是在清洗设备上配置白名单，将加速节点的回源IP标记为可信，清洗设备对发往这些IP的流量不做SYN Cookie验证。另一种方案是在两者之间使用隧道封装，比如GRE或VXLAN，将清洗后的原始数据包封装后发给加速节点，加速节点解封装后直接转发，不关心内层TCP状态。第二种方案更彻底，但会引入额外的封装开销，需要评估MTU和分片问题。

协同不仅仅是流量转发的协同，还包括数据层面的协同。加速节点和清洗节点各自产生大量日志，但格式和维度通常不一致。加速节点关注的是RTT、丢包率、吞吐量等性能指标，清洗节点关注的是pps、攻击类型、过滤规则命中次数等安全指标。如果把这些数据放在一起分析，能发现很多有用的信息。

比如你可以通过对比攻击发生前后加速节点的流量画像，识别出攻击流量的源IP分布、协议特征、包长规律，然后把这些特征反哺给清洗节点的规则引擎，实现更精准的过滤。反过来，清洗节点发现的恶意IP库也可以同步给加速节点的访问控制列表，在边缘直接拦截已知的攻击源。这种双向的情报共享需要一套统一的日志采集和分析平台，建议使用Elasticsearch加Kafka的组合，把两边的日志都打到同一个集群里，用Grafana做可视化关联分析。

协同架构做得好，能直接省钱。很多海外加速线路的计费模式包含95计费或按峰值带宽计费，攻击流量如果打到了加速线路上，哪怕只有几分钟，也可能把整月的95峰值拉高，导致费用暴涨。通过前置清洗把攻击流量挡在加速网络之外，等于保护了你的计费基数。另外，清洗服务本身也有成本，按清洗流量计费或按月租计费，你需要根据业务攻击频率来算账。如果攻击频繁但每次流量不大，月租模式更划算；如果攻击稀疏但每次流量巨大，按量计费更合适。协同架构允许你灵活调整清洗节点的投入，攻击时启用更多清洗资源，平时只用基础覆盖，这种弹性调度本身就是成本优化的手段。

第一个坑是路由收敛时间。BGP切换再快也有几秒到几十秒的收敛延迟，这段时间内流量还是走老路径。解决方案是提前预置备用路由，让清洗节点的路由始终存在于网络中，只是优先级较低，一旦主路由消失，备用路由立即生效，省去路由计算和传播的时间。

第二个坑是SSL证书问题。如果你的加速节点使用CDN厂商的SSL证书，清洗节点回注流量时可能会因为域名不匹配导致证书校验失败。需要在清洗节点上配置SSL透传或者使用自定义证书，确保证书链在整条链路上都有效。

第三个坑是源IP透传。清洗节点默认会替换源IP，导致源站看到的请求都来自清洗节点，无法做地域分析或IP黑白名单。一定要要求清洗厂商开启源IP透传功能，通常通过X-Forwarded-For头或Proxy Protocol实现，但要注意后端服务器是否正确解析这些字段。

海外访问线路和DDoS清洗节点的协同，本质上是在安全性和可用性之间寻找动态平衡点。架构设计上把清洗前置、加速后置，路由策略上实现自动化切换，DNS层面做细粒度分区域解析，数据层面打通日志和监控，成本层面做弹性调度。这些点都做到了，你的海外业务才能在攻击和正常访问之间游刃有余。