M9010防火墙策略相关问题

• 分开两条 drop 策略：rule2（匹配目的端口 2425/1801）、rule440（匹配源端口 2425），业务完全正常；
• 合并为单条 rule‑2，同一条 rule 内同时写service‑port tcp destination eq xxx + service‑port tcp source eq xxx，出现全网业务阻断；

重点：H3C Comware‑V7 service‑port 在同一条安全策略 rule 里面，同一个协议下同时配置 source 端口条件 + destination 端口条件，逻辑是【逻辑与】，不是逻辑或；和华为 USG 匹配逻辑不一样，这就是断网根源H3C。

1、匹配逻辑拆解（核心差异点）

分开两条 drop 策略（原始可用配置）

rule 2 动作drop service‑port tcp destination eq 2425 service‑port tcp destination eq 1801 service‑port udp destination eq 2425 rule 440 动作drop service‑port tcp source eq 2425 service‑port udp source eq 2425

• rule‑2：只要目的端口命中任意一个，就匹配本规则丢弃；
• rule‑440：只要源端口命中任意一个，就匹配本规则丢弃；

两条独立规则，各自条件独立，达到效果：源端口 2425 OR 目的端口 (2425/1801) 就丢弃，业务不受影响。

错误合并后的单条 rule（会断网）

rule 2 动作drop service‑port tcp destination eq 2425 service‑port tcp destination eq 1801 service‑port udp destination eq 2425 service‑port tcp source eq 2425 service‑port udp source eq 2425

H3C V7 安全策略规则逻辑： ①同一条 rule 内部，不同类型过滤条件之间是「与」；同一类过滤条件多个条目之间是「或」H3C。 ②service‑port属于同一个过滤条件类型；但一条 service‑port 语句同时携带 source、destination 时，源端口条件和目的端口条件必须同时满足（与）。

等价匹配逻辑（错误合并后）：

报文必须同时满足：（源端口 = 2425） 并且（目的端口是 2425 or 1801），才会被这条 drop 规则匹配丢弃。

⚠️关键副作用：绝大多数普通业务报文（上网、业务访问，客户端随机高位源端口，目的 80/443 等），不满足这条 drop 规则的 “源端口 2425 AND 目的端口列表” 条件，所以不会被 rule‑2 匹配！

但是！！！这条 rule‑2 里面已经配置了 service‑port 子条件，但是报文没有匹配上任何一条 service‑port，该 rule 直接不命中，继续往下匹配；不是问题直接原因。真正的坑：很多工程师会误以为 “写多个 service‑port 就是或”，实际语法上每一条service‑port protocol [source][destination]是一条完整五元组子条件。

补充：为什么华为模拟器复现不出断网： 华为 USG 安全策略：同一条策略下多个端口条件行为为逻辑或；H3C Comware V7 的service‑port语法行为与华为不一致，这是平台实现差异，不是 BUG华为。

真正导致全网断网的底层行为

你合并之后，多条独立service‑port tcp/udp xxx写在同一个 rule 里面： 每一条完整service‑port是一条独立的子匹配项，子条件之间为「或」，但是单条service‑port内部，source 和 destination 是「与」。

service‑port tcp destination eq 2425 #条件A：tcp目的=2425 service‑port tcp destination eq 1801 #条件B：tcp目的=1801 service‑port udp destination eq 2425 #条件C：udp目的=2425 service‑port tcp source eq 2425 #条件D：tcp源=2425 service‑port udp source eq 2425 #条件E：udp源=2425

理论上 A/B/C/D/E 之间是或，那为什么断网？ 👉现场真实高概率诱因：输入配置时，手误删除 / 丢失协议关键字；或者多条 service‑port 被设备解析合并为一条，变成：tcp 同时要求 source=2425 AND destination in (2425,1801)； 👉第二种高频现场：安全策略 rule 没有配置 source‑zone /destination‑zone！ 如果 rule‑2 没有配置源域、目的域，同时配置了 service‑port，当报文不匹配 service‑port 条件时，本 rule 不匹配；但是如果配置解析异常，service‑port 被全部识别为空，一条 drop 规则没有任何过滤条件，会匹配所有报文，直接全部丢弃，全局断网H3C。

排查验证命令，看设备实际解析出来的匹配条件：

display security‑policy match‑conditions rule‑id 2

这条命令可以直接看到设备解析出来这条 rule 实际生效的五元组匹配条件，确认是 “与” 还是 “或”。

2、正确的两种改写方案（实现：源端口 2425 OR 目的端口 2425/1801 就丢弃，等价原始两条策略效果）

方案一：保留两条规则（推荐，可读性最好，不易踩坑，生产首选）

rule 2 name 禁止‑飞秋‑目的端口 logging enable counting enable service‑port tcp destination eq 2425 service‑port tcp destination eq 1801 service‑port udp destination eq 2425 action drop rule 3 name 禁止‑飞秋‑源端口 logging enable counting enable service‑port tcp source eq 2425 service‑port udp source eq 2425 action drop

方案二：如果一定要合并为一条 rule，使用服务对象组（object‑group service），不要用多条 service‑port 命令写在同一条 rule

service‑port 命令不适合做复杂多条件或；使用服务对象组，把所有要阻断的五元组全部定义进去，rule 引用对象组，对象组内部成员之间天然逻辑或。

#1.创建服务对象组 object‑group service block‑feiqiu service‑port tcp destination eq 2425 service‑port tcp destination eq 1801 service‑port udp destination eq 2425 service‑port tcp source eq 2425 service‑port udp source eq 2425 #2.安全策略rule引用对象组 rule 2 name 禁止‑内外部飞秋端口全阻断 logging enable counting enable service object‑group block‑feiqiu action drop

✅对象组内部各个 service‑port 成员之间逻辑是或，达到 “满足任意一条就匹配”，等价原始两条独立 rule 效果。

3、现场排障核查要点

1. 执行 display security‑policy match‑conditions rule‑id 2，看设备实际解析的匹配条件，确认是否出现同时强制源端口 + 目的端口 “与” 条件；
2. 确认 drop 规则必须带上source‑zone / destination‑zone，不要写成 any‑any 不带域条件，防止解析异常后匹配全部报文；
3. Comware V7 安全策略：同一条 rule 里面，尽量避免混合配置带 source、带 destination 的多条 service‑port，改用 service 对象组实现多条件 “或”；
4. 动作 drop 不要忘记写！如果 rule 只配置匹配条件，忘记 action drop，该规则默认 permit，或者行为异常；
5. 修改策略后，查看策略命中计数 display security‑policy statistics rule‑id 2，看飞秋流量是否被计数命中。

4、核心总结

1. H3C M9010 V7 安全策略：单条service‑port子命令内，source 端口和 destination 端口条件是逻辑「与」；同一个对象服务组内多个 service‑port 成员之间才是逻辑「或」，和华为 USG 实现不一样，不能直接照搬配置习惯；
2. 不要在一条 rule 下堆砌多条混杂 source/destination 的service‑port xxx；要合并条件优先使用object‑group service服务对象组；
3. drop 规则务必配置源 / 目的安全域，不要省略域条件，防止解析异常后匹配全部流量造成全局断网；
4. 不要忘记写 action drop，只写匹配条件不写动作会产生不可预期行为。

整合后全局断网，原因是策略匹配逻辑变化导致流量被误拦。原两条策略分别针对不同方向或源，整合后可能将源、目的、服务等条件合并，使正常业务流量也命中拒绝规则。
排查步骤：
1. 确认整合后策略的具体配置，重点检查源/目的地址、服务端口、动作是否为deny。
2. 查看会话日志，确认被阻断流量的五元组信息：
display logbuffer | include "deny"
3. 检查策略匹配顺序，确认整合策略是否覆盖了正常业务：
display security-policy ip
4. 若策略中使用了any源或any目的，需确认是否误伤管理流量或业务流量。
关键命令：
查看策略命中计数：
display security-policy statistics
查看会话表确认阻断：
display session table verbose | include "deny"
建议：
保持策略分离，避免将不同方向的拒绝规则合并。
整合时明确源、目的地址范围，避免使用any。
若需合并，确保服务端口和方向逻辑与原策略一致，例如原策略分别针对“内到外”和“外到内”，整合后需用源/目的区分，而非简单合并端口。