FortiGate on Zero Day Notes

一次FortiGate HA主备切换因会话同步不完整导致业务大规模中断的排查实录

Thu, 02 Jul 2026 07:00:00 +0000

问题背景

我们公司总部机房出口部署了两台 FortiGate 600E 防火墙，以 Active-Passive 模式组成 HA 双机热备集群，承载全公司约 1800 人的互联网访问、总部-分支 IPSec VPN 隧道（6 条）、以及 ERP/OA 等业务系统的对外发布。这套 HA 集群已经稳定运行两年多，期间也经历过两次计划内主备切换（固件升级），均未出现异常。

周三上午 9:15，正值上班高峰期，监控平台突然弹出大量告警——6 条 VPN 隧道状态全部变为 Down，ERP 系统外部访问超时，OA 系统邮件收发中断。与此同时，多个分支机构电话涌入，报告无法访问总部内网资源。整个业务中断持续了约 40 分钟，影响了近 800 名在线用户的正常工作，紧急程度极高。

故障现象

故障发生时，现象非常明确且集中：

1. VPN 隧道全部中断

6 条总部到分支的 IPSec VPN 隧道在 9:15 同时从 Phase 2 Up 变为 Down，FortiGate VPN Monitor 页面显示隧道状态为 “Tunnel Down”，但 Phase 1 仍在协商中。各分支的 FortiGate 日志中出现大量：

1
2

ike: IPSec SA negotiation failed: payload malformed
ike: phase 2 negotiation failed due to timeout

2. ERP 和 OA 系统外部连接中断

Nginx 日志中 9:15 之后请求量骤降至零，直到 9:55 才开始恢复。Grafana 监控图上 TCP 连接数从 2300+ 瞬间跌至 12（仅剩防火墙自身管理连接）。

3. 内部用户互联网访问短暂中断后恢复

内部员工的互联网访问在 9:15 中断了约 30 秒后恢复，但所有需要维持长连接的应用（SSH 会话、WebSocket 推送、SIP 语音通话）全部断开，需要重新建立连接。

4. FortiGate HA 状态异常

登录防火墙管理界面后发现：原主设备（FG-600E-01）已变为 Standby，原备设备（FG-600E-02）已变为 Active。HA 切换确实发生了，但业务并未如预期无缝恢复。

关键日志片段（备机升级为 Active 后）：

ha: HA member 1 (FG-600E-01) status changed to standby
ha: HA member 2 (FG-600E-02) status changed to active
ha: HA failover triggered by: member 1 heartbeat lost
ha: Session sync incomplete: 48213/112340 sessions synced (43%)

最后一行日志格外引人注目——会话同步只完成了 43%，意味着超过 6 万条活跃会话在切换时丢失了。

排查过程

第一步：确认 HA 切换原因

首先搞清楚为什么会发生 HA 切换。登录原主设备（现在是 Standby）查看日志：

1
2
3

system: Thermal shutdown triggered: temperature threshold exceeded (65°C > 55°C)
system: Fan 1 status: failed, Fan 2 status: failed
system: HA heartbeat lost, member transitioning to standby

主设备的两个风扇同时故障，导致设备温度超过阈值触发热保护关机。这是个硬件故障，HA 切换本身是正确的保护行为。

在 FortiGate CLI 上进一步确认：

# execute ha peer status
HA Peer Status:
  Member 1 (FG-600E-01): Standby, heartbeat: OK, uptime: 0d 0h 45m (recovered)
  Member 2 (FG-600E-02): Active, heartbeat: OK, uptime: 2y 178d

# get system status
Hostname: FG-600E-01
HA Health Status: Standby
Temperature: 42°C (recovered after fan replacement by auto-restart)

主设备在温度恢复正常后自动重启并重新加入了 HA 集群（作为 Standby），但此时业务中断已经发生了。

第二步：深入分析会话同步率为什么只有 43%

这是核心问题。正常情况下，Active-Passive HA 的会话同步应该是实时进行的——主设备上每建立一条新会话，都会同步到备设备。我们检查了 HA 配置：

# show system ha
config system ha
    set group-id 10
    set group-name "FG-HA-Cluster"
    set mode a-p
    set password "xxxxxxxx"
    set hbdev "ha1" "ha2"
    set session-pickup enable
    set session-pickup-connectionless enable
    set override-disable
    set priority 100 (主) / 50 (备)
end

session-pickup enable 是开着的，session-pickup-connectionless enable 也开着（UDP 等 UDP 类会话也会同步）。配置看起来没问题。

但关键参数我们漏掉了：session-sync-dev 和 ha-session-sync-frequency。

继续查看完整配置：

# show system ha full-configuration
config system ha
    set group-id 10
    set group-name "FG-HA-Cluster"
    set mode a-p
    set password "xxxxxxxx"
    set hbdev "ha1" "ha2"
    set hbdev-vlan-id 0
    set hbdev-peerip 0.0.0.0
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-sync-dev "ha1"    <-- 仅用一条心跳线同步会话
    set ha-session-sync-frequency 50    <-- 每50ms同步一批
    set override-disable
    set priority 100
end

发现了两个问题：

session-sync-dev 仅指定了 ha1——会话同步只通过一条心跳线传输，而我们有两条心跳线（ha1 和 ha2），第二条只用来传心跳，没用来传会话数据。
ha-session-sync-frequency 设为 50ms——这意味着每 50ms 才同步一批会话更新。在高并发场景下（112340 条活跃会话），50ms 的间隔会导致同步队列积压。

第三步：计算会话同步吞吐量瓶颈

FortiGate HA 会话同步的工作机制是：主设备每隔 ha-session-sync-frequency 毫秒，将这段时间内新增/变更的会话打包发送到备设备。每批最大传输约 256 条会话更新（取决于底层 TCP 窗口和 MTU）。

我们来算一下：

同步频率：50ms → 每秒 20 批
每批上限：约 256 条
每秒最大同步速率：20 × 256 = 5120 条/秒

但在上班高峰期，新会话建立速率是多少？我们从监控数据中提取：

1
2
3

# 从 FortiGate 的 session 统计看
Active sessions at 09:14: 112340
New sessions per second (average 09:00-09:15): ~18000

每秒新增约 18000 条会话，但同步速率上限只有 5120 条/秒——同步速率远低于会话创建速率，差距约 3.5 倍。

这意味着在高峰期，主设备上大量会话根本来不及同步到备设备。当切换发生时，备设备上的会话表只是"最近同步过来的那部分"，而不是完整的活跃会话集合。

此外还有一个问题：FortiGate 的会话同步是增量同步，不是全量同步。主设备只在会话建立时发送一次同步消息，后续的状态变更（如 TCP 序列号更新、窗口大小变化）不会再同步。所以即使同步速度够快，长连接的中间状态信息也是缺失的。

第四步：验证心跳通道带宽

两条心跳线分别连接在不同端口上：

1
2

ha1: port3 (1Gbps RJ45)
ha2: port4 (1Gbps RJ45)

心跳线用的是千兆端口，但 session-sync-dev 只指定了 ha1，意味着所有会话同步数据只走 port3 一条链路。实际测量 port3 在高峰期利用率：

1
2
3

# fnsysctl ifconfig port3
port3: TX packets 847320, TX bytes 634MB (09:00-09:15)
port3: RX packets 823100, RX bytes 618MB

15 分钟内 TX 634MB → 平均速率约 7Mbps。对于千兆链路来说带宽远没有用满，但问题不在带宽，而在同步频率太低导致每批数据量不够。

如果把 ha-session-sync-frequency 从 50ms 改为 1ms（最小值），每秒同步频率从 20 批提升到 1000 批，同步速率上限变为 1000 × 256 = 256000 条/秒，远超高峰期新增速率。同时如果把 session-sync-dev 改为同时使用 ha1 和 ha2，吞吐量还能翻倍。

第五步：检查历史切换记录

排查到这里，不禁要问：之前两次计划内切换为什么没出问题？我们查看 HA 事件历史：

# execute ha history
1. 2024-03-15 02:00 - Planned failover (firmware upgrade), session sync: 98.7%
2. 2025-01-10 03:00 - Planned failover (firmware upgrade), session sync: 99.2%
3. 2026-07-02 09:15 - Unplanned failover (thermal shutdown), session sync: 43%

前两次切换都是在凌晨低峰期进行的（凌晨 2-3 点），活跃会话只有约 3000 条，同步完全来得及。而这次切换发生在早高峰，活跃会话 11 万条，同步速率跟不上，就暴露了这个长期存在的隐患。

本质上是：配置在低峰期"够用"，但高峰期不够用，平时根本发现不了。

第六步：查看备机切换后的会话重建情况

备机成为 Active 后，丢失的会话需要由客户端重新建立。我们统计了业务恢复时间线：

时间	事件	活跃会话数
09:15	HA 切换完成	48213（同步过来的）
09:16	VPN Phase 1 重新协商开始	48500
09:20	6 条 VPN 隧道恢复 4 条	52300
09:30	VPN 全部恢复	61200
09:55	业务连接基本恢复	108000
10:20	会话数恢复到正常水平	112000+

从 48213 恢复到正常水平用了约 1 小时，但核心业务（VPN、ERP）在 40 分钟后才基本可用。原因是 VPN 隧道的 IKE 协商需要多轮密钥交换，加上分支 FortiGate 的 DPD（Dead Peer Detection）检测间隔为 30 秒，隧道重建有较长的等待窗口。

解决方案

紧急止血（已完成）

HA 切换已经发生，无法回滚。业务通过自然重连逐步恢复，VPN 隧道在 DPD 触发后自动重建。40 分钟后业务基本恢复，这是本次故障的实际恢复时间。

配置优化（根治）

1. 提升会话同步频率

将 ha-session-sync-frequency 从 50ms 改为 1ms（最小值），大幅提升同步吞吐量：

# FortiGate CLI
config system ha
    set ha-session-sync-frequency 1
end

修改后，同步速率上限从 5120 条/秒提升到 256000 条/秒，完全覆盖高峰期 18000 条/秒的创建速率。

2. 会话同步使用双心跳通道

将 session-sync-dev 改为同时使用 ha1 和 ha2，使会话同步数据可以走两条链路，提供冗余和更高吞吐：

1
2
3

config system ha
    set session-sync-dev "ha1" "ha2"
end

3. 启用 TCP 会话状态同步

FortiGate 7.0+ 版本支持更精细的 TCP 状态同步，可以通过以下配置启用：

config system ha
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-pickup-expected enable     # 启用 expected-session 同步
end

4. 优化 HA 心跳参数

config system ha
    set hb-interval 500    # 心跳间隔从默认2s改为500ms
    set hb-lost-threshold 3  # 丢失3次心跳判定故障（1.5秒而非6秒）
end

这样主设备故障时备机能更快检测到并切换，减少中断窗口。

5. VPN 階道 DPD 间隔优化

各分支 FortiGate 的 DPD 检测间隔从 30 秒改为 5 秒：

# 各分支 FortiGate
config vpn ipsec phase1-interface
    edit "HQ-VPN"
        set dpd on
        set dpd-retryinterval 5
        set dpd-retrycount 3
    next
end

隧道中断后能在 15 秒内检测到并触发重建，而不是等 90 秒。

6.风扇故障修复

联系 FortiGate TAC 更换主设备的两个故障风扇，同时对备设备也做预防性检查。FortiGate 600E 的风扇模块是可插拔的，更换后设备温度恢复正常。

完整优化后的 HA 配置

config system ha
    set group-id 10
    set group-name "FG-HA-Cluster"
    set mode a-p
    set password "xxxxxxxx"
    set hbdev "ha1" "ha2"
    set hb-interval 500
    set hb-lost-threshold 3
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-pickup-expected enable
    set session-sync-dev "ha1" "ha2"
    set ha-session-sync-frequency 1
    set override-disable
    set priority 100
end

根因分析

本次故障的根本原因是 HA 会话同步配置未针对高峰期负载进行优化，形成了"低峰期够用、高峰期不够用"的隐性缺陷。

具体分解：

同步频率过低：ha-session-sync-frequency = 50ms 导致每秒最多同步 5120 条会话，而高峰期每秒新增约 18000 条，差距 3.5 倍。大量会话在主设备上建立但来不及同步到备设备。
同步通道单线传输：session-sync-dev 仅指定 ha1，没有利用第二条心跳线 ha2 的带宽，浪费了冗余资源。
增量同步机制局限：FortiGate 的会话同步只传递会话建立事件，不传递中间状态变更。即使同步速度够快，长连接在切换后的状态信息（TCP 序列号、窗口等）也是不完整的，可能导致部分连接虽然"存在"但无法继续正常通信。
风扇硬件故障是触发因素：两台风扇同时失效导致主设备过热保护关机，触发非计划切换。但风扇故障只是导火索，真正的爆炸点是长期存在的会话同步瓶颈。
缺乏高峰期验证：前两次计划切换都在凌晨低峰期进行，同步率 98%+ 给了团队"HA 配置没问题"的错误信心。从未在高峰期做过 HA 切换演练。

预防措施

1. HA 配置基线标准化

将上述优化后的 HA 配置纳入 FortiGate 标准配置模板，所有新部署和现有集群统一升级。特别关注三个关键参数：

参数	原值	优化值	说明
ha-session-sync-frequency	50ms	1ms	同步频率最大化
session-sync-dev	ha1	ha1+ha2	双通道冗余
hb-interval	2000ms	500ms	快速故障检测

2. 建立 HA 同步率监控

在 Zabbix 中新增 FortiGate HA 同步率监控项：

# FortiGate SNMP/CLI 获取同步会话数
fnsysctl cat /proc/ha_stats | grep "sessions_synced"

# 对应的 Zabbix Item
# Type: SNMP or External Check
# Key: fortigate.ha.session.sync.rate
# Expression: sessions_synced / active_sessions_total * 100
# Trigger: sync rate < 80% for 5 minutes → P1 alert

同步率低于 80% 立即告警，让运维在切换发生前就知道同步不完整。

3. 定期高峰期 HA 演练

每季度一次，在上班高峰期（上午 9-10 点）执行计划内 HA 切换演练，验证：

会话同步率是否 ≥ 95%
VPN 阧道重建时间是否 ≤ 30 秒
业务恢复时间是否 ≤ 60 秒
监控告警是否正常触发

演练流程：提前通知全员 → 手动触发主备切换 → 记录恢复时间 → 回切并验证。

4. 硬件健康监控

FortiGate 600E 支持通过 SNMP 获取风扇状态和温度：

# Zabbix Item
fgFanStatus[port3]  # 风扇运行状态
fgSysTemperature    # 设备温度
# Trigger: fan failed OR temperature > 50°C → P2 alert

风扇故障能在切换前被发现，避免非计划切换。

5. FortiGate 固件升级

当前版本 FortiOS 7.0.13，7.2 版本改进了 HA 会话同步机制（支持更高效的批量同步和 TCP 状态同步）。计划在下个维护窗口升级到 7.2.6。

6. 文档和 SOP 更新

更新以下运维文档：

FortiGate HA 配置标准模板：包含所有优化参数
HA 故障应急预案：明确切换后 5 分钟内检查同步率、10 分钟内评估业务影响
HA 演练 SOP：季度演练流程和验收标准
硬件巡检清单：增加风扇状态、温度、电源冗余检查项

总结

这次故障让我深刻认识到一个教训：HA 双机热备 ≠ 业务零中断，配置"能跑"不等于配置"可靠"。

两年多来 HA 一直"正常工作"，是因为前两次切换恰好在低峰期，同步瓶颈从未被暴露。当真正的非计划切换发生在高峰期时，11 万条会话只同步了 43%，业务中断 40 分钟。这就像一辆车平时在市区 30km/h 没问题，上了高速才发现刹车不够力。

几个关键教训：

HA 配置必须按高峰期负载设计，同步速率要远大于高峰期会话创建速率，留足余量。
HA 演练必须在高峰期做，低峰期演练只能验证切换流程，不能验证业务连续性。
会话同步率必须纳入持续监控，不能等到切换时才发现同步不完整。
硬件故障（风扇、电源、磁盘）是 HA 切换的最常见触发因素，预防性硬件监控比事后切换恢复更重要。

FortiGate HA 的会话同步是个容易被忽视的配置细节，很多团队只关注 session-pickup enable 是否打开，却忽略了同步频率、同步通道、TCP 状态同步这些影响实际同步效果的关键参数。希望这篇排查记录能帮助同行们重新审视自己的 HA 配置，别等到故障发生才追悔莫及。

一次IPSec VPN隧道因MTU不匹配导致ERP系统远程访问异常的排查实录

Fri, 26 Jun 2026 07:00:00 +0000

问题背景

公司在全国有8个分支机构，均通过FortiGate防火墙与总部建立IPSec VPN隧道，日常办公依赖总部的SAP ERP系统进行订单录入、库存查询和财务审批。周一上午9点，华南分公司的30多名员工集中登录ERP系统时，纷纷反馈页面加载极慢——登录界面要等2-3分钟才能显示，进入后点击菜单经常卡死超时，只能反复刷新碰运气。

奇怪的是，Ping总部的服务器完全正常，延迟稳定在15ms左右，traceroute也每一跳都通畅。其他通过VPN访问的服务（如邮件OA）虽然也有点慢，但不像ERP这样完全不可用。网络监控平台上VPN隧道状态显示绿灯"Connected"，流量统计正常，没有任何告警。问题持续了整个上午，严重影响了华南分公司的业务运转，紧急程度极高——财务月结审批被迫延迟，客户订单无法及时录入。

故障现象

故障的表现非常"诡异"，具有典型的MTU问题特征——小包通、大包不通：

现象一：Ping正常但ERP不可用

从华南分公司Ping总部ERP服务器10.10.1.100，100字节的小包100%成功，延迟15ms；但当Ping包大小超过1400字节时：

C:\Users\zhao> ping 10.10.1.100 -l 100 -n 10
Reply from 10.10.1.100: bytes=100 time=15ms TTL=62

C:\Users\zhao> ping 10.10.1.100 -l 1500 -n 10
Request timed out.
Request timed out.
Ping statistics for 10.10.1.100:
    Packets: Sent = 10, Received = 0, Lost = 10 (100% loss)

现象二：ERP登录页面加载极慢或超时

浏览器访问https://erp.company.com时，登录页的HTML框架能加载出来（小数据包），但包含CSS/JS资源的大响应体经常卡在"传输中"状态，最终浏览器报ERR_CONNECTION_TIMED_OUT。

现象三：SSH大文件传输失败

通过SSH从华南服务器向总部scp一个50MB的备份文件，传输开始后几秒就卡死：

1
2
3

$ scp backup.tar.gz admin@10.10.1.50:/tmp/
backup.tar.gz                                    0%    0KB   --:-- ETA
# 卡住不动，最终Connection reset by peer

但小文件（几KB的配置文件）可以正常传输。

现象四：TCP连接建立正常但数据传输中断

用Wireshark在华南分公司的客户端抓包，可以看到TCP三次握手顺利完成，客户端发送HTTP GET请求后，服务器回复了第一个数据包（SYN+ACK后的初始窗口），但当服务器连续发送多个满载（满1460字节）的TCP段时，客户端迟迟收不到后续数据，最终触发TCP重传，重传若干次后连接被reset。

关键发现：抓包中看不到任何ICMP Fragmentation Needed消息，说明IP分片所需的通知被某处拦截了。

排查过程

第一步：确认问题范围——是否只影响华南分公司

第一时间联系其他7个分支，发现华东分公司（同样通过IPSec VPN接入）也反馈ERP访问缓慢，但华北分公司（通过专线接入，不走VPN）完全没有问题。这个对比非常关键——专线正常、VPN异常，问题锁定在VPN隧道层面。

第二步：排除ERP服务器本身的问题

直接在总部内网访问ERP服务器，响应迅速，没有任何异常。检查ERP服务器的系统负载、数据库连接池、Web服务器线程池，全部在正常范围内。确认问题不在服务器端。

第三步：排除VPN隧道连通性问题

VPN隧道状态在FortiGate监控面板上显示为绿色"Up"，路由表正确，Ping小包100%通过。初步排除隧道本身断裂的可能。但注意到隧道接口的MTU配置——FortiGate上VPN隧道接口默认MTU值：

# 总部 FortiGate (FGT-HQ)
FGT-HQ # diagnose netlink interface list vpn-tunnel-HN
Name: vpn-tunnel-HN
  MTU: 1436
  Type: IPSec
  Status: up

# 华南 FortiGate (FGT-HN)
FGT-HN # diagnose netlink interface list vpn-tunnel-HQ
Name: vpn-tunnel-HQ
  MTU: 1436
  Type: IPSec
  Status: up

隧道MTU为1436，这是因为IPSec ESP封装会占用额外头部空间（ESP头8字节 + ESP尾2字节 + ICV 12字节 + 外层IP头20字节 = 42字节，1500-42=1458…但实际FortiGate的默认值是1436，预留了更多空间给可能的UDP封装和NAT-T）。隧道MTU本身看起来没有异常。

第四步：用路径MTU探测定位关键问题

使用Linux的tracepath命令进行路径MTU探测：

# 从华南Linux服务器探测到总部ERP
$ tracepath 10.10.1.100
1?: [LOCAL] 10.20.1.10                          mtu=1500
2:  10.20.1.1 (华南FG内网口)                      mtu=1500
3:  no reply
4:  10.10.1.1 (总部FG内网口)                      mtu=1436  ← 链路MTU突降!
5:  10.10.1.100 (ERP服务器)                       mtu=1436

关键发现：数据包经过VPN隧道后，路径MTU从1500降到了1436。这意味着从ERP服务器发往华南客户端的TCP数据包如果满载1460字节，在经过VPN隧道时会被封装成超过1500字节的IP包，需要分片。

第五步：检查TCP MSS协商

查看FortiGate防火墙的TCP MSS配置：

# 华南 FortiGate
FGT-HN # show full-configuration | grep -i mss
    set tcp-mss-sender 0
    set tcp-mss-receiver 0
    # 隧道接口未配置MSS协商

MSS值为0表示"未设置"——FortiGate不会在TCP SYN/SYN-ACK中主动修改MSS值。这意味着TCP连接建立时，ERP服务器（在1500 MTU的内网环境中）会在SYN-ACK中通告MSS=1460（MTU 1500 - 40字节IP+TCP头），华南客户端同理也在SYN中通告MSS=1460。

这就是问题所在：双方协商的MSS=1460，但数据实际要经过MTU=1436的VPN隧道。ERP服务器按MSS=1460发送满载TCP段，封装后IP包总长 = 1460 + 40(IP头) + 42(IPSec封装) = 1542字节，超过了出接口MTU 1500！这要么需要IP分片，要么被丢弃。

第六步：验证——为什么Ping小包通但大包不通

ICMP Echo Request小包（100字节）加上IPSec封装后仍远小于1500，无需分片，顺利通过。但1500字节的Ping包（IP层已达1500）加上IPSec封装后变成1542字节，超过了物理接口MTU，需要分片。

第七步：为什么没有ICMP Fragmentation Needed反馈

正常情况下，当路由器发现出接口MTU不足以转发不分片的包，且包的DF(Don’t Fragment)位为1时，应该返回ICMP Type 3 Code 4（Fragmentation Needed and DF Set）消息，通知发送方降低包大小。但我们在抓包中完全没看到这类ICMP消息！

进一步排查发现两个原因：

FortiGate的IPS策略拦截了ICMP Fragmentation Needed消息——查看IPS Sensor配置，发现有一条默认规则ICMP.DOS.FRGNeeded将其标记为"Drop"，这是误将路径MTU发现的必要ICMP消息当作DOS攻击了。
ERP服务器的Linux内核默认在TCP包中设置DF位——Linux的net.ipv4.tcp_df默认行为倾向于设置DF位以避免分片带来的性能损失。当DF=1的TCP包在VPN封装后超MTU且被FortiGate丢弃时，本应返回ICMP Fragmentation Needed，但被IPS拦截了。

双重打击：服务器设置了DF位禁止分片 → FortiGate需要返回ICMP通知 → IPS策略把ICMP通知拦截了 → 服务器永远不知道自己发的包太大 → 只能不断重传同样大小的包 → 连接卡死。

第八步：确认根因链路

完整的因果链路：

IPSec隧道封装增加42字节开销 → 隀道MTU从1500降到1436
TCP MSS协商未适配隧道MTU → 双方协商MSS=1460（应为1396）
ERP服务器按MSS=1460发送满载TCP段 → IPSec封装后超物理接口MTU
TCP包DF位=1 → 不能分片，由FortiGate丢弃
FortiGate IPS策略拦截ICMP Fragmentation Needed → 发送方收不到PMTU通知
服务器不断重传超大的TCP段 → 连接永远无法完成数据传输
小包（<1436-40=1396字节）不受影响 → Ping小包正常、ERP小响应体能加载

解决方案

紧急止血（5分钟内生效）

方案一：在FortiGate隧道接口上启用TCP MSS协商

这是最标准的修复方式，在VPN隧道接口上设置MSS Sender和MSS Receiver值，让FortiGate在TCP SYN/SYN-ACK经过隧道时自动修改MSS值，将其限制在隧道MTU允许的范围内：

# 华南 FortiGate
config system interface
    edit "vpn-tunnel-HQ"
        set tcp-mss-sender 1396
        set tcp-mss-receiver 1396
    next
end

# 总部 FortiGate
config system interface
    edit "vpn-tunnel-HN"
        set tcp-mss-sender 1396
        set tcp-mss-receiver 1396
    next
end

MSS值计算：隧道MTU 1436 - 40(IP头+TCP头) = 1396。设置后，FortiGate会在TCP SYN经过隧道接口时将MSS Option从1460修改为1396，确保双方协商出的最大段大小不超过隧道承载能力。

修改后立即生效，无需重启隧道，已有连接会在下次TCP握手时使用新MSS值。

方案二：释放IPS对ICMP Fragmentation Needed的拦截

同时修复IPS策略，放行必要的PMTU Discovery ICMP消息：

# 总部 FortiGate IPS Sensor配置
config firewall ips-policy
    edit "default-ips"
        config rule
            edit 1
                set name "allow-pmtu-icmp"
                set signature "ICMP.DOS.FRGNeeded"
                set status disable
                set log enable
                set action pass
            next
        end
    next
end

将ICMP.DOS.FRGNeeded规则从Drop改为Pass，确保路径MTU发现的ICMP消息能正常传递。这是TCP PMTU Discovery机制正常工作的必要条件。

验证修复效果

修改后从华南分公司测试：

# Ping大包测试
C:\Users\zhao> ping 10.10.1.100 -l 1500 -n 10
Reply from 10.10.1.100: bytes=1500 time=16ms TTL=62
Reply from 10.10.1.100: bytes=1500 time=16ms TTL=62
# 100%成功！

# ERP访问测试——登录页面3秒内完整加载，菜单点击秒级响应

# SCP大文件传输测试
$ scp backup.tar.gz admin@10.10.1.50:/tmp/
backup.tar.gz                                   100%   50MB  12.8MB/s   00:03
# 正常完成！

全量修复——所有分支机构VPN隧道

紧急修复华南后，立即对所有8个分支的VPN隧道接口统一配置MSS：

# 批量配置脚本（总部侧）
for tunnel in vpn-tunnel-HN vpn-tunnel-HD vpn-tunnel-HB vpn-tunnel-HX vpn-tunnel-HW vpn-tunnel-HN2 vpn-tunnel-HS vpn-tunnel-HNE; do
    config system interface
        edit "$tunnel"
            set tcp-mss-sender 1396
            set tcp-mss-receiver 1396
        next
    end
done

并在每台分支FortiGate上同样配置对应的隧道接口。

根因分析

问题的根本原因是 IPSec VPN隧道的MTU开销未被TCP层感知和适配，叠加 IPS策略误杀PMTU Discovery的ICMP消息，形成了"黑盒"效应：

核心根因一：TCP MSS未适配隧道MTU

IPSec ESP封装会在原始IP包外增加约42字节的头部开销，导致物理链路上可承载的有效载荷从1500字节降到约1458字节（考虑NAT-T UDP封装则更低）。但TCP层在握手时协商的MSS是基于直连网段MTU 1500计算得出的1460，完全不知道中间有一个MTU更低的隧道。FortiGate的隧道接口默认未开启MSS协商修改功能（tcp-mss-sender/receiver=0），导致这个信息鸿沟无法自动弥合。

核心根因二：IPS拦截ICMP Fragmentation Needed阻断PMTU发现

RFC 1191定义的Path MTU Discovery机制本应作为MSS协商的后备方案——当TCP包因DF位无法分片而被中间路由器丢弃时，路由器应返回ICMP Type 3 Code 4消息通知发送方降低包大小。但FortiGate的IPS默认规则将此类ICMP消息标记为潜在DOS攻击并丢弃，使得PMTU Discovery机制完全失效。

两个根因叠加：TCP不知道隧道MTU限制（MSS过大），又无法通过ICMP得知自己发的包太大（PMTU Discovery被阻断），导致发送方陷入"盲重传"的死循环。

预防措施

1. 标准化VPN隧道TCP MSS配置

制定VPN隧道配置标准，所有新建隧道接口必须设置MSS值：

# FortiGate VPN隧道MSS配置标准
tcp-mss-sender = 隧道MTU - 40
tcp-mss-receiver = 隧道MTU - 40
# 常见值：
#   IPSec ESP (无NAT-T)：MTU=1458 → MSS=1418
#   IPSec ESP (NAT-T/UDP封装)：MTU=1436 → MSS=1396

将此标准纳入VPN隧道配置Checklist，新建或修改隧道时强制执行。

2. IPS策略优化——放行PMTU Discovery ICMP

在所有FortiGate的IPS Sensor中，将以下ICMP规则从默认的Drop改为Pass或至少Disable：

ICMP.DOS.FRGNeeded (Type 3 Code 4 - Fragmentation Needed)
ICMP.Info.SourceQuench (Type 4 - Source Quench，虽已废弃但部分设备仍使用)

这些ICMP消息是IP网络正常运行的必要组成部分，误杀它们会导致PMTU Discovery失效，远比所谓的DOS风险危害更大。

3. 定期路径MTU探测巡检

编写自动化巡检脚本，每周对所有VPN隧道执行路径MTU探测：

#!/bin/bash
# pmtu_check.sh - VPN隧道路径MTU巡检
BRANCHES=("10.20.1.0/24 华南" "10.30.1.0/24 华东" ...)
HQ_ERP="10.10.1.100"
ALERT_THRESHOLD=1400

for branch in "${BRANCHES[@]}"; do
    network=$(echo $branch | awk '{print $1}')
    name=$(echo $branch | awk '{print $2}')
    gw=$(echo $network | sed 's/0\/24/1/')
    
    # 从分支网关探测路径MTU
    pmtu=$(tracepath -n $HQ_ERP 2>&1 | grep "pmtu" | tail -1 | awk '{print $NF}')
    
    if [ "$pmtu" -lt "$ALERT_THRESHOLD" ]; then
        echo "[ALERT] $name 隧道路径MTU异常: $pmtu (期望 >= $ALERT_THRESHOLD)"
    else
        echo "[OK] $name 隧道路径MTU正常: $pmtu"
    fi
done

当路径MTU低于阈值时自动告警，防止MSS配置被意外修改或隧道MTU因封装方式变化而降低。

4. 网络变更流程纳入MTU审查

在FortiGate配置变更审批流程中加入MTU/MSS审查环节：

新增VPN隧道 → 必须检查MSS配置
更改IPSec封装方式（如从ESP改为ESP+UDP封装）→ 重新计算MSS值
修改IPS策略 → 检查是否影响PMTU Discovery ICMP放行
更换ISP或链路类型 → 测试路径MTU是否变化

5. 文档化MTU计算方法

编写内部网络运维手册中的MTU计算章节，记录所有VPN隧道的：

隧道名称	封装方式	预留开销	隧道MTU	MSS值	物理接口MTU
vpn-HN	ESP+NAT-T	64字节	1436	1396	1500
vpn-HD	ESP	42字节	1458	1418	1500

让每位运维工程师都能快速查阅和计算正确的MSS值。

总结

这次故障的排查给我留下了深刻的教训：

教训一：Ping通不代表网络通。 Ping只是ICMP小包测试，它能证明链路可达，但完全不能证明大包传输能力。在涉及VPN隧道的故障排查中，必须用不同大小的Ping包（ping -l 1500）或tracepath进行路径MTU探测，才能发现隐藏的MTU问题。

教训二：MTU/MSS不匹配是VPN环境的"经典杀手"。 IPSec封装带来的MTU缩减是必然的、可计算的，但TCP层对此毫不知情。如果不主动在隧道接口配置MSS协商修改，就等于让TCP盲目发送超大数据包，轻则分片降速，重则完全卡死。这是VPN运维的基本功课，不能等出事了才补。

教训三：IPS策略不能一刀切地拦截ICMP。 安全策略的"拦截一切ICMP"看似防御了ICMP-based DOS攻击，实则破坏了PMTU Discovery这一网络基础机制。安全与可用必须平衡，对于RFC定义的必要ICMP消息（Fragmentation Needed、Time Exceeded等），必须放行。

教训四：故障排查要善于利用"小包通、大包不通"这个特征。 当你发现小请求能成功但大数据传输失败，或者Ping通但应用不通，第一反应就应该是检查MTU/MSS。这个特征太过典型，不必浪费时间去查服务器性能、应用日志、路由表——直接从MTU入手往往能最快定位。

最终，一个1436的隧道MTU和未设置的MSS参数，加上一条过于激进的IPS规则，三者合力制造了一个"Ping正常但业务瘫痪"的经典假象。修复只需两行配置，但理解它需要整个IP/TCP栈的知识。运维不只是改配置，更是理解协议。

一次FortiGate防火墙策略配置错误导致内网DNS解析失败的排查实录

Fri, 15 Aug 2025 20:00:00 +0000

一、问题背景

2026年5月中旬，公司新收购的一家分公司完成网络改造，核心交换机升级为华为S7706，出口防火墙替换为FortiGate 100F，由我负责整体网络运维支持。改造完成后前三天网络运行正常，但从第四天开始，陆续有员工反映"网页打开很慢"、“有些网站完全打不开”、“微信能发消息但图片加载很慢”。

由于分公司没有专职网络工程师，问题上报到总部后由我远程协助排查。初期怀疑是ISP链路问题，联系运营商测速后确认出口带宽正常，100M专线上下行均达标，问题指向内网。

影响范围逐渐扩大，到第二天已有约40%的员工反映网络异常，部分关键业务系统（如ERP、OA）访问也出现间歇性超时，情况比较紧急。

二、故障现象

通过远程桌面连接到分公司的一台运维跳板机，我进行了以下几项基础测试，汇总故障现象如下：

1. 网络连通性测试

ping 8.8.8.8 通，延迟约12ms，无丢包；ping www.baidu.com 间歇性超时，大约30%的ICMP包被丢弃，且延迟波动极大（12ms~3000ms）。

2. DNS解析测试

使用 nslookup 测试内网DNS服务器（由AD域控兼做DNS，IP为192.168.10.10）：

C:\> nslookup www.baidu.com 192.168.10.10
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.

多次尝试后偶尔能解析成功，但响应时间普遍超过5秒。换成公共DNS（114.114.114.114）测试，现象一致。

3. HTTP/HTTPS访问测试

用curl测试HTTP访问：

1
2

C:\> curl -w "%{time_total}\n" -o /dev/null -s http://www.baidu.com
5.237

首次访问耗时超过5秒，后续复用连接后有所改善，但刷新页面后问题复现。

4. 关键观察

有一个重要现象：使用IP地址直接访问的业务系统（如 http://10.10.1.20）完全正常，延迟稳定；而使用域名访问的系统（如 http://oa.company.com）则间歇性超时。这进一步将问题范围缩小到DNS解析环节。

三、排查过程

第一步：确认DNS服务器本身是否正常

首先排除DNS服务器（AD域控）自身故障的可能性。远程登录到域控服务器，检查DNS服务状态：

1
2
3

PS> Get-Service DNS
Status   Name   DisplayName
Running  DNS    DNS Server

DNS服务运行正常。进一步检查DNS日志，发现大量"Event ID 4013"和"Event ID 3150"的警告日志，提示"DNS服务器无法解析外部域名，转发器超时"。

查看DNS转发器配置，发现配置了四个转发器：

202.96.128.86（本地运营商DNS）
114.114.114.114
8.8.8.8
8.8.4.4

看起来配置没有问题，但为什么解析会超时？

第二步：抓包分析DNS流量

在域控服务器上启动Wireshark，过滤DNS流量（UDP 53端口），然后进行解析测试：

`1`	`C:\> nslookup www.google.com 192.168.10.10`

抓包结果发现了关键线索：

域控向外网转发DNS查询时，发出的UDP包目标端口53，但完全没有收到响应包
域控随后尝试TCP 53重试，同样没有响应
整个过程中，域控本身可以ping通所有转发器IP，网络层是通的

这说明DNS查询包在出去的路上被丢了，而不是DNS服务器本身的问题。

第三步：检查FortiGate防火墙策略

分公司新上线的FortiGate 100F是本次网络改造的新增设备，重点怀疑对象。通过FortiCloud远程登录FortiGate管理界面，检查防火墙策略。

FortiGate的策略配置相对复杂，新上线时由实施工程师配置，我之前只做了基础验收测试。逐条检查策略，发现了一条当时为"临时测试"创建的策略，规则如下：

Policy ID: 5
Name: DNS_OUT_TEST
Source: all
Destination: all
Service: DNS
Action: DENY
Schedule: always
Log: disable

这条策略的意图是"临时禁止某个测试用的DNS流量"，但配置时Source设成了all，导致所有出站DNS流量（UDP/TCP 53）都被这条策略匹配并丢弃了。

更糟糕的是，这条DENY策略的序列号是5，排在所有ALLOW策略之前（FortiGate策略是自上而下匹配的）。也就是说，任何出站DNS流量在到达后面的ALLOW策略之前，先被这条策略拦截了。

第四步：验证猜测

为了验证是不是这条策略的问题，我先记录当前策略配置，然后临时禁用Policy ID 5，再进行DNS解析测试：

C:\> nslookup www.baidu.com 192.168.10.10
Server:  dc01.company.com
Address:  192.168.10.10

Non-authoritative answer:
Name:    www.a.shifen.com
Addresses:  110.242.68.4
            110.242.68.3
Aliases:  www.baidu.com

解析成功，响应时间不到100ms！进一步测试网页访问、业务系统访问，全部恢复正常。

第五步：追溯策略来源

联系当时负责实施的工程师，了解到这条策略是他做DNS代理测试时创建的，测试完后忘记删除了。由于FortiGate的策略匹配是顺序制的，这条DENY策略插在策略列表靠前的位置，导致所有DNS出站流量被静默丢弃。

之所以前三天没有暴露问题，是因为当时客户端DNS缓存尚未过期，且部分员工使用的是浏览器内置的DNS over HTTPS（DoH），绕过了系统DNS设置，所以问题有延迟才集中爆发。

四、解决方案

问题的根因已经明确，解决步骤如下：

1. 删除错误的测试策略

登录FortiGate，删除Policy ID 5：

1
2
3

config firewall policy
    delete 5
end

2. 优化DNS流量策略

原来策略列表中，DNS出站流量依赖一条"any to any"的通用放行策略，不够精细。新建专用策略，明确允许内网DNS出站：

config firewall policy
    edit 0
        set name "DNS_OUTBOUND"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "RFC1918"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "DNS" "DNS-TCP"
        set logtraffic all
    next
end

关键点：

明确指定了源接口（internal）和目的接口（wan1）
服务明确限定为DNS（UDP 53）和DNS-TCP（TCP 53）
开启全量日志，便于后续排查

3. 优化DNS服务器转发器配置

原先DNS转发器配置了四个，其中8.8.8.8和8.8.4.4从分公司网络访问延迟较高（分公司出口是电信专线，访问Google DNS需要绕路）。优化后的转发器列表：

优先级	DNS服务器	说明
1	202.96.128.86	本地电信DNS，延迟最低
2	114.114.114.114	国内公共DNS，备用
3	内网根提示	直接迭代查询，最后兜底

4. 在FortiGate上启用DNS过滤的安全功能

FortiGate有内置的DNS过滤功能，可以阻断恶意域名解析。在优化后的策略上启用了此功能：

config firewall policy
    edit 10
        set dnsfilter-profile "default"
    next
end

五、根因分析

本次故障的根本原因是FortiGate防火墙策略配置错误，具体可以拆解为以下几个层面：

直接原因：一条Source为"all"的DNS DENY策略被错误地保留在策略列表中，且序列号靠前，导致所有出站DNS流量被静默丢弃。

间接原因：

策略审查缺失：新设备上线的策略清单没有经过严格的Code Review式审查，测试策略未及时清理
缺乏策略变更管理：FortiGate策略的增删改没有走变更流程，实施工程师可以随意添加策略
监控覆盖不足：FortiGate的DNS流量被DENY的日志没有开启（原策略Log设置为disable），导致无法通过日志快速发现问题
DNS解析超时表现不直观：客户端DNS解析超时后会有重试，ICMP ping通但HTTP慢，这种"半通不通"的现象容易引导排查方向偏离

六、预防措施

针对本次故障暴露的问题，制定了以下预防措施：

1. 建立防火墙策略变更管理流程

所有FortiGate策略变更必须满足：

变更前填写《防火墙策略变更申请表》，注明策略用途、源目地址、服务端口、有效期
测试策略必须设置明确的有效期（通过FortiGate的schedule功能实现自动过期）
变更后由第二人复核策略列表

2. 启用关键策略的日志功能

所有DENY类策略必须开启日志（set logtraffic all），以便在日志中心（FortiAnalyzer或FortiCloud）中监控被拦截的流量，快速发现问题。

3. 部署网络监控告警

在监控系统中增加以下告警项：

DNS解析成功率低于95%时告警
FortiGate策略命中次数异常（如某条DENY策略突然有大量命中）时告警
内网到外网DNS服务器的延迟超过100ms时告警

具体实现可以用Prometheus + Blackbox Exporter做DNS探测，告警推送到企业微信。

4. 标准化新设备上线检查清单

制作了《FortiGate上线检查清单》，包含以下关键检查项：

所有测试策略已清理或设置过期时间
策略序列号经过合理性审查（宽策略在前，窄策略在后）
DENY策略均开启日志
DNS、NTP等关键基础服务的策略已明确配置
保存配置（execute backup）

七、总结

这是一次典型的"配置残留"引发的网络故障。FortiGate作为状态检测防火墙，策略匹配顺序是自上而下，一条配置不当的DENY策略所产生的破坏力，不亚于一次DDoS攻击。

几个值得记取的教训：

测试策略必须有过期机制。FortiGate支持schedule设置策略有效期，所有临时测试策略都应该用这个功能，而不是依赖"记得删除"
DNS是网络的基础中的基础。DNS出问题时的表现非常具有迷惑性——ping IP通但域名不通，很容易被误判为应用层问题
抓包是最直接的排查手段。在本次故障中，Wireshark抓包看到的"有去无回"现象，是锁定问题方向的关键
策略变更要有审计。FortiGate的config revision功能可以定期自动备份配置，建议开启

网络运维工作中，“最小化变更影响"和"可回溯性"是两个核心原则。这次故障如果配置备份和策略审计做到位，本可以在5分钟内定位问题，而不需要花费近2个小时逐步排查。

本文所有IP地址、域名均已脱敏处理，技术细节基于真实案例整理。