|
从"光纤一断全网瘫痪"到"双链路无感切换" 某制造企业安恒防火墙替换全流程复盘
目录:
一、项目背景
二、问题分析
三、方案设计
四、架构设计
五、简要实施过程
六、优化效果
七、典型问题复盘
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/端口映射)都必须保证回程路径一致,否则必然出现连接异常。
八、项目总结
本次改造的核心价值在于完成了三个转变:
①从“单链路依赖” → “多链路调度”
②从“人工应急” → “自动容灾”
③从“策略堆叠” → “结构化管理”
在制造业场景中,出口防火墙不仅是安全设备,更是业务连续性的关键控制点。
本项目的关键不在于设备替换本身,而在于对现网的理解深度 + 割接过程控制能力。
该项目验证了一点:在出口改造中,“链路冗余设计”优先级应高于“设备冗余设计”,否则即使设备高可用,业务仍可能中断。 |