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

发表于 分类于 ， 阅读次数： 本文字数： 2.7k 阅读时长 ≈ 10 分钟

一、问题背景

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）：

1
2
3
4
5
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的策略配置相对复杂，新上线时由实施工程师配置，我之前只做了基础验收测试。逐条检查策略，发现了一条当时为”临时测试”创建的策略，规则如下：

1
2
3
4
5
6
7
8
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解析测试：

1
2
3
4
5
6
7
8
9
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出站：

1
2
3
4
5
6
7
8
9
10
11
12
13
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过滤功能，可以阻断恶意域名解析。在优化后的策略上启用了此功能：

1
2
3
4
5
config firewall policy
    edit 10
        set dnsfilter-profile "default"
    next
end

五、根因分析

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

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

间接原因：

  1. 策略审查缺失：新设备上线的策略清单没有经过严格的Code Review式审查，测试策略未及时清理
  2. 缺乏策略变更管理：FortiGate策略的增删改没有走变更流程，实施工程师可以随意添加策略
  3. 监控覆盖不足：FortiGate的DNS流量被DENY的日志没有开启（原策略Log设置为disable），导致无法通过日志快速发现问题
  4. 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攻击。

几个值得记取的教训：

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

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

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