🔧 當備援設計反咬一口：一次 CATO SASE + Palo Alto 雙層防火牆的 ZTNA 異常排查記錄

記錄一次有趣的網路問題排查過程，關於備援機制如何在「好心」的設計下，反而造成核心功能失效。

前言

最近遇到一個有趣的問題：ZTNA 遠端存取功能異常，但辦公室內的網路和一般上網都正常。

這種「部分功能失效」的問題最難排查，因為不是全斷，很容易被忽略或誤判。花了一些時間追根究柢，最後發現問題出在一個「好心的備援設計」上。

把排查過程記錄下來，給自己留個參考，也許對遇到類似問題的人有幫助。

架構背景

先說明一下網路架構，這是一個典型的 SASE + NGFW 雙層防護設計：

關鍵點：

• 兩層都有 HA（高可用性），各兩台設備
• 正常流量路徑：Internet → CATO Socket → Palo Alto → 內網
• ZTNA 流量必須經過 CATO Cloud 驗證，這是 SASE 架構的核心

廠商在 Palo Alto 上設定了一條 Backup WAN 路由：當 CATO Socket 不通時，流量可以直接走 ISP，確保基本上網功能不中斷。

聽起來是個貼心的設計，對吧？

問題現象

某天發現 ZTNA 無法使用，但奇怪的是：

• ✅ 辦公室內網存取：正常
• ✅ 一般上網：正常
• ❌ ZTNA 遠端存取：失敗

這種「部分失效」的現象很有意思。如果是網路全斷，問題反而好找；但只有 ZTNA 不通，其他都正常，就需要仔細分析流量路徑了。

排查過程

第一步：確認問題範圍

先做了幾個測試：

• 測試 1：關閉 CATO Client → 可以存取內網 ✓
• 測試 2：開啟 CATO Client → ZTNA 失敗 ✗
• 測試 3：辦公室直接上網 → 正常 ✓

這說明問題跟 CATO 有關，但不是 CATO 完全掛掉（因為如果完全掛掉，上網也會有問題）。

第二步：檢查 CATO 狀態

請廠商協助檢查 CATO Management Console（CMA），發現：

• Socket 的 LAN Port 狀態顯示異常
• 實體燈號是亮的，但 CMA 上顯示 Down

這就有意思了 — — 實體層正常，但邏輯層異常。

第三步：分析流量路徑

開始思考：如果 Socket 到 PA 之間有問題，為什麼一般上網還是正常？

這時候想到了那條 Backup WAN 路由。

檢查 PA 的路由設定：

code

發現問題了：主路由沒有啟用 Path Monitoring。

這意味著 PA 只看「介面狀態」來決定路由是否有效，不會主動檢查「路徑是否真的通」。

根因分析

把整個邏輯串起來：

為什麼 ZTNA 會失敗？

這是 SASE 架構的特性：

為什麼不會自動切回？

這是問題的關鍵：

沒有 Path Monitoring，PA 就像一個「不會主動打電話確認」的人 — — 他只看門口有沒有車，不會打電話問「你到底還在不在」。

解決方案

已執行：在主路由新增 Path Monitoring

設計邏輯：

1. 為什麼監控兩個目標？

• Socket IP：確認 Socket 本身是否活著
• 8.8.8.8：確認「透過 Socket 能不能上網」
• 兩個都失敗才算主路由失效，避免單點誤判

2. 為什麼設 150 秒容忍時間？

• Socket HA 切換通常只需要幾十秒
• 150 秒足夠讓 Socket 完成更新和 HA 切換
• 避免短暫中斷就觸發 Backup WAN

3. 為什麼設 Failure Condition: All？

• 更保守的判斷
• 只有當 Socket 和外網都不通時，才認為主路由失效

建議方案：停用 Backup WAN

其實更簡單的做法是直接停用 Backup WAN：

`理由：

1. CATO Socket 有 HA，兩台同時掛掉的機率很低`

2. Backup WAN 會讓 ZTNA 失效，備援狀態下核心功能反而不能用

3. 簡化架構，減少不確定因素

但這需要跟廠商確認，畢竟是他們設計的架構。

經驗總結

1. 備援設計要考慮「備援狀態下什麼功能會失效」

這次的情況：

• Backup WAN 可以讓一般上網維持
• 但 ZTNA 會失效
• 對於重度依賴 ZTNA 的環境，這個備援反而造成更大問題

2. Path Monitoring vs Link Monitoring

• Link Monitoring：只看介面狀態（線有沒有插），快速但不精確，適合偵測硬體故障
• Path Monitoring：主動 Ping 目標確認路徑是否通，較慢但精確，適合偵測軟體問題、上游設備故障

在這個案例中，Link Monitoring 不夠用，因為問題出在「邏輯層」而不是「實體層」。

3. 多層 HA 架構的複雜性

• 單層 HA：狀態簡單，Active 或 Standby，切換邏輯清楚
• 雙層 HA：狀態組合 2 × 2 = 4 種，加上備援路由，複雜度更高，一層的問題可能影響另一層的判斷

不是說雙層 HA 不好，而是要更謹慎地設計切換邏輯和監控機制。

4. 廠商的「貼心設計」要謹慎評估

這次的 Backup WAN：

• 廠商的出發點是好的：確保網路不會全斷
• 但低估了 CATO Socket 的穩定性
• 也沒考慮到 ZTNA 對 CATO 的依賴性

教訓：備援機制要跟業務需求對齊，不是「有備援就是好」，要問：備援啟動時，什麼功能會受影響？

後記

這個問題花了一些時間才釐清，主要是因為「部分功能失效」的現象很容易誤導方向。

一開始以為是 CATO 的問題，後來發現是 PA 的路由設定；一開始以為是硬體問題，後來發現是邏輯層的狀態不一致。

排查網路問題就是這樣，要一層一層剝開，不能只看表面現象。

希望這個記錄對遇到類似問題的人有幫助。如果你也在用 CATO + Palo Alto 的架構，建議檢查一下有沒有類似的備援設定，以及 Path Monitoring 是否正確配置。

🏷️ 標籤：#CATO #PaloAlto #SASE #ZTNA #HA #PathMonitoring #NetworkTroubleshooting 這篇文章是排查記錄，如果有技術細節錯誤或更好的解法，歡迎留言討論。