深入解析 Sophos Firewall 常見問題：管理平面設計哲學、Web Admin 鎖死救援、IPsec 與 SSL VPN 的 MTU 陷阱、NAT 解耦與 HA 雙機判讀，高雄企業適用。
先懂設計哲學：管理平面和防火牆規則是兩回事
會出錯的第一個根源，是把「連到防火牆本機」和「流量穿過防火牆」搞混。在網路設備裡，這叫 control plane（管理平面）與 data plane（資料平面）的分離：你用瀏覽器連 Web Admin、SSH 進去、做 RADIUS 認證，這些是「找防火牆本機講話」，Sophos 不吃你寫的那些 firewall rule，而是統一由 Administration 底下的 Device Access 一張「服務 × 區域」的勾選矩陣決定。所以最常見的鬼打牆：「我明明開了一條 Any-Any 的規則，WAN 還是連不進管理頁」：原因就是矩陣裡 HTTPS 管理與 SSH 對 WAN 預設是關的，跟你寫的那條規則一點關係都沒有。
比整張矩陣更精準的做法，是 Local service ACL exception rule。矩陣的粒度是「整個區域全開或全關」，exception rule 則能覆寫它，只放行特定來源 IP、國家或位置存取某一個本機服務，權限收得更細。官方也是這個建議：真要從外部管理，寧可用 exception rule 綁死來源 IP，也別為了方便把整個 WAN 區域對 HTTPS 打開。要提醒的是，某些舊韌體版本的 exception rule 曾有實作上的瑕疵導致仍連不進，遇到「規則寫對卻沒生效」時，先確認韌體是不是該升級。
第二個根源是 CLI。Sophos 的 SSH／序列埠登入後看到的是 1 到 7 的編號式選單，不是自由指令列。類似傳統 CLI 的進階診斷藏在 4. Device Console（會出現 console 提示字元，ipsec、tcpdump、drop-packet-capture 這些都在這一層下），最底層的 Linux root shell 在 5. Device Management → 3. Advanced Shell。這裡有個要命的工程細節：Advanced Shell 是直接動到執行中的 Linux 系統，你在裡面改的東西不會寫進設定資料庫、重開機就消失、也不會進備份檔，所以它只該拿來看狀態、抓封包、救急，絕不能當成正式改設定的地方。正式組態一律回 GUI 或用 Device Console 的結構化指令下，才會被持久化與同步到備援機。
Web Admin 連不上：先排除埠號、再排除區域
管理介面預設走 https://設備IP:4444，用 http 或漏掉埠號一定失敗，這是最基本卻最常被忽略的一步。埠號、協定都對了還是進不來，多數是前面講的 Device Access 區域沒開，或你正從 WAN 連而 WAN 沒放行。判斷順序我習慣這樣：先在同網段用 LAN 直連測一次，能通就代表服務本身活著、問題出在區域或來源判定；連 LAN 都進不去，才往服務或憑證那邊查。
萬一把自己鎖在門外：改錯埠、規則打架、密碼忘了：別急著整台重置設定。接一條 console 線進 Device Console 主選單，System Configuration 裡可以重設 admin 密碼。真的火燒眉毛，console 有一道 system appliance_access enable 能暫時放行所有本機服務，但官方講得很白：開這個開關的當下，設備會停止對外轉送流量、等於整條線先斷掉，只能當幾分鐘的救命繩，救回來務必馬上 disable。把 4444 直接曝在公網更是大忌，正確姿勢是走 VPN 進來管理，或用 exception rule 只放行你辦公室的固定 IP，再搭多因素認證，把攻擊面收到最小。
站對站 IPsec：log 字串就是診斷書
Sophos 的 IPsec 底層是開源的 strongSwan，好處是 log 幾乎照著 IKE 協商的階段在講話，會看就不用瞎猜。整理幾條最常遇到的：
- Remote peer is refusing our Phase 1 proposals：卡在第一階段，兩端的加密演算法、雜湊、DH group 或 gateway ID 有一項對不上。IKE 協商是「整組提案全部 match 才算數」，只要一個參數差一格，整組提案就被拒。
- Error on decryption of the exchange：多半是 pre-shared key 打錯；但也可能是 MTU／MSS 過大，封包在路上被切壞、解不開，這一點下面單獨拆開講。
- Remote peer reports INVALID_ID_INFORMATION：進到第二階段，但兩端的子網（traffic selector）或 ID 型別沒對映好，一端宣告 10.1.0.0/24、另一端只認 10.1.1.0/24，就會互踢。
在 Device Console 用 ipsec statusall 看通道狀態、用 ip xfrm policy 核對實際下發的加密策略，常見問題會當場現形。還有一個 route-based（VTI）通道最愛出的包：介面建好、通道也 up 了，流量卻不進通道：因為NAT 不改變路由決策，路由才決定封包往哪走。route-based 一定要另外補一條指向 tunnel 介面的靜態路由，policy-based 才是靠 traffic selector 自動框流量。搞不清自己用的是哪一種，就先把這一步確認掉。
為什麼小封包會通、傳大檔就斷？：MTU 與 MSS 的物理限制
這是 VPN 最陰的一種故障：ping 得到、開網頁也還好，一傳大檔或跑資料庫同步就整個卡死。根因是封包大小。乙太網路標準 MTU 是 1500 bytes，但 IPsec 要在原封包外面再包一層 ESP 表頭與加密開銷：ESP 本身約 36 bytes 起跳，AES-256 搭 SHA1 這種常見組合可以吃到約 73 bytes，若又套了 NAT-T 的 UDP 封裝還要再加 8 bytes。原本 1500 的封包硬塞進通道就爆掉，只能分片（fragmentation）；分片一多，CPU 拉高、對端要重組，一旦路徑上某台設備把 ICMP「需要分片」的訊息擋掉，就形成 PMTUD 黑洞：路徑 MTU 自動偵測失效，大封包默默被丟，症狀就是小的會通、大的卡死。
工程上的解法不是去賭 PMTUD 能自己談成，而是主動把尺寸壓下來：把通道 MTU 設在 1400 到 1440，並對 TCP 做 MSS clamping 夾到 1360 到 1380；環境雜、又過多層封裝時，乾脆把 MSS 壓到 1336 最保險。MSS clamping 的巧妙處，是防火牆會主動改寫 TCP 三向交握裡協商的 MSS 值，逼兩端一開始就用小一點的區段，完全不依賴 ICMP，所以連 PMTUD 黑洞都能繞過去。看到「小的通、大的斷」，先想 MTU，別再從加密參數那邊瞎找。
SSL VPN 與 Sophos Connect：照順序查最快
SSL VPN 撥不上，官方的檢查順序其實很清楚，照做就好：先確認 Device Access 有把 SSL VPN 對 WAN、VPN portal 對 WAN 與 LAN 都開；再到 Advanced Shell 下 service -S 過濾 sslvpn，看服務是不是 Running，若顯示 UNREGISTERED，代表你連一條 SSL VPN 政策都還沒建、服務根本沒起來。兩個很容易漏掉的硬限制要記住：使用者名稱加網域合計不能超過 51 個字元，太長的 AD 帳號會撥不上；遠端存取 IPsec（Sophos Connect）只支援 IKEv1，DPD 要關掉或設成 Disconnect，你在 profile 選了 IKEv2 就是建不起來。撥上了卻連不到後端伺服器，防火牆規則的來源要用系統內建的 host 物件 ##ALL_SSLVPN_RW，並確認配發給用戶端的 VPN 子網沒和內網重疊：網段一撞，回程封包會走錯邊，症狀就是連得上通道卻連不到主機。
規則、NAT 與 Log Viewer：別用猜的，去看命中哪一條
Sophos 的防火牆規則是由上而下、第一條符合就定案，勝出的是「第一條 match」而不是編號最小那一條，順序排錯就會被上面的規則先攔走。要特別小心自動產生的規則（郵件 MTA、IPsec）永遠壓在最上層，你手動把某條設成 Top，有機會插到它們前面反而闖禍。
v18 之後 NAT 從防火牆規則裡拆出來、變成獨立的 NAT 表，核心一句話：NAT 只翻譯位址、不負責放行。所以做 port forward（DNAT）永遠是「兩條」：一條 DNAT 規則把外部流量的目的地改寫成內網伺服器，再加一條防火牆規則真正允許這個連線。最多人卡在這條防火牆規則的寫法：目的區域要填 NAT 後的內網區域，目的 IP 卻要填 NAT 前的對外 public IP，因為規則比對是在 NAT 之前判目的位址、在 NAT 之後判區域，這個「前後不一致」不是 bug，是設計如此。另外，內網用自家 public IP 連不到自家伺服器，是少了 loopback（髮夾彎）規則；伺服器主動回外面的流量要能對得上來源，則靠 reflexive 規則：這兩者在 v18 都能在建 DNAT 時一鍵勾選生成，不用再手刻。
實際被哪一條擋，不要猜。到 Monitor & analyze 的 Log Viewer，左上角把模組切成 Firewall 或 Web filter，看 fw_rule_id 就知道命中哪條，點下去還能直接跳到那條規則；Rule ID 顯示 0，代表沒命中任何規則、被預設策略丟棄。這裡有個超容易誤判的陷阱：同一個網頁請求，會在 Firewall 模組顯示 allowed、卻在 Web filter 模組顯示 blocked：兩者不衝突，因為封包是先過防火牆放行、再被內容過濾攔下，真正的兇手要看 Web filter 那一筆。想更底層看丟包原因，Device Console 的 drop-packet-capture 配 BPF 過濾式最直接，例如 drop-packet-capture 'host 10.10.10.1 and port not 22'，只抓被丟的封包，把噪音全濾掉，drop 的真因一目了然。
HA 雙機：條件很硬，別在 CLI 找開關
Sophos 的 HA 是 Primary（主）與 Auxiliary（輔）的角色，成軍條件比很多人想的嚴格：同型號、同硬體版本（連 rev 都要一樣，rev3 只能配 rev3）、韌體連 build number 都得一致、埠數相同、專用 HA 線兩端 IP 在同一網段。設定同步是單向從 Primary 推到 Auxiliary。狀態字串要會讀：Standalone 是對端掛了、健存這台獨立扛著；Fault 不一定是硬體壞，監控埠失效、韌體更新中都可能顯示 Fault，別急著換機。
查狀態用 Device Console 的 system ha show details，翻歷程用 system ha show logs。最容易被忘記的一點：啟用或停用 HA 只能走 GUI 的 System services，Device Console 裡根本沒有 enable／disable HA 的指令，在 console 裡翻半天是找不到的。還有一個要命場景：專用 HA 線斷掉會 split-brain，兩台都以為自己是主、同時搶同一組 virtual MAC，網路會亂到你懷疑人生。標準處置是先控制性地關掉其中一台、把線修好，再讓它重新偵測 Primary、加回叢集，切忌兩台都開著硬接。
