跳轉到

VPN 疑難排解

VPN 建不起來、時通時不通，是最常開 TAC 的題目之一。這篇把 debug 指令、log 檔、Phase 1 / Phase 2 常見失敗對照整理成一套排錯流程。

先分清楚卡在哪一階段

VPN 協商分兩階段（見 Site-to-Site VPN）：

  • 卡 Phase 1（IKE SA）：通常是認證 / 加密參數不合（加密、hash、DH group、PSK、Main vs Aggressive mode）。
  • 卡 Phase 2（IPsec SA）：通常是加密網段（VPN Domain / Proxy-ID）對不上，或 PFS / DH group 不一致。

debug 指令

# 高階 VPN daemon debug → $FWDIR/log/vpnd.elg*
vpn debug on
vpn debug off

# IKE 協商 debug
vpn debug ikeon [-s <Size_MB>]
#   ... 重現連線 ...
vpn debug ikeoff

# 一鍵：先輪替清空舊 log 再開全面 debug（最常用）
vpn debug trunc

# IKE 封包監測 → $FWDIR/log/ikemonitor.snoop
vpn debug mon

協商記錄檔（用 Check Point IKEView 工具開最易讀）：

  • IKEv1 → $FWDIR/log/ike.elg
  • IKEv2 → $FWDIR/log/ikev2.xmll

標準流程：vpn debug trunc → 重現問題 → vpn debug off; vpn debug ikeoff → 下載 log → IKEView 分析。

看隧道狀態與 SA

vpn tu                 # 互動式：列出 / 刪除 IKE / IPsec SA
#   常用「Delete all IPsec+IKE SAs for a given peer」→ 強制重新協商

用 fw monitor 看加解密

fw monitor 的四個檢查點（詳見）可確認封包加密前 / 後的樣子，判斷流量到底有沒有進隧道、NAT 有沒有干擾。

Phase 1 / Phase 2 常見失敗對照

症狀 常見原因 方向
Phase 1 No proposal chosen 兩端加密 / hash / DH group 不一致；Main vs Aggressive mode 不符；憑證式設定不對 逐項對齊 Phase 1 提案
收到 peer Received Notification: no proposal chosen 提案組合無交集 同上
Phase 1 提案被拒（提案過多） Gateway 最多只「看」16 個 IKE Phase-1 提案，超過即拒 精簡提案組合
Phase 2 no proposal chosen / Quick Mode 失敗 加密網段不對稱（我方 Local 必須 = 對方 Remote，反之亦然）；PFS / DH group 不一致 對齊兩端加密網段與 PFS
時通時不通 / 一段時間後斷 生命週期不一致、NAT-T 問題、缺 Permanent Tunnel/DPD 對齊 lifetime、檢查 NAT-T

NAT-T（NAT Traversal）

VPN 經過中間 NAT 設備時用 UDP 4500 封裝；偵測到 NAT 預設啟用。對第三方 IKEv2 排錯時，NAT-T 行為（sk165003 等）是常見嫌疑，必要時於 Gateway 屬性 → IPSec VPN → VPN Advanced 調整。

排錯心法

先比對「設定」（加密套件 + 加密網段）→ 再用 debug log「驗證」
   ↓
卡 Phase 1 → 認證 / 加密參數
卡 Phase 2 → 加密網段 / PFS
時通時斷 → lifetime / NAT-T / 缺常駐隧道

小結

  • 先判斷卡在 Phase 1（認證/加密）還是 Phase 2（加密網段）。
  • vpn debug trunc + vpn debug ikeon 抓 ike.elg / ikev2.xmll，用 IKEView 分析。
  • vpn tu 刪 SA 強制重協商。
  • No proposal chosen = 提案不合；Phase 2 失敗多半是加密網段不對稱。