整墙迁移：用 API 脚本把一台华为防火墙搬到奇安信

决定：写脚本调 API#

奇安信的 Web 管理界面背后是一套 HTTP API。既然界面能做的事 API 都能做，那就不该用手点。

整个迁移拆成了几个独立脚本，每类对象一个：

1
qax_login.py          # 登录、拿 token、维持会话
2
qax_migrate.py        # 地址对象、服务对象
3
qax_migrate_routes.py # 静态路由
4
qax_migrate_policy.py # 安全策略
5
qax_migrate_nat_sec.py# DNAT / SNAT
6
qax_pbr_schedule.py   # 策略路由与时间对象
7
qax_full_audit.py     # 迁移后全量审计

这么拆有个直接好处：每一类都能单独重跑。 迁移不是一次成功的，是跑 → 看报错 → 改 → 重跑。如果写成一个大脚本，每次都要从头来。

数据源是从华为侧导出的配置（display current-configuration 的各个分段），脚本负责把华为的语法翻译成奇安信 API 的 JSON。

最花时间的不是搬，是对账#

真正的难点是怎么确认搬完了、搬对了。

所以写了 qax_full_audit.py——它不做任何修改，只把新墙上的实际配置全量拉下来，逐项对照检查，输出一份审计报告：

1
### 关键业务地址检查
2
  [OK]   telecom_ip: 183.x.x.x 在 ge7, type=static, zone=untrust
3
  [WARN] 183.x.x.x 类型为 static，SSL VPN 通常需要 float
4
  [OK]   unicom_ip:  202.x.x.x 在 ge5, type=static, zone=untrust
5
  [FAIL] 缺少关键地址 trust_ip=10.x.x.x

[OK] / [WARN] / [FAIL] 三级，跑完一眼就知道还差什么。

DNAT 另外单独出了一张 CSV 对照表，19 条逐条列出：名称、协议、公网 IP、公网端口、内网 IP、内网端口、入接口、状态。这张表是交付物——之后谁来接手，看这张表就知道每条映射对应哪个业务（qms、mes、NAS、AI-server、FTP、回调接口……），而不是对着一堆端口号猜。

踩到的坑#

接口地址类型 float vs static。 SSL VPN 要求承载接口的地址类型是 float，而迁移脚本按华为侧的静态配置写成了 static，结果隧道死活建不起来。这种约束不在文档显眼处，是审计脚本的 [WARN] 提示出来的——这就是写审计脚本的价值，它会告诉你”能通但不对”的地方。

API 也有边界。 证书上传接口 /upload 一直返回 403，试了几种方式都不行。最后认了：SSL VPN 的服务器证书在 Web 界面上手动传，两分钟的事。

自动化不是目的。能自动的自动掉，剩下的老老实实手工做完并记录下来，比死磕一个接口划算得多。

管理口不能动。 迁移全程 ge1 管理口保持原样不改——这是唯一一条退路。改了它，一旦配置出错就只能去机房。

双 ISP 与策略路由#

新墙上电信、联通各一个 untrust 接口，各带一条默认路由；12 条 PBR 按源地址指定出接口，把不同网段、不同业务分流到不同运营商。SNAT 四条分别对应电信、联通、SD-WAN 和默认。

这套东西的正确性没法靠”能上网”验证——得逐条源地址去 traceroute 看走的是哪个口。 审计脚本把 PBR 表和路由表一起打出来，比在 Web 界面上翻页对照快得多。

SSL VPN 迁移#

老墙上两个虚拟网关：一个走电信口 1443 端口、network-extension 模式、地址池 10.10.80.0/24，通到内网；另一个走联通口 9443、split 模式。角色分三种权限。

新墙上对应重建了地址池、本地用户和放行策略（VPN 客户端网段 → trust 区）。

VPN 这块的教训是：先确认接口地址类型，再建隧道。 顺序反了就得把隧道删了重来。

值不值#

从”决定写脚本”到”审计报告全绿”，比手点省了大概两天，但真正的收益不在这里：

• 可重复：中途配置错了，改脚本重跑一遍就行，不用回忆刚才在界面上点了什么
• 有据可查：迁移日志是 JSONL 的，每条操作的请求和响应都留着
• 交付物是文档不是记忆：审计报告 + DNAT 对照表 + 完整清单，接手的人不用来问我

做了这么多年网络，越来越觉得会写点代码对网络工程师的意义，不是转行去做开发，而是把这类”量大、重复、易漏”的活变成可重复执行的东西。