DDoS防御中的流量回注与源站真实IP隐藏

DDoS防御本质上是一场资源不对等的消耗战。攻击者用海量垃圾流量塞满你的带宽，而防御方要做的，就是把“脏数据”洗掉，只让“干净流量”抵达源站。在这个清洗过程中，流量回注和源站IP隐藏是两个紧密咬合的齿轮，一个负责把洗干净的流量送回正确的路径，另一个则从根本上拔掉攻击者瞄准的坐标。这两个环节如果出现短板，整个防御体系就会瞬间崩塌。

当DDoS攻击流量冲向目标时，高防节点或清洗中心会抢先接管这些流量。经过深度检测和过滤后，正常的业务请求需要被送回源站，这个过程就是流量回注。它不是简单的数据转发，而是一次路径重映射。回注的质量直接决定了正常用户是否能无感知地访问业务，延迟、丢包、连接中断往往都发生在这个环节。

常见的回注方式有几种，每一种都有自己适用的场景和代价。第一种是IP隧道回注，清洗中心将干净流量封装在GRE隧道包里，直接发往源站。源站解封装后拿到原始请求包，再正常响应。这种方式的好处是源站不需要改动网络架构，回注路径灵活，但隧道本身会带来额外的报文开销，MTU问题需要提前处理，否则大包会被分片，性能急剧下降。

第二种是二层专线回注，清洗中心和源站之间通过物理专线或MPLS VPN打通二层网络。清洗后的流量直接通过专线送回，不经过公网。这种方案的延迟最低、稳定性最高，适合金融、游戏等对延迟极度敏感的业务，但成本也最昂贵，扩展性受限。

第三种是策略路由回注，清洗中心直接把干净流量通过公网路由送回源站IP，但通过修改路由策略来避免被攻击者再次拦截。这种方式实现简单，成本低，但回注流量仍然暴露在公网上，存在被二次攻击或窃听的风险。实际部署中，很多企业会混合使用这些方案，核心业务走专线回注，非核心业务走公网策略路由，在成本和效果之间找平衡点。

回注过程中最容易被忽视的问题是会话保持。当清洗中心是多节点集群时，同一个用户的请求可能被不同节点处理，如果回注时没有做好会话同步，源站看到的可能是来自不同IP的请求，导致登录状态丢失或交易中断。解决这个问题需要在清洗层就维护会话表，确保同一会话的流量始终回注到源站的同一连接上。

很多人以为买了高防服务就万事大吉，但源站真实IP一旦泄露，攻击者完全可以绕过清洗中心直接打击源站。到那时，再强的高防也形同虚设。源站IP泄露的途径远比想象的多，而且往往是在不经意间发生的。

历史DNS记录是最常见的泄露源。很多网站在接入高防之前，域名直接解析到源站IP。即使后来切换到了高防IP，攻击者依然可以通过DNS历史查询服务找到之前的解析记录，轻松拿到源站地址。SSL证书也是重灾区，通过全网扫描证书指纹，攻击者可以反向关联出同一个证书部署在哪些IP上，其中就可能包含源站。邮件服务、API接口回调、文件外链这些业务功能，也经常在数据包或日志里直接暴露出源站IP。

更隐蔽的泄露途径是应用层的信息泄露。比如网站页面里的注释代码、错误页面返回的调试信息、WebSocket握手包里的内网地址，甚至是一封自动发送的注册确认邮件，邮件头里都可能躺着源站的真实IP。攻击者还会利用主动探测手段，向你的域名发送大量请求，同时监控哪些IP返回了相同的页面特征，以此定位源站。

真正有效的源站IP隐藏，不是做一个动作就完事，而是要构建一条完整的策略链，从网络层到应用层逐级设防。第一步也是最基础的一步，源站只允许来自清洗中心IP段的入站流量，其他所有来源一律在防火墙层面丢弃。这意味着即使攻击者知道了源站IP，他的请求包也根本到不了服务器网卡。这个策略需要在网络边界设备上配置白名单ACL，而不是依赖服务器上的iptables，因为流量到达服务器时带宽已经被消耗了。

第二步是彻底更换源站IP。在接入高防服务后，应该申请全新的、从未对外暴露过的IP地址作为源站。旧的IP必须彻底废弃，不能做任何形式的端口映射或备用。很多企业偷懒保留旧IP作为管理通道，结果被攻击者扫描出来一击即中。新IP部署后，要立即在防火墙上实施白名单策略，确保只有清洗中心的回注流量能进来。

第三步是封堵所有可能泄露IP的业务出口。邮件服务必须走独立的发送服务器，不能和源站共用IP。API对外回调要通过代理网关转发，让外部系统只能看到代理IP。DNS解析要全面切换到高防提供的解析服务，并开启解析记录锁定。SSL证书如果之前部署在源站上，更换IP后必须重新申请证书，旧证书要立即吊销，防止指纹关联。

第四步是应用层的深度伪装。源站的Web服务器要配置默认站点，对于非本域名的请求直接返回空白页面或拒绝连接，不能返回任何包含真实信息的错误页。响应头里的Server字段要修改或删除，PHP、ASP.NET等语言版本信息也要隐藏。页面代码中不能出现内网IP、开发环境地址等敏感信息。这些细节看似琐碎，但在攻击者的信息收集中，每一个小漏洞都可能成为突破口。

把流量回注和源站IP隐藏放在一起看，才能理解它们是如何协同工作的。一个典型的防御架构是这样的：用户请求首先到达高防节点的BGP宣告IP，这个IP是公开的，也是攻击者唯一能看到的地址。高防节点完成流量清洗后，通过预先建立的GRE隧道或专线，将干净流量回注到源站。源站的防火墙只允许来自清洗中心回注接口的流量进入，其他所有流量全部丢弃。

在这个架构下，攻击者面对的是一个完全封闭的回路。他能打到的只有高防节点的前端IP，而这个IP背后是巨大的清洗集群，攻击流量在这里被稀释和过滤。他永远无法触及真正的源站，因为源站根本不响应任何来自清洗中心以外的请求。即使攻击者通过某种手段猜到了源站IP，发送过去的请求包也会被防火墙直接丢弃，连TCP三次握手都建立不起来。

这套架构的关键在于几个硬性约束必须同时满足。清洗中心的回注流量必须来自固定的、可预期的IP段，否则源站防火墙无法配置精确的白名单。回注通道必须独立于公网，或者至少经过加密和认证，防止被中间人篡改。源站绝对不能有任何主动对外发起连接的行为，所有出站请求都必须通过代理，防止在反向连接中泄露IP。

在实际部署中，很多看似不起眼的配置错误会让整个防御体系功亏一篑。最常见的是源站防火墙白名单配置不完整。清洗中心在回注流量时，可能会使用多个源IP，如果漏配了某个IP段，部分正常用户的请求会被防火墙拦截，表现为间歇性无法访问。这种问题排查起来很痛苦，因为不是所有用户都受影响，很容易被误判为网络波动。

另一个高频错误是回注路径的MTU设置不当。GRE隧道会在原始报文外面加封装头，导致报文变大。如果路径中间的设备不支持分片或PMTUD被防火墙阻断，大包就会被丢弃。用户端表现为某些页面能打开，但上传文件或加载大图片时卡死。解决方法是降低隧道接口的MTU值，或者在清洗中心侧对回注流量做TCP MSS调整，从源头控制报文大小。

源站IP更换不彻底也是重灾区。有些企业在更换IP后，忘记更新内部DNS记录，导致内网部分系统仍然通过旧IP访问源站。攻击者如果通过社工或漏洞获取了内网访问权限，就能从内部DNS记录里发现源站新IP。还有CDN配置残留的问题，如果之前用过CDN服务，切换高防后没有清理CDN上的源站配置，攻击者可以通过CDN的回源机制探测到真实地址。

部署完成后，必须用攻击者的视角来验证防御效果。第一步是全面扫描自己的域名，用DNS历史查询工具检查是否有源站IP的解析记录残留。第二步是用全网扫描引擎搜索自己的SSL证书指纹，看是否能关联出其他IP。第三步是检查所有对外服务的响应头、错误页面、邮件头，确认没有泄露内部地址。第四步也是最直接的，从外部网络向源站IP发起请求，确认是否被防火墙正确阻断，连一个RST包都不应该返回。

对于流量回注的验证，需要在清洗中心侧和源站侧同时抓包分析。在清洗中心侧抓取回注前的流量，在源站侧抓取收到的流量，对比两者的报文内容是否一致，延迟是否在可接受范围内。特别要注意TCP序列号和确认号是否正确转换，会话状态是否保持。如果发现源站收到的请求源IP不是用户真实IP而是清洗中心IP，说明没有正确传递客户端原始地址，需要检查回注链路上的X-Forwarded-For头或Proxy Protocol配置。

这套防御体系的维护是一个持续的过程，不是一次配置就能一劳永逸。业务每增加一个新的对外功能，都要评估是否会引入新的IP泄露风险。清洗中心的回注策略也要随着业务流量模型的变化定期调整。只有把流量回注和源站IP隐藏当作一个动态的、需要持续运营的系统来对待，才能在不断升级的攻防对抗中保持优势。