Palo Alto 策略"不通"别瞎改规则：一个实施工程师的 10 分钟排障法

Palo Alto 策略"不通"别瞎改规则：一个实施工程师的 10 分钟排障法并不只看表面做法，关键还要理解相关条件、限制和后续影响。

Palo Alto 策略"不通"别瞎改规则：一个实施工程师的 10 分钟排障法

先说结论：排障顺序是这个

日志 → 命令验证 → 查 NAT → 查 App-ID → 抓包

别一上来就动规则。下面一步一步来。

第 1 步：先看 Traffic Log（最常被跳过的一步）

大部分人改了半天规则没用，是因为压根没看日志。

进 Monitor > Traffic，用源/目的 IP 过滤，重点看两列：

Action：是 allow 还是 deny？ Session End Reason：这列才是真相。

几个高频值你得认得：

Session End Reason	含义	说明
age-out	会话正常结束	策略其实是通的，问题大概率在应用层或对端
tcp-rst-from-server	对端主动拒绝了连接	不是防火墙拦的，去查目的服务器
tcp-rst-from-client	客户端自己断了	多半是客户端/链路问题
policy-deny	真被安全策略拒绝了	这才是策略问题，再去查规则

我见过太多次：日志里明明是 tcp-rst-from-server，现场却还在那加放行规则。看一眼日志，省半小时。

第 2 步：用命令行精准验证"到底命中了哪条规则"

不用真发流量，一条命令就能看某个五元组会匹配到哪条策略：

test security-policy-match source 10.1.1.10 destination 8.8.8.8 destination-port 443 protocol tcp

返回结果会告诉你命中了哪条规则、action 是什么。比肉眼数规则顺序靠谱得多——尤其是策略几百条的环境，肉眼数一定会数错。

如果返回的是 deny 或"no rule matched"（落到 default），再去对应改；如果返回的是正确的 allow，那问题就不在安全策略（回到第 1 步看 end reason）。

第 3 步：NAT 和安全策略是两码事

这是新手最容易混的坑。很多人把"访问不通"归罪于安全策略，其实是 NAT 没做或做反了。

记住 Palo Alto 的匹配逻辑：

安全策略默认匹配的是 NAT 转换之后 的目的 IP（egress 方向）。 所以排查顺序一定是：先确认 NAT 命中，再看 security policy。

实操：先在 Policies > NAT 里确认这条流量有没有被正确的 NAT 规则接住，再回来看安全策略。很多"策略怎么改都不通"，把 NAT 一条规则加上就好了。

第 4 步：App-ID 没识别导致的"假不通"

规则里写了 service = application-default 或指定了某个 App，结果流量被识别成 unknown-tcp，导致规则不匹配——看起来像"策略没生效"，其实是对应用识别失败。

排查和验证：

在 Traffic Log 里看 App 列，是不是识别成了 unknown-tcp / incomplete。 临时把规则的 Application 设成 any 验证一下：如果设成 any 就通了，那就是 App-ID 识别的问题。 常见原因：没做解密（SSL 流量识别不出应用）、App-ID 超时太短、或者本身就是非标准端口的私有协议。

第 5 步：实在查不出，上抓包

前面都排除了，还不确定包到底有没有过防火墙，就抓：

debug dataplane packet-diag set filter match source 10.1.1.10 destination 8.8.8.8debug dataplane packet-diag capture on（复现问题）debug dataplane packet-diag capture offshow capture

能看到包到底进没进、出没出防火墙接口。这一步基本是"最后手段"，前面几步通常已经能定位了。

收尾：记住这条线

日志看 end reason → 命令验证命中规则 → 确认 NAT → 排查 App-ID → 最后才抓包。

顺序对了，现场排障从"瞎改两小时"变成"十分钟定位"。这也是我每次上线前都会跟客户 IT 交代的——别慌，按流程来。

标签： #PaloAlto #防火墙 #网络安全 #运维 #安全实施 #排障