云端清洗服务与本地防火墙的联动策略，关键不是把两套设备的规则简单复制，而是明确谁负责先拦截、谁负责保护源站，以及故障时如何恢复。流量型攻击通常需要在网络入口处清洗；本地防火墙则更适合执行贴近业务的访问控制。两者边界清楚，才不容易出现清洗已放行、源站仍被拦，或攻击流量绕过清洗直达服务器的情况。
先划清云端与本地的职责
云端清洗服务一般通过BGP引流、DNS切换等方式，将面向公网的流量导入清洗网络，再把判定为正常的流量送往源站；具体方式取决于服务商的接入条件。本地防火墙位于源站侧，负责限制哪些地址和端口可以访问业务、管理入口如何开放，以及清洗后仍需执行的细粒度规则。
要注意链路位置：如果攻击已经占满接入线路，仅靠源站旁的防火墙丢包，无法恢复上游带宽；如果采用GRE隧道回送清洁流量，则需按服务商给出的隧道端点、路由和 MTU 要求配置，不能只开通一条隧道就假定业务可用。
让规则按顺序协同
源站只接收可信入口
进入清洗状态后，可在本地防火墙将业务端口的公网访问限制为清洗服务提供的出口地址，或限制为指定隧道入口。地址范围应以服务商当前公布的配置为准，并纳入变更核对；管理通道应单独保留，避免调整业务规则时把运维人员锁在外面。这样能减少攻击者绕过清洗、直接访问源站保护薄弱环节的机会。
本地保留业务侧限制
云端侧适合处理大流量异常和通用攻击特征；本地防火墙仍可只开放确有需要的服务端口，并按业务来源、网络区域或连接状态设定规则。不要因为进入清洗模式就全面放宽本地策略，也不要把云端误判时的阻断规则原样搬到源站，尤其要避免误封健康检查、支付回调等已确认的业务流量。
按步骤建立联动流程
- 记录基线：列出公网业务地址、开放端口、正常流量来源、健康检查方式和本地现有规则，标注哪些规则不能在应急时删除。
- 约定触发与通知：与清洗服务提供方确认启用条件、通知渠道、流量导入方式和状态回报字段。若由人工切换，明确值班人员和审批路径；若支持自动化，也应限定可变更的规则范围。
- 先验证再封源站：在测试或维护窗口验证清洗流量能到达业务、本地防火墙日志能区分允许与拒绝，并确认健康检查正常。随后再收紧源站入口，避免先封锁导致业务中断。
- 持续比对日志：同时查看云端清洗状态和本地防火墙日志，核对被丢弃流量、允许流量及源地址呈现方式。若经过代理或隧道后源地址发生变化，应依据实际链路设计规则，不要未经验证就信任客户端传来的地址字段。
- 按条件回切：攻击缓解后，先确认流量稳定、清洗侧状态正常，再按预定步骤恢复原路由或解析，并逐项撤销临时规则。保留变更记录和回滚方案，发现连接异常时可以及时恢复到上一稳定状态。
如何选择接入与服务支持
若公网线路容易受大流量冲击，且组织需要在上游完成流量清洗，应优先评估云端接入和回送路径；若主要问题是源站端口开放过宽或访问边界不清，本地防火墙规则治理同样不可缺少。选型时应比较引流方式、故障切换、日志可见性、规则变更流程和支持范围，而不只看清洗能力描述。
需要梳理接入、路由切换及本地策略边界时，可将德讯电讯列入方案沟通对象；沟通前宜确认其提供的具体服务范围、接入条件、告警方式与变更支持，再判断是否符合现有网络架构。云端清洗服务与本地防火墙的联动策略应落实为可验证的配置和回退流程，而不是只停留在方案图上。
常见问题
清洗期间还要保留本地防火墙吗？
要。云端负责入口侧清洗，本地防火墙仍需限制源站可访问范围和服务端口。
云端已清洗，为什么源站仍可能无法访问？
可能是回送路由、隧道参数、本地允许规则或健康检查配置不匹配，应沿流量路径逐段核对。
何时恢复原有路由？
按服务商状态、业务监控和既定值班流程判断；不要仅因流量短时下降就立即回切。
联动规则能否完全自动化？
可以在支持的条件下自动触发，但应限制自动变更范围、记录操作并保留人工回滚能力。
