防火墙 on Zero Day Notes

FortiGate 策略变更致分支机构 VPN 隧道全断的复盘

Fri, 06 Dec 2024 09:15:00 +0000

问题背景

公司采用 Hub-Spoke 组网架构，总部部署一台 FortiGate 200F 作为 VPN 中心节点，5 个分支机构各部署一台 FortiGate 60F，通过 IPSec Site-to-Site VPN 隧道互联。分支访问总部内网的流量以及分支间互访流量都经过总部中转。隧道使用 IKEv2 + 预共享密钥认证，运行稳定超过 2 年。

故障现象

12 月 6 日上午 9:00，网络安全工程师按计划实施了一次防火墙策略优化——在总部的 FortiGate 200F 上新增了一条允许内网网段出站访问互联网的策略。变更完成后约 5 分钟，运维监控告警：所有 5 个分支机构的 IPSec 隧道全部 Down。

FG200F # get vpn ipsec tunnel summary
Branch-SH-DC  : down
Branch-BJ-DC  : down  
Branch-GZ-DC  : down
Branch-CD-DC  : down
Branch-SZ-DC  : down

总部内网终端无法 ping 通任何分支机构的服务器，分支机构的同事也无法访问总部的 ERP 和 OA 系统。全部分支-总部通信中断。

排查过程

第一步：确认是策略变更导致

回滚了最近一次的防火墙策略变更：删除新增的出站互联网访问策略。5 分钟后隧道自动全部恢复。确认是新增策略导致了隧道中断。

第二步：分析新增策略为什么影响 VPN

新增的策略：

config firewall policy
    edit 0
        set name "Allow Internal to Internet"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "all"           # <--- 问题所在
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable              # <--- 问题所在
    next
end

策略匹配 srcaddr "all" + dstaddr "all"，且开启了 nat enable（源 NAT）。

在 FortiGate 中，防火墙策略是按顺序匹配的（从上到下）。当这条"允许内网到互联网"的策略被放在策略列表顶部（edit 0）后，所有从内网出发的流量——包括发往分支机构网段的 VPN 流量——在到达 VPN 策略之前就被这条"Internet 出站"策略匹配了。

更致命的是 nat enable：VPN 流量被这条策略匹配后，在路由前被做了源 NAT，源 IP 变成了 wan1 的公网 IP，于是后续的 VPN 策略无法根据原始源 IP 匹配到对应的隧道规则。

第三步：验证流量路径

FG200F # diagnose sniffer packet any "host 10.2.1.1 and host 10.3.1.1" 4
interfaces=[any]
filters=[host 10.2.1.1 and host 10.3.1.1]
10. packets captured

pkt 1: 10.2.1.1 -> 10.3.1.1: icmp: echo request  
  # 进入 internal 口，源 10.2.1.1（总部内网）
  # 匹配策略 0 → NAT → 源 IP 变为 100.1.1.1（wan1公网IP）
  # 后续没有策略匹配 100.1.1.1 → 10.3.1.1
  # 数据包被丢弃

VPN 流量被"劫持"到了错误的安全策略中，并被 NAT 破坏了原始的源 IP。

第四步：完整策略列表分析

FG200F # show firewall policy
# 策略 0（新增）: internal → wan1, src: all, dst: all, NAT enabled
# 策略 1: internal → wan1, src: Branch-SH, dst: Branch-SH-Subnet, NO NAT
# 策略 2: internal → wan1, src: Branch-BJ, dst: Branch-BJ-Subnet, NO NAT
# ...

VPN 策略（1-5）虽然存在，但由于策略 0 的 srcaddr "all" 完全覆盖了所有流量，VPN 策略永远不会被命中。FortiGate 的策略匹配是首次匹配即停止。

解决方案

修正策略顺序和匹配条件

# 必须先配置 VPN 策略（编辑为更高的序号，确保先匹配）
config firewall policy
    edit 6
        set name "Allow Internal to Internet"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "Internal-LAN"       # 明确指定内网地址对象
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable
    next
end

# 确保 VPN 策略在新互联网策略之前（策略 1-5）

或者更优的方案：在互联网策略中使用 negate 排除 VPN 目标：

config firewall policy
    edit 0
        set name "Allow Internal to Internet"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set dstaddr-negate enable           # 否定all
        # 再加明确的排除分支地址对象
        ...
    next
end

根因分析

直接原因：新增的互联网出站策略使用了 srcaddr "all" + dstaddr "all" 的宽泛匹配条件，加上被放置在策略列表最顶部，且开启了 NAT，导致 VPN 流量在匹配到正确的 VPN 策略之前就被截获并做了错误的 NAT 处理。

深层原因：

缺少"变更影响分析"流程——没人审查新增策略对现有 VPN 策略的影响
策略列表缺乏优先级规划——VPN 策略在下方、通用出站策略在上方是反模式
未使用 srcaddr-negate 或明确的地址对象来缩小匹配范围

预防措施

策略编排规范：VPN 策略必须在任何宽泛匹配的出站策略之前，且 VPN 策略必须包含精确的源/目标地址对象
策略变更前的影响分析：新增策略后通过 diagnose firewall proute list 检查路由-策略匹配路径
变更窗口和回滚计划：涉及防火墙策略的变更必须有明确的回滚步骤（像这次直接删除策略 0 就恢复了）
地址对象标准化：所有策略必须使用有意义的地址对象名称（Branch-SH-Subnet），禁止裸写 IP 范围
策略注释强制填写：每条策略必须写清楚"为什么需要这条策略"，方便变更时审查
策略变更审批双签：涉及网络的防火墙策略变更需要第二人复核，重点检查是否会"劫持"其他流量

总结

防火墙策略管理最危险的错误不是"写了一条多余的策略"，而是阻塞或破坏了一条关键的策略。在 FortiGate 的策略模型中，“all-to-all with NAT on top"是一条必须极其谨慎使用的规则——它的匹配范围只有"所有流量"和"不匹配"两种可能，而"所有流量"意味着 VPN、管理流量、监控流量等一切都会被它捕获。在防火墙上，精确永远比宽泛更安全，顺序永远比便利更重要。

Docker Swarm Overlay 跨节点不通，问题卡在哪？

Thu, 08 Jun 2023 21:15:00 +0000

问题背景

公司微服务部署在 Docker Swarm 集群（1 Master + 5 Worker），使用 overlay 网络 swarm-net 实现跨节点容器互访。集群运行稳定超过一年，所有服务通过 Docker Service 部署，容器 IP 由 overlay 网络自动分配。

故障现象

6 月 8 日晚 9:00，运维收到大量服务异常告警：API Gateway 返回 502 Bad Gateway，所有后端服务的健康检查失败。进一步排查发现一个关键模式：同一节点上的容器之间通信正常，跨节点的容器通信全部失败。

# 在 node-01 上
$ docker exec api-gateway curl http://user-service:8080/health
curl: (7) Failed to connect to user-service port 8080: Connection refused

$ docker exec api-gateway curl http://node-03:8080/health  # user-service在node-03上
curl: (28) Connection timed out after 5000ms

# 但node-03上本地访问正常
$ docker exec user-service curl http://localhost:8080/health
{"status":"UP"}    # 本地ok

所有 overlay 跨节点通信全部中断。

排查过程

第一步：Swarm 控制面状态

$ docker node ls
ID                   HOSTNAME   STATUS  AVAILABILITY  MANAGER STATUS
abc123def456 *       node-01    Ready   Active        Leader
def456ghi789         node-02    Ready   Active
ghi789jkl012         node-03    Ready   Active
jkl012mno345         node-04    Ready   Active
mno345pqr678         node-05    Ready   Active
pqr678stu901         node-06    Ready   Active

所有节点状态正常，Leader 可达。

第二步：overlay 网络状态

$ docker network inspect swarm-net | jq '.[].Peers'
[
  {"Name": "a1b2c3d4e5f6", "IP": "10.10.0.2"},
  {"Name": "a1b2c3d4e5f7", "IP": "10.10.0.3"},
  {"Name": "a1b2c3d4e5f8", "IP": "10.10.0.4"},
  {"Name": "a1b2c3d4e5f9", "IP": "10.10.0.5"},
  {"Name": "a1b2c3d4e5fa", "IP": "10.10.0.6"},   # node-06 缺失！
  {"Name": "a1b2c3d4e5fb", "IP": "10.10.0.7"},
]

node-06 上的 peer 条目还在，但实际通信中 node-06 处于孤立状态。这说明 control plane 的 gossip 协议分发正常，但 data plane（VXLAN 隧道）出了问题。

第三步：检查 VXLAN 端口

Docker overlay 网络使用 VXLAN（端口 4789/UDP）在节点之间建立隧道：

# node-06 上
$ ss -tunlp | grep 4789
# 空——VXLAN 端口未监听！

# 检查防火墙规则
$ iptables -L INPUT -n --line-numbers | grep 4789
# 无结果

$ iptables -L INPUT -n | tail -5
REJECT   all  --  0.0.0.0/0   0.0.0.0/0   reject-with icmp-host-prohibited

节点 6 的 iptables 有一条全局 REJECT 规则在末尾，且没有 4789/udp 的允许规则——所有 VXLAN 流量被防火墙拒绝。

第四步：追溯防火墙变更

1
2
3

$ cat /etc/sysconfig/iptables | grep -C3 "May 25"
# May 25 某运维执行了 "iptables-save > /etc/sysconfig/iptables" 
# 覆盖了原有规则文件，但原文件中有VXLAN允许规则，新保存的版本没有

检查 /var/log/secure：当天下午，有人在 node-06 上执行了 systemctl restart iptables，导致运行时 iptables 规则被重新加载为文件中的版本——而文件中恰好缺失了 Docker 自动添加的 VXLAN 规则。

Docker daemon 在启动时会在 iptables 中自动添加 overlay 网络所需的规则，但 Docker 不会将这些规则持久化到配置文件中。一旦 iptables 服务被重启，Docker 自动添加的规则就会丢失。

解决方案

紧急恢复：重启 node-06 上的 Docker daemon

`1`	`systemctl restart docker`

Docker 重启后自动重新添加了 iptables 规则，VXLAN 端口恢复监听。

固化 Docker 防火墙规则：

1
2

# 重启docker后立即固化规则
iptables-save > /etc/sysconfig/iptables

配置 iptables 持久化服务：安装 iptables-services，确保每次 Docker 启动后自动持久化规则。

根因分析

直接原因：node-06 的 iptables 被重启后丢失了 Docker overlay 网络的 VXLAN 规则，导致跨节点容器通信中断。Swarm 集群中只要有一个节点 VXLAN 不通，所有指向该节点的流量都会超时。

深层原因：

Docker 自动生成的 iptables 规则不会自动持久化
缺少"防火墙重启后自动恢复 Docker 规则"的机制
集群缺少 overlay 网络健康检测

预防措施

iptables 持久化策略：所有 Docker 节点配置 iptables-services 并在 /etc/docker/daemon.json 中设置 "iptables": true
防火墙变更流程：修改 iptables 配置后必须验证 Docker overlay 网络连通性
overlay 网络心跳监控：定期从每个节点 ping overlay 网络中的固定测试容器
Swarm 节点健康检查：监控每个节点的 gossip 协议心跳和 VXLAN 隧道状态
配置管理：iptables 规则文件纳入版本管理，变更可审计

总结

Docker overlay 网络的脆弱点在于它依赖 iptables 的动态规则，而这些规则不在任何配置文件中。一旦有人重启了防火墙服务，Docker 不会自动感知并重建规则。这个设计意味着：在 Docker 集群中，操作 iptables 服务就等同于操作网络基础设施。如果你不知道 Docker 在背后往 iptables 里写了什么，那就别碰 iptables。