运维笔记

FortiGate IPsec VPN 隧道反复中断？从日志分析到 CLI 强制恢复的硬核排查指南

· SmartInfraLog · Cybersecurity
Cybersecurity 技术可视化

写在前面：这个 Bug 能让你怀疑人生

FortiGate 的 IPsec VPN 隧道，用起来是真香，但一旦开始反复断连，那就是噩梦。我见过太多人在 Reddit 上发帖，说隧道好不容易建起来了，结果随机掉线，必须重启设备才能恢复。有个兄弟在 r/fortinet 上吐槽，说他隧道建好后，啥也没干，就莫名其妙断了，重启一边才能恢复。这场景，熟悉不？

最近在 r/india 上有个帖子更离谱——一个老哥发现他的 ISP 在 TLS 1.2 上搞 HTTPS 中间人劫持，而罪魁祸首就是 ISP 侧的一台 FortiGate 设备。这玩意儿不仅能断你的 VPN，还能在你不知情的情况下读你的流量。虽然这是个极端案例，但它说明了一个问题：FortiGate 在隧道管理上，坑是真的多。

今天这篇东西，不跟你扯什么"全面指南"或者"最佳实践"。我就把我自己踩过的坑，加上 Reddit 上那些老哥的血泪史，揉成一个从症状到根因再到 CLI 硬核修复的排查流程。准备好了？直接开干。

症状描述：别只看"隧道 Down"

隧道断了，你第一个看到的是什么？FortiGate 的 GUI 上那个红色的 “Down” 状态？别急，症状远不止这一个。

我整理了几种最常见的表现：

症状典型表现可能原因
隧道彻底断开diagnose vpn tunnel list 显示 downPhase 1 或 Phase 2 协商失败
隧道间歇性断连流量跑着跑着就断了，过一会自己恢复DPD 超时或 NAT-T 问题
隧道显示 Up 但 ping 不通状态是绿的，但内网资源全挂路由丢失或 Phase 2 selector 不匹配
只有单向流量一边能通，另一边不行防火墙策略未放行 return traffic
重启后才恢复隧道断了，必须 reboot 才能重建进程死锁或内存泄漏（老版本常见）

我去年在生产环境遇到过一个经典案例：隧道显示 Up，但所有跨站点的数据库连接全部超时。查了半天，结果是 Phase 2 的 local address 配错了，导致加密流量被丢弃。这玩意儿 GUI 上根本看不出来，必须上 CLI。

根因分析：为什么你的隧道总在作妖？

Phase 1 协商失败

这是最常见的原因，没有之一。IKEv1 和 IKEv2 的协商过程涉及一大堆参数：加密算法、哈希算法、DH 组、生命周期……任何一个参数不匹配，隧道就起不来。

我见过最坑的一次是两边都配了 AES256-SHA256，但一个用的是 IKEv1，另一个是 IKEv2，结果日志里啥也不报，就给你一个 negotiate failed。

Phase 2 selector 不匹配

这个更隐蔽。Phase 2 的 local address / remote address 必须精确匹配。如果你这边配的是 10.0.0.0/24，对端配的是 10.0.0.0/23，隧道能建起来，但流量可能全丢。

DPD 配置问题

Dead Peer Detection 是个好东西，但配不好就是灾难。DPD 间隔太短，网络抖动一下隧道就断；间隔太长，对端挂了你还不知道。默认的 10 秒三次重试，在丢包率高的链路上基本等于自虐。

NAT-T 翻车

如果 VPN 两端都有 NAT 设备，NAT-T（NAT Traversal）必须开启。我见过有人把 NAT-T 关了，结果隧道在公网上跑了几分钟就断，因为中间的 NAT 设备把 ESP 包给丢了。

ISP 层面的骚操作

这是最让人无语的。r/india 那个帖子里，老哥发现他的 ISP 在 TLS 1.2 上做 MITM，用的就是 FortiGate。虽然这跟 VPN 断连不是直接关系，但它说明 ISP 可能会主动干扰或劫持 VPN 流量。有些 ISP 会直接丢弃 ESP 协议包，逼你只能用 UDP 封装的 IPsec。

硬核修复：一步步 CLI 操作

别指望 GUI 能解决这些问题。以下所有操作都在 FortiGate CLI 上执行。

第一步：确认当前隧道状态

diagnose vpn tunnel list

这个命令会列出所有 VPN 隧道及其状态。如果看到 state: down，继续往下走。

更详细的调试信息：

diagnose vpn ike gateway list

这个命令会显示 Phase 1 的详细信息，包括对端 IP、加密算法、DPD 状态等。

第二步：抓日志，定位问题

diagnose debug application ike -1
diagnose debug enable

这个命令会开启 IKE 调试日志。-1 表示所有隧道，你也可以指定具体隧道 ID。

等几秒，然后关掉：

diagnose debug disable

在日志里找这些关键词：

  • no proposal chosen：Phase 1 参数不匹配
  • peer not responsive：对端不可达，可能是防火墙或 NAT 问题
  • DPD timeout：DPD 超时，检查网络稳定性
  • IPsec SA negotiation failed：Phase 2 协商失败

第三步：检查 Phase 1 配置

show vpn ipsec phase1-interface

检查每一项参数是否跟对端一致。重点看：

  • type：是 static 还是 dynamic
  • interface：是否绑定到正确的 WAN 接口
  • peertype：是 any 还是 specific
  • proposal：加密算法是否匹配
  • dhgrp：DH 组是否一致
  • keylife：生命周期，默认 86400 秒

我踩过的一个坑：两边都配了 aes256-sha256，但一个用的是 dh-group 14，另一个是 dh-group 2。日志里根本看不出来，直到我逐行对比才发现。

第四步：检查 Phase 2 配置

show vpn ipsec phase2-interface

重点关注：

  • src-addr-type 和 dst-addr-type：是 subnet 还是 ip
  • src-start-ip 和 src-end-ip：本地子网范围
  • dst-start-ip 和 dst-end-ip：远程子网范围
  • protocol：是 0（所有）还是特定协议

一个常见错误：两边 Phase 2 的 local/remote 配反了。比如你这边 local 是 10.0.1.0/24，remote 是 10.0.2.0/24，对端必须反过来。

第五步：强制重建隧道

如果隧道卡住了，别急着 reboot。先试试这个：

execute vpn tunnel down <tunnel_name>

等几秒，再：

execute vpn tunnel up <tunnel_name>

这个命令会强制重新协商。如果还不行，试试清空 IKE SA：

diagnose vpn ike restart

注意：这个命令会重置所有 IKE 连接，影响所有 VPN 隧道。

第六步：检查路由和防火墙策略

隧道建起来了，但流量不通？检查路由表：

get router info routing-table

确保去往对端子网的路由指向 VPN 隧道接口。

然后检查防火墙策略：

show firewall policy

确保有允许 VPN 流量的策略。一个常见错误：策略的 srcintf 和 dstintf 配反了。

第七步：DPD 和 NAT-T 优化

如果隧道频繁断连，调整 DPD 参数：

config vpn ipsec phase1-interface
    edit <tunnel_name>
        set dpd on-idle
        set dpd-retryinterval 10
        set dpd-retrycount 5
    end

on-idle 表示只在空闲时发送 DPD 探测，减少不必要的网络开销。

NAT-T 配置：

config vpn ipsec phase1-interface
    edit <tunnel_name>
        set nattraversal enable
        set keepalive 10
    end

keepalive 10 表示每 10 秒发送一个 NAT-T keepalive 包，防止 NAT 设备超时。

性能与安全权衡

调整 DPD 和 NAT-T 参数时，你得在性能和可靠性之间做取舍。

参数激进配置保守配置适用场景
DPD 间隔3 秒30 秒激进用于高可用环境，保守用于不稳定链路
DPD 重试次数3 次10 次少次数快速失败，多次数容忍抖动
NAT-T keepalive5 秒30 秒短间隔防止 NAT 超时，长间隔减少带宽
Phase 2 生命周期3600 秒86400 秒短周期更安全，长周期减少重建开销

我个人的经验：在公网链路上，DPD 间隔设 10 秒，重试 5 次，NAT-T keepalive 设 10 秒。这个配置在大多数场景下表现良好。

替代方案：什么时候该换掉 IPsec？

IPsec 虽然强大，但配置复杂，调试困难。如果你受够了，可以考虑这些替代方案：

  • WireGuard：配置简单，性能好，但需要 FortiGate 7.2 以上版本支持。Reddit 上 r/homelab 的老哥都在吹 Tailscale，本质就是 WireGuard 的封装。
  • SSL VPN：FortiGate 的 SSL VPN 比 IPsec 容易配，但性能差一些。适合远程访问，不适合站点到站点。
  • SD-WAN：如果你的预算够，FortiGate 的 SD-WAN 功能可以自动选择最佳链路，减少 VPN 断连的影响。

但说实话，IPsec 在站点到站点场景下仍然是主流。关键是配好、调好，别指望一次配完就万事大吉。

社区踩坑实录

Reddit 上的老哥们贡献了不少血泪史：

  • r/networking 上有人发帖，VPN 连上了但 RDP 不通。查了半天，结果是防火墙策略没放行 3389 端口。这种低级错误，谁都会犯。
  • r/fortinet 上有人隧道断了必须重启设备才能恢复。官方建议升级到 7.2.4 以上版本，因为老版本有内存泄漏问题。
  • r/india 那个 ISP 劫持的帖子虽然极端，但它提醒我们：你的 VPN 流量可能被中间设备干扰。如果隧道频繁断连，试试换端口或协议。

FAQ

问：为什么我的 FortiGate VPN 隧道显示 Up，但 ping 不通对端？

答：最常见的原因是 Phase 2 selector 不匹配或路由丢失。检查 get router info routing-table 确认路由指向 VPN 接口，然后用 diagnose vpn tunnel list 确认 Phase 2 的 local/remote 地址范围是否正确。另一个可能是防火墙策略的 srcintf 和 dstintf 配反了。

问：隧道频繁断连，怎么定位问题？

答：先开 IKE 调试日志：diagnose debug application ike -1 和 diagnose debug enable。在日志里找 DPD timeout 或 peer not responsive。如果是 DPD 超时，调整 DPD 间隔和重试次数。如果是 no proposal chosen，检查 Phase 1 参数是否匹配。

问：重启设备才能恢复隧道，怎么解决？

答：这是 FortiGate 老版本的已知问题，通常是 IKE 进程死锁或内存泄漏。先试试 execute vpn tunnel down 和 execute vpn tunnel up 强制重建。如果不行，升级到 7.2.4 以上版本。Fortinet 官方在 7.2.4.6880 版本中修复了这个问题。

问：NAT-T 应该开启吗？

答：如果 VPN 两端至少有一端在 NAT 设备后面，必须开启。用 config vpn ipsec phase1-interface 设置 set nattraversal enable 和 set keepalive 10。如果不确定，建议默认开启，因为很多公网环境都有 NAT。

问：Phase 1 和 Phase 2 的参数必须完全一致吗？

答：Phase 1 的加密算法、哈希算法、DH 组、生命周期必须完全匹配。Phase 2 的加密算法和哈希算法也必须匹配，但生命周期可以不同（以较小的为准）。Phase 2 的 local/remote 地址范围必须精确匹配，不能有重叠或缺失。

参考与社区洞察

本文的技术观点综合自以下来源：

  • Fortinet 官方文档：Troubleshooting Tip: IPsec VPN tunnels（v7.2 及以上）
  • Reddit 社区：r/fortinet、r/networking、r/india 的 VPN 相关讨论
  • 个人在生产环境中的 FortiGate 运维经验

特别感谢 r/india 那位老哥的 ISP 劫持帖子，虽然跟 VPN 断连不是直接关系，但它提醒我们：网络安全没有银弹，每一步都要谨慎。

Elvin Hui

关于作者：Elvin Hui

Elvin 拥有 10+ 年企业级数据中心、云原生架构和网络安全经验。持有 CCNA、AWS 解决方案架构师认证。我致力于将一线的“踩坑”经验沉淀为真实、硬核的技术指南，拒绝空洞理论。