F1000-AK1150 防火墙 修改感兴趣流量后业务数据不通

NAT的ACL地址要拒绝这个新增的源目地址，

对端也需要添加这个感兴趣流

你这是 ACL 规则顺序 + NAT / 路由 / 策略联动 + 感兴趣流不对称 三重重叠导致的 “改一条全挂”，而且删规则也不会自动恢复。下面按根因→验证→恢复→根治来给你完整排查（F1000-AK1150，Comware V7）。
一、为什么只加一条 rule 15 就全断？（核心根因）
1）ACL 3005 是 IPsec 感兴趣流，规则顺序错了（最直接）
高级 ACL 是 从小到大匹配、匹配即停、末尾隐含 deny。
你原来 3005 里大概率有：
rule 10 permit ip 旧网段
rule 20 permit ip 其他网段
你插了 rule 15 → 导致：
某些流量匹配到 rule 15 后不再匹配后面的原有 VPN 规则
或 rule 15 与原有规则冲突 / 覆盖，导致所有流量都被 deny（因为末尾隐含 deny）
典型场景：
原 3005：rule 10 permit ip A B；rule 20 permit ip C D
你加：rule 15 permit ip 192.168.50.38 0 172.16.0.6 0
结果：某些原有流量匹配 rule 15 失败 → 掉到末尾 deny → 全断
2）IPsec 感兴趣流两端不对称（对端不变，你这边多了一条）
IPsec 要求两端感兴趣流必须镜像对称：
你本地：ACL 3005 多了 rule 15
对端：还是老 ACL，没有这条反向规则
结果：SA 虽然存在，但流量不匹配 / 被丢弃，ping 不通
3）防火墙NAT / 安全策略 / 路由被这条 rule 触发变更
ACL 3005 同时被 IPsec + NAT + 安全策略 引用
加 rule 15 后：
部分流量被 NAT 转换了（不该转的转了）
或安全策略拒绝
或路由递归变化，来回路径不一致，防火墙丢包
4）删 rule 15、reset sa 不恢复的原因
ACL 改完后，安全策略 / NAT / 会话表不会自动刷新
reset ike/ipsec sa 只清 VPN 表项，不清会话表、NAT 表、策略缓存
必须重新应用策略 / 清空会话 / 重加载 ACL 才会恢复
二、立刻验证（4 条命令，确认根因）
1）看 ACL 3005 完整配置与匹配计数
bash
运行
display acl advanced 3005
看 rule 15 是否在 原有规则中间
看 hit 计数：原有规则 hit 变 0 → 顺序问题
2）看 IPsec 策略引用的 ACL
bash
运行
display ipsec policy | include 3005
确认 VPN 感兴趣流就是 acl 3005
3）看会话表（关键：流量有没有进隧道）
bash
运行
display session table source 192.168.50.38 destination 172.16.0.6
无会话 → 被 ACL / 策略 deny
会话标记 NAT → 不该 NAT 却转了
会话标记 VPN → 进隧道但对端丢包
4）看安全策略是否放行
bash
运行
display security-policy source 192.168.50.38 destination 172.16.0.6
必须有 permit 规则
三、紧急恢复（不重启，5 步回滚）
1）删除 rule 15（你已做）
bash
运行
acl advanced 3005
undo rule 15
2）清空所有会话表（必做！）
bash
运行
reset session table all
3）重置 IPsec/IKE SA（必做）
bash
运行
reset ike sa all
reset ipsec sa all
4）重新应用安全策略（清缓存）
bash
运行
security-policy
save
quit
5）测试连通性
bash
运行
ping 172.16.0.6 source 192.168.50.38
四、正确添加 rule 15（避免再断）
1）调整规则顺序：精确在前，宽泛在后
bash
运行
acl advanced 3005
# 先删旧的，重新排序
undo rule 10
undo rule 20
# 新规则放最前面（精确匹配）
rule 5 permit ip source 192.168.50.38 0 destination 172.16.0.6 0
# 原有规则按范围从小到大
rule 10 permit ip source 旧网段 旧反掩码 destination ...
rule 20 permit ip source 其他网段 反掩码 destination ...
# 末尾确保没有 deny，或显式 permit
rule 99 permit ip
2）对端同步添加反向规则（关键！对称）
对端防火墙 / 路由器的感兴趣流 ACL 必须加：
bash
运行
rule permit ip source 172.16.0.6 0 destination 192.168.50.38 0
3）确认 NAT 不影响
bash
运行
display nat policy | include 3005
确保 VPN 流量 不做 NAT（nat 策略 deny 该流）
五、一句话总结 + 预防
根因：ACL 规则顺序错乱 + 感兴趣流不对称 + 会话表未清空。
预防：
改 VPN 感兴趣流 ACL 时，先备份、再清空重排、精确在前
两端 ACL 必须同步镜像
改完后 reset session table all + reset sa
测试流量 hit 计数，确认匹配正确

1. 核心排查：两端 ACL 是否严格“镜像”

• 排查点：你在 A 单位防火墙上添加了 rule 15 permit ip source 192.168.50.38 0 destination 172.16.0.6 0。请务必确认，对端 VPN 网关上，是否也同步添加了完全对应的镜像规则：permit ip source 172.16.0.6 0 destination 192.168.50.38 0。
• 故障原理：如果对端没有添加这条镜像规则，当 A 单位的 192.168.50.38 发起流量时，本端防火墙认为需要加密并发起协商，但对端防火墙认为该流量不在加密范围内而拒绝建立 SA 或直接丢弃，这会导致 IPSec SA 协商失败或建立不完整，进而可能拖累整个 VPN 隧道的正常转发。

2. 检查 NAT 策略是否排除了新增流量（极高频原因）

• 排查点：检查你的 NAT 策略。新增的 192.168.50.38 到 172.16.0.6 的流量，是否被现有的 NAT 规则“误伤”了？如果这条流量在进 VPN 隧道前被做了 NAT 地址转换，IPSec 校验会直接失败，导致业务不通。
• 解决建议：在 NAT 策略的最前面，添加一条优先级更高的规则，将源 192.168.50.38、目的 172.16.0.6 的流量设置为 no-nat（不进行地址转换）。

3. 检查安全策略（Security Policy）是否放行

• 排查点：检查从 GE1/0/4 所在的安全区域（例如 Trust）到 GE1/0/20/21 所在安全区域（例如 Untrust）的安全策略。是否明确放行了源 192.168.50.38 访问目的 172.16.0.6 的权限？
• 排查命令：在防火墙上开启安全策略的命中计数，观察该流量是否命中了允许的策略。

4. 清除残留的旧会话（Session）

• 故障原理：防火墙是状态检测机制。在故障发生期间，可能已经建立了错误的或半开的会话。即使你修正了配置或重置了 SA，旧的错误会话如果没有超时，流量依然会匹配旧会话而被丢弃。
• 解决建议：在系统视图下，执行命令 reset session table（清除所有会话表）或 reset session table source-ip 192.168.50.38（清除特定主机的会话），强制让业务流量重新建立连接。

5. 排查路由黑洞

• 排查点：确认 192.168.50.38 访问 172.16.0.6 的流量，其路由下一跳确实指向了建立 IPSec VPN 的出接口或虚拟隧道接口。如果路由指向了其他物理出口，流量将不会触发 VPN 加密。