简介FortiOS 7.0.0 管理指南以 PDF 形式提供是 Fortinet 官方面向防火墙管理员、网络安全工程师和初学者的完整参考手册。内容从 Getting Started 讲起说明不同型号差异并分别介绍 GUI 图形界面与 CLI 命令行的连接、语法和权限用法还包含 FortiExplorer 的接入与升级步骤基本管理章节涵盖注册、FortiCare、FortiGate Cloud 登录、配置备份和安装故障排除仪表盘与 FortiView 部分则指导创建仪表盘、添加小工具、查看会话和来源信息同时覆盖静态/动态路由、DHCP、IPsec、SSL-VPN 等安全监控模块以及设备清单和会话分析。资源为单文件 PDF压缩包内共 1 个 pdf大小 29.34MB目录结构完整、层级清晰适合离线查阅与检索。目前已有 224 人学习下载。对准备部署 FortiOS 7.0.0 或正在排障的运维人员来说能从中快速定位重点配置路径和监控方法可作为日常管理中的长期技术手册。1. 打开这份 FortiOS 7 管理指南前先想清楚你要解决什么我刚接手第一台 FortiGate 时对着 FortiOS 7 Administration Guide 翻了两个下午越翻越困。它不像速查手册更像一张庞大网络设备的地图。真正让我读懂它的是第三次带事故去翻内网一台服务器要对外发布 HTTPS 服务GUI 上按钮点了不少外面却始终不通。最后才发现我新建的策略排在一条老的 deny 策略后面而 FortiOS 的策略匹配是自上而下、首条命中。这个教训让我意识到这份指南真正要教会你的不是点按钮而是理解策略、路由、会话和升级这几条主线。这篇文章写给准备接手 FortiOS 7 设备的人从管理入口选型、策略顺序、NAT 与路由到升级和高可用的避坑记录再到用日志做巡检每一章都能直接映射到命令和配置。适合的读者是有一年以上网络基础、想把 FortiGate 用明白的从业者不是来泛读产品介绍的。2. 管理入口先选对GUI、CLI 与 REST API 三块工作面怎么切2.1 三块管理面各自擅长什么为什么排障时不能只看 Web 界面FortiOS 7 设备默认提供 Web GUI、SSH/串口 CLI 和 REST API 三套管理入口。很多人习惯只开 Web GUI但 GUI 其实擅长单点操作不擅长批量查状态。接手一台来历不明的设备时我一般不会在浏览器里逐页点因为 GUI 上的策略列表默认只显示前几十条而且你看不到被默认隐式规则挡住的那部分流量。CLI 能一口气把完整配置拉出来API 能按固定格式拿数据这两种才是排障的主战场。三者边界很清楚GUI 适合改单条配置、看统计面板、做证书上传这种一次性操作CLI 适合巡检、批量改动、调试数据流、在应急时翻全量配置REST API 适合固化操作流程、定期巡检、批量纳管。下面这张表是我给自己团队的选型参考管理面登录方式适合场景我的建议Web GUIHTTPS 443单条配置调整、证书与固件上传变更前别只用它看状态CLISSH/串口全量备份、调试流量、故障定位至少练熟本文这套命令REST APIHTTPS Token批量巡检、自动化运维先用只读接口跑起来CLI 登录默认走 SSH我一般用终端里的ssh admin设备IP进入。刚上手的机器如果 SSH 没开先在 GUI 的系统管理里打开。改任何配置前我都会先敲get system status把固件版本和当前启动分区记下来。版本不同命令行为和默认参数会有差异这个习惯帮我在升级回滚时省了很多事。2.2 从版本到会话我常敲的一套 CLI 体检命令一套适合刚接手设备时的只读体检命令我通常按下面顺序敲get system status get system performance status get system interface physical get router info routing-table all get firewall policy listget system status输出固件版本、主机名、启动分区和 HA 状态先确认设备处在什么状态。get system performance status看 CPU、内存和会话数如果会话数接近上限很多诡异断流都能从这里找到线索。get system interface physical列出所有物理接口的连接状态方便确认端口有没有被禁用、协商速率是否正常。get router info routing-table all输出完整路由表排查“能 ping 通网关但业务不通”的时候先看路由在不在。get firewall policy list列表里能看到每条策略的命中次数这是判断策略是否生效的最直接证据。真正定位单条流量问题时CLI 的 debug flow 是首选比抓包快得多。我常用的过滤组合如下diagnose debug flow filter saddr 10.1.1.20 diagnose debug flow filter daddr 10.2.1.10 diagnose debug flow filter dport 443 diagnose debug flow show function-name enable diagnose debug enable跑几秒或者让报障方复现一次然后立刻执行diagnose debug disable关闭避免日志刷爆控制台。这里三个 filter 参数可以单独用也可以叠加叠加时是“与”的关系。show function-name enable会把匹配过程细化到函数级虽然输出量变大但能看到流量到底卡在路由查找还是策略匹配。这套命令的缺点是会吃 CPU生产环境别长时间开启。提示debug flow 输出里如果出现 policy deny 字样优先去看对应策略的命中次数别急着改策略很可能只是源地址对象没把新网段包含进去。2.3 用 REST API 批量拉配置建 token 和最小脚本模板Web GUI 里管理员的创建路径我不用多讲真正要说的是 REST API 的 token。在系统管理里新建一个 REST API 管理员时系统会生成一串 token只在创建那一刻完整显示一次关掉页面就看不到了建议直接存进密码管理器。权限上不要一上来就授超级管理员可以建一个只读权限的巡检账号避免脚本误操作。最小脚本模板我会写成这样#!/bin/bash # 只读巡检脚本拉取接口配置并格式化输出 FGT_IP10.0.0.1 FGT_TOKEN填入你的只读 token curl -ks -H Authorization: Bearer ${FGT_TOKEN} \ https://${FGT_IP}/api/v2/cmdb/system/interface \ | python3 -m json.tool-k是因为默认是自签证书测试环境先用它绕过证书校验生产环境建议把设备 CA 放进系统信任库去掉这个参数。Authorization: Bearer是 FortiOS REST API 的固定写法token 放在 Bearer 后面。/api/v2/cmdb/...是配置管理接口路径不同小版本对路径前缀有细微差异以当前设备 API 参考为准。我只在脚本里保留了 interface 这一项你还可以替换成firewall/policy或system/status来拉策略和系统状态。脚本跑通之后下一步就是把它丢进 crontab每周跑一次。能做到这一步你已经比只看 GUI 的人省出至少一半排障时间。3. 安全策略与对象先理解“首条命中”再动手建规则3.1 策略的匹配顺序为什么是自上而下而不是最长匹配不少从路由背景转过来的工程师最容易把策略匹配想成最长匹配这是个很贵的误解。FortiOS 的安全策略在两个接口之间从上到下逐条匹配命中的第一条就是最终结果后面的策略哪怕更精确也不会被执行。也就是说一条写在最前面的宽松 deny能把后面所有精确的 allow 全部挡住。我在给客户做策略梳理时经常看到这样的顺序deny 研发区访问生产区 accept 办公网访问 Web 服务器 ... implicit deny最后一条是隐式规则这时候如果办公网访问 Web 服务器失败问题不一定在第三条 allow 上而可能是第一条 deny 的源地址对象范围写大把办公网也包含了。排查方法很简单先看策略列表里每条策略的命中次数再配合日志里的 policyid 对号入座。记住一个原则能放进对象里的地址尽量用对象不要把一串 IP 直接散落在策略里。另一个容易忽略的点是FortiGate 的接口对之间如果没有策略流量直接丢弃而且不会产生明显日志。管理面到数据面的流量同样会过策略实战中很多人忘记加“允许管理网段访问设备本身”的策略导致远程管理时断时续。3.2 把地址和服务抽成对象避免策略变成一锅粥地址对象的本质是一张“命名的 IP 清单”。我一般会先建地址对象再建服务对象最后才建策略。这样后续扩容只改对象不用动策略。CLI 创建地址对象的写法如下config firewall address edit WEB_SRV set type ipmask set subnet 10.1.1.10 255.255.255.255 next endtype ipmask表示这是一个 IP 加掩码的对象也可以换成iprange来表示一段地址。subnet后面的两个参数分别是 IP 和掩码注意这里写的是点分十进制掩码不是前缀长度。对象建好后策略里的 srcaddr 和 dstaddr 都可以直接引用这个名字。服务对象可以用内置服务名也可以建一个服务组把常用端口打包config firewall service group edit WEB_PORTS set member HTTP HTTPS next endmember里填的是 FortiOS 内置服务名HTTP对应 80HTTPS对应 443。如果你的业务端口不是标准端口可以先用config firewall service custom建自定义服务再把自定义服务加入服务组。对象命名的坑我在早期踩过中文名和特殊字符在旧版本里能建升级后可能变成空白对象策略引用了空对象后会被静默处理。现在我的新环境全部用 ASCII 命名比如WEB_SRV、OFFICE_NET省得升级时给自己挖坑。3.3 用 CLI 建一条办公网访问 Web 的策略并把日志打开先确认接口名和对象名都存在用get system interface physical查接口用show firewall address查对象。确认无误后再建策略避免引用不存在对象导致提交报错。一个典型策略如下config firewall policy edit 101 set name office-to-web set srcintf port1 set dstintf port3 set srcaddr OFFICE_NET set dstaddr WEB_SRV set action accept set schedule always set service HTTPS set logtraffic all set nat enable next endsrcintf和dstintf分别指定流量入口和出口接口。action accept表示放行如果要做成阻断策略改成set action deny。schedule always表示全时段生效生产环境里经常要换成业务时段。service HTTPS只放行 443 端口。logtraffic all是这里最关键的一个参数它让 FortiOS 同时记录会话建立和拆除方便出事时回溯默认只记异常流量排障时很容易少一段日志。set nat enable表示该策略下的流量在出接口做源地址转换适用于内网访问公网的场景。内网互访策略不要开 NAT否则源地址被转换后对端服务器看到的是一个你意想不到的内网地址排查时会被带偏很久。日志打开后在日志查询里能看到 policyid101、actionaccept、srcip、dstip 这些字段按 policyid 过滤就能确认流量走的是哪条策略。4. NAT 与路由的边界DNAT、源地址转换和策略路由容易踩的坑4.1 出口源 NAT 与端口映射是两件事别混在一张策略里FortiGate 上的 NAT 处理逻辑里内网访问外网用的是策略 NAT也就是在策略上打开 nat 开关外网访问内网用的是虚拟 IP也就是 DNAT。这两个功能经常被人混在一张策略里配置导致下面这类问题内网终端能正常上网但外网访问发布的服务时来回路径上被二次转换会话在中间某节点超时。我做方案时习惯把 NAT 职责拆成两层。第一层是出口源地址转换只放在访问 Internet 的那条策略上。第二层是端口映射只针对公网进来的流量单独建虚拟 IP再单独建一条入站策略。混在一个接口对里不是不行但多人维护时很容易互相覆盖。下面这张表是我常用的判断依据场景配置入口关键参数常见误区内网访问外网安全策略set nat enable内网互访也开了 NAT外网访问内网虚拟 IP 入站策略目标用 VIP 对象目标直接写内网真实 IP内网互访开 NAT 是我见过最多的问题之一。两个内网网段之间通讯源地址被 NAT 成出口接口地址后对端服务器看到的源 IP 全部相同审计和排查都变难。正确做法是内网互访策略只放行不启用 nat。4.2 发布内网 Web 服务一套 VIP 加策略的最小示例对外发布 HTTPS 服务我一般先建一个虚拟 IP把公网 IP 加端口映射到内网服务器。CLI 配置如下config firewall vip edit web-vip set type static-nat set extintf port1 set extip 203.0.113.10 set mappedip 10.1.1.10 set portforward enable set extport 443 set mappedport 443 next endextintf是公网所在的接口extip是公网 IPmappedip是内网服务器真实 IP。portforward enable表示启用端口映射extport和mappedport分别是公网端口和内网端口。这里的 extip 建议用独立公网 IP不要和出口接口主 IP 混用否则出方向 NAT 和入方向 DNAT 会撞出很多奇怪问题。然后建一条入站策略注意 dstaddr 要填 VIP 对象名config firewall policy edit 201 set name pub-to-web set srcintf port1 set dstintf port3 set srcaddr TRUSTED_MONITOR set dstaddr web-vip set action accept set schedule always set service HTTPS set logtraffic all next end这条策略我没有开 nat因为目标地址已经是 VIPFortiOS 会自动完成目的地址转换。srcaddr TRUSTED_MONITOR是重点永远不要把公网入站策略的源地址设成 all。哪怕运维图省事我也建议至少限定成公司出口 IP否则这台 Web 服务器等于裸奔在公网。配置完成后可以在 CLI 里用diagnose sniff packet any port 443 4抓几个包确认外网客户端握手包有没有到达外网接口。4.3 策略路由强制路径后回程会话为什么容易断策略路由是 FortiOS 里一个优先级很高的转发规则它不查路由表而是按“入口接口 源地址 目的地址”直接指定下一跳。在多链路场景下很实用比如让研发网段固定走 A 线路办公网段走 B 线路。但问题往往出在回程流量上。我处理过一个案例某分支两条互联网线路策略路由把内网访问某云平台的流量强制指向线路 B云平台服务器的回程却从线路 A 进FortiGate 的会话表里记录的是线路 B 的出口回程从另一个接口进来后状态匹配不上连接全部超时。这不是玄学是典型的非对称路由问题。配置策略路由时必须同时确认对端回程路径也能对称回来否则就要考虑在策略 NAT 上做特殊处理。查看路由和策略路由的常用命令如下get router info routing-table all get router info routing-table detail 0.0.0.0 show router policyget router info routing-table all看全局路由表确认目的地址是不是已经在路由表里。get router info routing-table detail 0.0.0.0专门看默认路由确认默认出口走向。show router policy列出当前策略路由规则排查时先看规则顺序再看每条规则的 input-device 和 gateway。策略路由规则也是自上而下匹配和防火墙策略一个逻辑所以顺序同样重要。5. 升级与 HA 的避坑记录主备双机也会翻车的现场5.1 HA 主备切换前先确认心跳口和接口监控清单FortiGate 的高可用最常见的是主备模式两台设备之间通过心跳口同步配置和会话状态。生产环境里我一般把两个专用口配成心跳不跑业务流量。hbdev后面的数字是心跳优先级优先级越高代表越优先成为主设备。一套最小 HA 配置如下config system ha set mode a-p set group-name FGT-SITE-A set hbdev port5 50 set session-pickup enable set monitor port1 port3 endmode a-p表示主备模式group-name是 HA 组名两台设备必须一致。hbdev port5 50指定心跳口为 port5优先级 50。session-pickup enable让主备切换时尽力保留已有会话对长连接业务很重要。monitor port1 port3指定业务口一旦这些接口链路断开设备会主动让出主角色触发切换。配置完成后的检查习惯更重要。我重启完 HA 组后一定会执行diagnose sys ha status看两台设备的角色确认。如果发现两台都显示自己是主设备说明心跳出了问题业务会来回抖动下面避坑记录里详细说。5.2 升级前先做兼容性评估与备份别把后悔药扔掉升级是 FortiOS 运维里风险最高的操作没有之一。我的原则是不跨大版本跨越升级先备份再评估最后动手。备份配置用下面这条命令把配置导出到 TFTP 服务器execute backup config tftp 10.0.0.2 fortigate-7-config.confTFTP 服务器最好放在运维网段不要放公网。备份文件保存后实际改配置前还要确认一下当前启动分区和下一次启动分区FortiOS 的固件升级本质是把新镜像写入临时分区升级失败时可以从旧分区启动这就是你的后悔药。升级路径上常见做法是从当前版本先升到中间大版本再继续往上升。比如从 6.4 直接跳到 7.4风险就比 6.4 到 7.2 再到 7.4 大很多。中间版本可以帮你把配置转换问题分成两步排查。还有一条血泪经验先在备用设备或虚拟机上跑一次升级流程确认配置转换没报错再动生产设备。特别是那些用了中文对象名、特殊字符名称的配置经常在转换时被过滤升级完才发现策略少了一截。5.3 避坑记录脑裂、升级丢配置、长连接会话中断避坑记录一HA 脑裂。现象两台设备在管理界面都显示为主设备内网设备到网关的流量在两个节点之间来回跳日志里反复出现 HA heartbeat timeout。原因我把心跳口接到了办公网那台交换机上而且没做 VLAN 隔离业务广播流量大心跳报文被间歇性拥塞两台设备互相以为对方挂了各自抢主角色。这就是典型的脑裂。解决把心跳口单独走一条物理链路或者划一个独立 VLAN 只跑心跳。同时缩短 heartbeat 间隔参数让两台设备更快感知对方状态。改完后我持续观察了两周主备角色再没来回翻转。避坑记录二跨版本升级后策略消失。现象从 6.4 升到 7.2 后原有端口映射策略还在但部分策略区块变成空策略列表里少了好几行界面没有任何报错。原因旧配置里有中文对象名和特殊字符升级时配置转换器把这类对象过滤掉了策略引用了空对象于是整条策略被丢弃。解决升级前把对象名全部改成 ASCII 命名重新检查所有策略对对象的引用。升级顺序改成先虚拟机验证再上备机最后切主。这个坑让我明白版本升级不只是下载固件配置兼容性评估才是核心活。避坑记录三升级重启后所有长连接断开。现象升级完成设备正常启动配置完好但业务系统、数据库连接和部分视频流服务全部超时重连短连接应用看起来正常。原因FortiGate 升级重启会清空会话表有状态防火墙一旦会话丢失TCP 连接就只能靠客户端主动重连。长连接应用没有重试机制自然全线超时。解决把升级窗口放在业务低峰提前通知业务侧重启应用连接。生产环境如果条件允许直接组成双机 HA升级前把主备切换一次让备机接管后再升级原主设备这样业务中断时间最短。6. 把日志字段和只读 API 用起来每周五下午十分钟巡检6.1 日志里先盯住四个字段别被动作刷屏带偏FortiOS 的日志字段很杂但排障时我通常只看四个字段logid定位日志类型policyid定位命中的策略编号action看最终是放行还是丢弃sessionid把同一条会话的所有日志串起来。看到 actiondeny 时别急着改策略先看 policyid 在哪条再查这条策略的 srcaddr 和 dstaddr 设计往往是对象范围没覆盖到。6.2 一个只读巡检脚本的完整写法和验证习惯巡检脚本我用得最多的是 REST API 加 cron。脚本只做三件事拉版本状态、拉 HA 状态、拉策略命中次数。下面是简化版接口路径以你当前版本 API 参考为准#!/bin/bash # 只读巡检每周执行一次 FGT_IP10.0.0.1 FGT_TOKEN填入只读 token curl -ks -H Authorization: Bearer ${FGT_TOKEN} \ https://${FGT_IP}/api/v2/monitor/system/status \ | python3 -m json.tool输出后我习惯直接对比上一周的版本号和 HA 角色如果发现主备角色变了而自己不知道说明这周发生过切换。每次升级或大变更后我会把策略列表导出一次保存成带日期的文件一旦业务异常就跑一遍 diff。这套习惯救过我多次把很多问题拦截在用户发现之前。我现在接手任何一台 FortiGate 之前会把四样东西打印出来当前版本、HA 状态、会话表规模、策略列表里按命中次数排序的前十条。这四样决定了我接下来半天会不会熬夜。希望这些踩坑记录能帮你少熬一次夜。本文还有配套的精品资源点击获取
