整篇文章透過AI將排查的內容整理之後產出
前言
最近排查了一個相當燒腦的 IPsec 撥號 VPN 連線問題：同一台筆電、同一份憑證、同一版本的 FortiClient，連線 A 台 FortiGate 完全正常，連線 B 台 FortiGate 卻穩定失敗。更詭異的是，B 台 FortiGate 自己看起來一切正常——IKE/IPsec SA 顯示協商成功，但 FortiClient 用戶端幾秒後就回報連線失敗，錯誤原因欄位還是空的。
前後花了不少時間交叉比對封包、debug log，最後定位到一個很少人會注意到的角落：同一台 FortiGate 出廠時，可能內建了兩張分屬不同 CA 體系的裝置憑證，而用戶端電腦剛好只信任其中一條。整個過程紀錄下來，希望能幫到遇到類似狀況的人。
環境與症狀
- Gateway A(FortiGate-60F，FortiOS 7.4.11)：問題發生端，IKEv2 撥號 VPN
- Gateway B(FortiGate-201E，FortiOS 7.4.11)：對照組，功能完全正常
- 用戶端：同一台 Windows 筆電，同一份智慧卡憑證，FortiClient 7.4.1(Free 版與 EMS 版皆測試過)
症狀很單純但很誤導人：連線 Gateway A 時，FortiGate 端的 log 顯示 IKE/IPsec SA 協商成功(SA established)，但流量是 0 進 0 出；FortiClient 大約 5~9 秒後就回報連線失敗，沒有具體原因。連線 Gateway B 則完全正常。
排查過程：一路排除的假設
依序測試並排除了以下幾個方向：
- client-auto-negotiate / client-keep-alive 設定：調整成與 Gateway B 一致並啟用，無效。
- Mode-cfg 指派網段：IP Pool 從 /32 改成 /24，無效。
- MTU / 封包分片：一度懷疑是分片重組問題，但比對後發現 Gateway A 的 AUTH_RESPONSE 封包實際上比 Gateway B 更小，方向完全相反；用戶端封包截取也證實分片有正確重組，排除。
- ISP / 網路路徑封包遺失：這個最關鍵。在 FortiGate 端與用戶端筆電同時做封包截取，結果發現——即使 FortiClient 已經回報連線失敗超過一分鐘之後，FortiGate 主動送出的 DPD(Dead Peer Detection)探測封包，仍然完整送達用戶端的網卡。這證實封包在網路路徑上完全沒有遺失，問題出在用戶端內部，不是網路傳輸層。
用戶端內部到底發生了什麼事
網路層排除之後，只能往 FortiClient 內部挖。開啟 Debug 等級日誌後，找到兩個關鍵線索：
- 狀態機日誌顯示 FortiClient 內部會先進入一個 Compliance Check 狀態，等待約 7 秒後，主行程會對負責 IPsec 協商的獨立子行程送出一個「關閉」訊息——這個時間點竟然略早於 FortiGate 端完成金鑰交換的時間，代表協商行程在收到關閉指令之後才完成協商，於是 FortiGate 端看到「成功」，FortiClient 上層卻已經判定「失敗」。
- 結構化安全事件日誌(forticlientlog.log)第一次給出明確的錯誤訊息：
IKE phase1 authentication fail as peer's certificate is not verified用戶端在驗證 FortiGate 回傳的憑證時失敗了——這才是真正的根因線索。
根因：同一台設備，兩張分屬不同 CA 鏈的出廠憑證
把 Gateway A 與 Gateway B 實際協商時送出的憑證抓下來比對(openssl 解析)，發現：
| 項目 | Gateway A 的出廠憑證(失敗) | Gateway B 的出廠憑證(正常) |
|---|---|---|
| Subject CN | FGT60FTxxxxxxxx | FG201ETxxxxxxxx |
| Issuer CN | fortinet-subca2001 | support |
| 有效期至 | 2056 | 2038 |
兩台設備的出廠憑證，簽發 CA 完全不同——一個走較新的中繼 CA 鏈(fortinet-subca2001)，一個走較舊的 CA(support)。用戶端 Windows 電腦的信任存放區裡剛好只信任舊的那條鏈，所以連線 Gateway A 時，憑證驗證必定失敗；連線 Gateway B 則因為剛好信任那條舊鏈而成功。
更有趣的是：Gateway A 這台設備上，其實同時內建了另一張出廠憑證，走的正是與 Gateway B 相同的舊 CA 鏈，Subject CN 與原本那張完全相同(代表是同一台設備)、簽發日期也相同——證實同一台設備出廠時就準備了兩條不同世代的憑證鏈，只是預設用的是比較新的那條。
進一步查了 FortiClient 的連線設定檔，發現它在驗證對方憑證時，並沒有自己另外維護一份信任清單，而是直接呼叫 Windows 作業系統本身的憑證存放區。也就是說，問題根源其實是「這台電腦的憑證信任清單」，不是 FortiClient 軟體本身的缺陷。
原廠回覆：官方證實的憑證架構差異
把這個發現拿去問原廠支援，得到的答覆正式確認了背後的邏輯：
- 較新機型：具備中繼 CA 與根 CA 的完整架構，出廠憑證由中繼 CA 簽發，有效期到 2056 年；同時保留一張較舊架構的備用憑證，有效期到 2038 年。
- 較舊機型：沒有中繼 CA，出廠憑證直接由根 CA 簽發，有效期到 2038 年——這張憑證與新機型上的備用憑證屬於同一套(舊式)體系。
這完全解釋了觀察到的現象：新一代設備預設用的是新憑證鏈，用戶端電腦如果只信任舊鏈，接上新機型時就會踩到這個坑。
兩種解法，各有取捨
排查到這裡，實際驗證出兩種都可行的解法：
方案一：直接切換到設備上內建的舊鏈憑證
操作最簡單，改一行設定即可：
set certificate "備用憑證名稱"缺點是這張備用憑證有效期較短(2038 年到期)，而且只解決了這一台設備，換一台新設備仍可能重演同樣問題。
方案二：在用戶端電腦補齊完整信任鏈
保留原本效期更長的出廠憑證不變，改成在用戶端電腦安裝完整的信任鏈。解析憑證的 Authority Key Identifier 延伸欄位，可以反推出完整鏈是三層：裝置憑證 → 中繼 CA → 根 CA。原廠支援確認可以直接從 FortiGate GUI 的「System > Certificates」頁面，在 CA 憑證清單裡點兩下目標憑證即可下載。
取得中繼 CA 與根 CA 兩張憑證檔案後，分別匯入 Windows 的「中繼憑證授權單位」與「受信任的根憑證授權單位」存放區，原本無法驗證的出廠憑證就能正常通過驗證了——實際測試確認有效。
這個方案的好處是可以繼續使用效期更長的原廠憑證，而且往後不管接上任何一台使用同一條新版憑證鏈的設備，都不會再發生同樣的問題，算是比較治本的做法。
心得
這個案例最有意思的地方在於：FortiGate 端從頭到尾都顯示連線成功，SA 建立、金鑰交換全部正常，完全看不出任何異常；真正的失敗訊息只存在於用戶端的 Debug 等級日誌裡，而且還藏在一個平常很少人會去開的結構化安全事件日誌檔案裡。如果只看 FortiGate 端的 log，這個問題大概永遠找不到根因，只會一直懷疑網路、懷疑相容性、懷疑各種設定組合。
幾個帶得走的心得：
- 遇到「伺服器端看起來成功、用戶端卻回報失敗」的情境，第一時間應該懷疑是用戶端內部邏輯判斷失敗，而不是一味在伺服器端或網路層打轉。
- IPsec 憑證驗證失敗這種問題，光看 IKE debug log 往往看不到明確原因，一定要另外開用戶端軟體的 Debug 等級日誌才有機會抓到真正的錯誤訊息。
- 同一款硬體、同一個廠牌，不代表出廠預設憑證用的是同一套信任體系——尤其是新舊世代交替的產品線，這種細節差異很容易被忽略。
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg){kind=link}