深度解析 PAN-OS 防火牆四大常見狀況：Commit 驗證失敗、GlobalProtect 連不上、流量走錯政策與 HA 主備異常，從機制講到 CLI 實戰指令，高雄企業適用。
先建立心智模型：candidate 與 running 不是同一份設定
要看懂 PAN-OS 的所有疑難雜症，得先接受一個觀念：你在 Web 介面上點來點去、改到手軟的那份，叫做候選設定（candidate），它只是暫存，對正在跑的流量毫無影響；真正在轉封包、比政策的是執行中設定（running）。按下 Commit，系統才會把候選設定完整驗證一遍，編譯成資料平面（dataplane）看得懂的結構，再原子性地替換掉舊的 running。這是一套交易式（transactional）的模型：要嘛整包成功，要嘛整包回退，不會做到一半卡在中間。
理解這點，很多現象就通了：為什麼你改完不 Commit 一切照舊？因為 running 沒動。為什麼大設定的 Commit 要跑一兩分鐘？因為它在背後重編整份政策、重建共享記憶體結構，規則越多、session 越滿，編譯越久。為什麼有時候明明改對了卻沒生效？常見是你根本忘了按 Commit，或是 Commit 失敗被打回，running 還停在舊版。把 candidate 與 running 的分野先弄清楚，後面的排查才不會鬼打牆。
Commit 失敗：先 validate，再看 job，最後比 diff
Commit 跳出 Validation Error 的當下，最忌諱的就是不看訊息、按了重來又重來。PAN-OS 給了你一個更聰明的入口：在設定模式下敲 validate full，它會把整份候選設定 parse 一遍，有問題直接點名是哪個物件、哪一行。與其賭運氣，不如讓它先告訴你錯在哪。
驗證常見的幾種出錯，列出來給你對照：
- 介面沒指派 zone：訊息類似 interface has no zone，任何 Layer 3 介面只要參與轉送就必須歸屬某個 zone，漏掉就過不了。
- 引用了不存在的物件：政策指到一個已被刪除或改名的位址、服務或應用群組，會冒出 is not a valid reference。改名的殺傷力最大，因為引用它的規則不會自動跟著改。
- Panorama 推送撞名：本地已有同名物件，Panorama 又從 shared 推了一份下來，就會看到 Duplicate 或 is already in use，這類要先決定以誰為準，不是硬 Commit 就能解。
- 配額或版本相依：某些功能要對應的授權或軟體版本，日誌儲存配額、內容更新沒到位，也會在 Commit 或推送階段被擋下來。
validate 或 commit 都會產生一個 job-id，拿它到操作模式敲 show jobs id 編號（或先用 show jobs all 找出那一筆），完整的錯誤明細就在裡面。接著回設定模式用 show config diff 把「這次實際改了什麼」攤開來對照，錯誤訊息配上差異，多數的 Commit 失敗當場就地解決。
還有一種卡關跟語法無關：訊息寫 Other administrators are holding device-wide commit locks。PAN-OS 有兩種鎖：config lock 擋別人編輯、commit lock 擋別人提交，常見於多人同時進後台，或啟用了自動取得鎖。規則很單純：只有 superuser 或當初上鎖那位管理者能手動移除，而正常情況下 Commit 一完成系統就自動釋放。Web 介面右上角點那個鎖頭圖示就能解，別急著重開機。
政策沒走對：top-down、first-match，還要防 shadow
「規則我明明寫了，流量就是不照走」，這是另一個大宗。關鍵在於 PAN-OS 的安全政策是由上而下、第一條符合就停（first match）。只要你把一條範圍很廣的規則擺在具體規則上面，下面那條想命中的永遠輪不到，這叫 shadow（遮蔽）。規則一多，人腦很難一眼看出遮蔽關係，這時就別靠肉眼硬看。
PAN-OS 有測試指令。想知道某條流量實際會落到哪一條規則，敲：test security-policy-match from trust to untrust source 來源IP destination 目的IP destination-port 80 protocol 6。輸出第一行引號裡就是真正命中的規則名。這裡有個新手最常忽略的地雷：zone 一定要帶對，from／to 寫錯，比對結果就完全失準，因為政策比對是先靠 zone 收斂範圍的。
但這個 test 有個邊界要記牢：它比的是靜態設定，不會跑 App-ID。真實 session 一開始只能靠埠號猜應用，可能先標成 incomplete 或用暫定的應用比一次政策；等封包夠多、App-ID 認出真正的應用，會發生 app shift，政策被重新評估，流量就可能改命中另一條。所以 test 說會走 A、實際 session 走 B，不是防火牆壞了，是動態辨識的正常行為。要看活的連線，敲 show session id 編號，輸出裡的 rule 欄告訴你命中哪條、application 欄告訴你被認成什麼，兩相對照真相立現。
還有一個坑會讓人找到抓狂：流量明明被擋了，Traffic log 裡卻一筆都找不到。常見是它命中了最底部的 interzone-default（跨 zone 預設拒絕）。這條隱含規則和它的兄弟 intrazone-default（同 zone 預設放行）預設都不寫 log，所以你當然看不到。要抓它，得把這條預設規則 override 出來、勾上 logging，被擋的封包才會現形。這一步做完，很多「查無此流量」的懸案就破了。
GlobalProtect 連不上：不是憑證，就是埠
使用者一回報 Could not connect to gateway 或 The server certificate is invalid，先按住想改帳號密碼的手：這兩個症狀常見跟認證無關，而是憑證或埠在作怪。
憑證這關，魔鬼藏在 CN／SAN
較新版本的 GlobalProtect App 會強制：Portal 裡設定的 gateway 位址，必須對得上 Gateway 憑證的 CN 或 SAN。實務上最常見的死法，就是 Portal 填 IP、憑證卻簽的是 FQDN，兩邊對不起來當場報憑證無效。解法是統一改用 FQDN，並確認內外部 DNS 都解得到。其他常見中招點還有：憑證鏈不完整（中繼憑證沒帶齊）、用戶端沒裝到 root CA、設備時間沒對 NTP 導致憑證被判過期或尚未生效。設定上的好習慣是 Gateway 與 Portal 共用同一個 SSL／TLS Service Profile，並在 Portal 的 Agent 設定把 Trusted Root CA 加進去、勾選安裝到本機根憑證儲存區，免得每台用戶端各自為政。
連線卡住，先查 UDP 4501 有沒有被擋
GlobalProtect 為了快，預設先走 IPSec（UDP 封裝的 ESP，埠 4501），失敗才退回較慢的 SSL（TCP 443）。它的判斷機制是這樣：app 每隔約 10 秒送一次 keep-alive，連續五次（約 50 秒）收不到 gateway 回應，就認定 IPSec 不通、退回 SSL。所以只要上游 ACL 把 UDP 4501 擋掉，使用者「連得上、卻永遠掉在較慢的 SSL」，體感就是慢、容易斷。設備前面的防火牆或路由 ACL，務必同時放行 TCP 443 與 UDP 4501。另外提醒一個容易被忽略的變因：當 gateway 掛在 NAT 後方（而非直接吃 WAN 介面），IPSec 退回 SSL 的機率會明顯升高，部署時要把這點算進去。IPSec 還怕 MTU 與分片問題：ESP 封裝會吃掉封包空間，若中間鏈路把分片擋了又設了 DF 位元，大封包就會神隱，這時調小 tunnel MTU 往往比查半天政策還有效。
要看認證實際過了沒，直接在操作模式敲 tail follow yes mp-log authd.log 盯認證日誌，Monitor 的 System log 也能用 subtype 過濾 globalprotect 與 auth。用戶端那側同樣有兩本帳可查：PanGPS.log 是服務層、PanGPA.log 是介面層，排錯時兩本一起攤開，才分得出實際是連線談不攏，還是只是 UI 顯示的問題。
HA 主備異常：最怕 split-brain，最恨亂開 preemption
雙機高可用（HA）出事，最經典的就是 split-brain：兩台同時搶著當 Active。根因幾乎千篇一律：只接了單一條 HA1 控制鏈路又沒做備援。HA1 一斷，心跳收不到（預設每 1000 毫秒一次、連續三次遺失就觸發 failover），兩台都以為對方死了，於是雙雙上位，網路瞬間打結。
要根治，方向有二，建議兩個都做：
- 補一條 HA1 backup link：走不同實體路徑、不同網段，讓控制鏈路本身有冗餘，任一條斷了另一條頂上。
- 啟用 Heartbeat Backup（更推薦）：它透過管理埠、以 ICMP 送備援心跳，路徑與主 HA1 完全獨立。當主鏈路斷了它還通，兩台就知道「對方其實活著，只是控制鏈路掛了」，從而避免誤判成對方陣亡而搶當 Active。
另一個常見狀況是設備不停 failover（flapping）。這裡先講一個重要觀念：preemption 預設是關閉的，沒有明確需求千萬別去開。開了 preemption，原本的 Active 修復後會硬把主控權搶回來，一來一回就是一次不必要的斷線，很多 flapping 就是被手癢開了 preemption 害出來的。PAN-OS 也有自保機制：設備在 15 分鐘內累積到 flap-max（預設 3）次進入非功能狀態，就會被打進 Suspended 停止折騰。這時用 request high-availability state functional 把它救回來，再用 show high-availability all 看最後一次掉出功能狀態的原因是什麼。想核對兩台狀態同步有沒有正常收發，敲 show high-availability state-synchronization。順帶一提，session 同步只涵蓋已建立的連線，failover 當下那些還在三次交握途中的短命連線本來就會斷，這是設計，不是故障。
CLI 排查心法：先看 job、再看 session、最後看 log
把上面幾類問題串起來，PAN-OS 的排障其實就是一套固定流程的反覆操作，再配上幾把 CLI 利刃。
封包實際卡在哪一關，靠資料平面的 flow basic 追：先 debug dataplane packet-diag clear all 清乾淨，設好 filter、set log feature flow basic、set log on，重現問題後務必 set log off（這步最多人忘，忘了它會一直寫、白吃效能），接著 aggregate-logs，最後 tail follow yes dp-log pan_packet_diag.log 讀出全流程。這裡要下一個工程判斷：flow basic 會拖效能，能不在尖峰、不在正式主機上跑就別跑，而且一定要先用 filter 把範圍縮到單一連線，別全開了事。
不想開這麼重的追蹤，先看全域計數器往往就夠：show counter global filter delta yes severity drop。輸出裡的 flow_policy_deny 代表被安全政策擋掉；flow_tcp_non_syn_drop（收到不是 SYN 的第一個 TCP 封包）十有八九是非對稱路由：去程走這台、回程繞別台，防火牆看到半路的 session 沒有前情提要就直接丟。這一個計數器，常常一眼就點破架構問題。其餘各功能的日誌也各有其檔：VPN 談不攏就 less mp-log ikemgr.log 看 IKE／IPSec 協商，User-ID 對應不到使用者查 useridd.log，認證問題回到 authd.log。這幾個 mp-log 檔名背起來，排查速度天差地別。
