#信服智创#【项目案例】从"光纤一断全网瘫痪"到"双链路无感切换"：某制造企业安恒防火墙替换全流程复盘

信服智创 | 参与得豆！2026技术征文大赛正式启幕！

目录：
一、项目背景
二、问题分析
三、方案设计
四、架构设计
五、简要实施过程
六、优化效果
七、典型问题复盘
  1.端口映射正常，但业务异常（范围端口映射）
  2.访客网络无法访问SSL VPN（非对称路由）
八、项目总结






一、项目背景
客户为某制造企业，现网出口采用双区域架构：
电信专线：承载办公及核心业务访问（主业务链路）
移动专线：承载物联网及访客网络（物理隔离）


基础拓扑如下：
电信专线 → 业务防火墙 → 核心交换机 → 办公/生产终端
移动宽带 → 路由器 → 交换机 → 访客/物联网终端




二、问题分析
随着业务发展与外部环境变化，逐步暴露出以下问题。
1.链路稳定性问题逐渐放大
公司周边施工频繁，电信光纤多次被挖断。现网应对方式为：
人工切换：将移动宽带接入业务防火墙临时顶替


实际运行中存在明显问题：
①切换依赖人工，恢复时间不可控（通常10–15分钟）
②业务中断不可避免，影响生产及办公连续性
③运维压力大，存在误操作风险


本质问题：
缺乏链路层面的自动化调度与健康检测机制，无法实现链路故障的快速感知与自动切换


2.设备能力与安全能力不足
①原出口设备为安恒明御安全网关（2020年部署）  
②上网行为管理能力较弱，难以进行细粒度策略控制  
③安全规则库长期未更新，防护能力持续下降  
④硬件性能老化，维保已过期，存在运行风险


本质问题：
设备仍在运行，但安全能力已“失效”


3. ssl vpn接入能力受限
①终端支持不完整：仅支持Windows、Android，无法覆盖iOS等移动办公场景，限制管理层及部分业务人员使用
②接入体验不稳定：在公网链路波动或切换时，VPN连接易中断，缺乏链路级保障机制


本质问题：
SSL VPN作为远程接入能力，处于“附属功能”状态，缺乏稳定性保障





三、方案设计
本项目的核心，不是简单替换设备，而是：
在成本、风险、能力之间做取舍


方案评估过程
实际落地前，我们评估了三种路径：


方案A：原厂升级
优点：改造成本低
问题：行为管理能力与链路调度能力仍不足、扩展性差
结论：适合短期缓解，不具备长期价值


方案B：双防火墙HA架构
优点：设备层高可用
问题：无法解决链路中断问题、成本提升明显
结论：解决“设备单点”，但未解决“链路单点”


方案C：单AF + 多链路调度（最终选择）
核心思路：
用“链路智能”替代“设备冗余”


采用一台深信服AF作为出口核心设备，重点利用其能力：
①链路健康探测（ICMP / DNS / 自定义目标）
②基于策略的选路与自动切换
③内置上网行为管理
④SSL VPN多终端支持（Windows / Android / iOS）




四、架构设计
1.出口结构：
电信专线（主链路）
联通专线（备链路 + 分流）
移动宽带（应急兜底）


2.流量调度策略
核心思想：不同业务，不同路径策略
① 服务器流量（稳定优先）
优先走电信
电信异常/探测失败 → 自动切换联通
探测目标优先选择公网稳定地址 + DNS地址组合，避免单一探测误判，连续3次失败触发切换


② 用户上网流量（利用率优先）
电信 + 联通负载均衡
实际调整过程中，对部分业务（如视频、下载）做了链路倾斜，避免挤占主链路资源


③ 极端场景兜底机制
双专线异常 → 手动接入移动宽带
该方案虽为手动，但作为三层兜底已足够




五、简要实施过程
1.割接前准备：配置梳理
原防火墙：
①NAT规则：50+条
②存在问题：冗余策略、端口混乱、命中率不可见
③ 处理策略不是“迁移”，而是：梳理 → 分类 → 重构


关键动作：
①删除无效策略
②合并重复规则
③ 标记关键业务流量




2.新设备配置
在AF上采用“重建式配置”：
①接口与网络重新规划
②NAT规则结构化设计（按业务分类）
③ 安全策略分层（业务控制策略 / 上网管控策略）


这一点非常关键：
很多问题不是“迁移失败”，而是“把旧问题带到了新设备”。




3.割接切换
①选择夜间低峰期进行：原设备保留、不关机（作为回退）
②分阶段验证：内网连通性、外网访问、VPN接入




4.实施结果：
①大部分业务仅在切换过程中短暂中断（个别端口映射例外）
②切换过程可控




六、优化效果
1.可用性提升
①链路切换：人工 → 自动
②故障恢复时间：10–15分钟 → 5–10秒


2. 带宽利用率提升
①原：单链路高峰约80%
②现：双链路均衡约40%~70%


3. 运维复杂度降低
①不再依赖人工切换链路
②策略结构清晰，维护成本明显下降


4. 公网访问体验优化
采用“双出口 + 智能DNS（阿里云）”：
①电信用户 → 电信链路接入
②联通用户 → 联通链路接入
有效降低跨网访问延迟。




七、典型问题复盘
1. 端口映射正常，但业务异常
现象：端口可访问、部分业务连接异常


排查过程：
①排查安全策略 → 正常
②排查链路 → 正常
③ 抓包分析 → 发现端口不固定


根因分析：
NAT规则中配置了“端口转换为端口范围”，导致端口随机映射，破坏一对一关系。


解决方案：
①删除端口范围配置
②使用默认一对一映射


经验总结：
涉及端口范围映射时，如无明确需求，应避免使用端口随机转换。




2. 访客网络无法访问SSL VPN接入地址（非对称路由）
现象：
使用访客网络（移动宽带）访问SSL VPN地址


表现为：
IP不通，VPN无法建立连接

排查过程：
①本地网络正常，可访问公网
②检查AF策略与端口监听 → 正常
③排查公网访问路径 → 无异常
④抓包发现请求能到达，但无响应


根因分析：
①多出口环境下出现回程路径不一致（非对称路由）：
②请求从电信/联通进入
③回包从移动链路发出
④源地址不匹配，客户端丢弃


触发原因：
AF配置中引入了移动链路作为应急备用出口


解决方案：
通过策略路由+调整路由优先级，固定回包路径


经验总结：
①在多链路环境中，“能出去”不等于“能回来”
②任何公网服务（如VPN/端口映射）都必须保证回程路径一致，否则必然出现连接异常。




八、项目总结
本次改造的核心价值在于完成了三个转变：
①从“单链路依赖” → “多链路调度”
②从“人工应急” → “自动容灾”
③从“策略堆叠” → “结构化管理”


在制造业场景中，出口防火墙不仅是安全设备，更是业务连续性的关键控制点。
本项目的关键不在于设备替换本身，而在于：
对现网的理解深度 + 割接过程控制能力


该项目验证了一点：在出口改造中，
“链路冗余设计”优先级应高于“设备冗余设计”，

否则即使设备高可用，业务仍可能中断。