企业官网建设流程全解析

简介：Fortinet官方发布的FortiOS 7.0.0管理指南PDF，面向网络与安全运维人员，系统讲解防火墙操作系统的日常管理、配置与监控方法。资源为单文件PDF，共1个文件，包体大小约29.34MB，目录结构完整，支持按需查阅或通读学习。内容从入门概念与机型差异讲起，深入覆盖GUI图形界面与菜单表格操作、CLI命令行语法及子命令权限、FortiExplorer初始化、基本管理（注册、FortiCare登录、配置备份、故障排除）、仪表盘与小工具定制，以及FortiView监控、静态与动态路由监控、DHCP/IPsec/SSL-VPN监控、设备清单、FortiView会话分析等核心模块；同时涉及Security Fabric安全架构、自动化缝合、多VDOM模式、SAML SSO与安全评级等进阶主题。指南既适合入门读者快速建立管理框架，也能帮助中高级管理员在实战中对照排查。目前已有224人学习浏览，是研究FortiOS 7.0.0配置与安全管理的权威参考。

1. 这版管理指南不是让你通读的：一张配置地图与三个使用场景

新接手一台 FortiGate 时，多数人的第一反应是打开 FortiOS-7-Administration_Guide.pdf，从第一章开始通读。我劝你别这么干——这份管理指南真正的价值不在「读」，而在「查」。它完整定义了 FortiOS 7 的配置模型：接口怎么挂到 zone、地址对象怎么被策略引用、NAT 在哪一层生效、日志在哪个环节被记录。把这些主线捋顺后，你面对的不是一本 PDF，而是一张配置地图。这篇笔记就按这个思路，把 FortiOS 7 的日常管理拆成能照做的步骤和参数。适合刚接手设备、想让策略一次配通的运维工程师，也适合准备写自动化脚本、需要搞懂 CLI 层级的人。

2. FortiOS 7 的配置模型：对象、策略、数据三层怎么串成一条线

2.1 为什么说 FortiOS 7 的配置是「对象-策略-数据」三层结构

FortiOS 7 的配置体系可以拆成三层。最底下一层是对象层：接口、地址、服务、时间表、虚拟 IP，这些都是独立存在的实体；中间是逻辑层：防火墙策略、NAT 规则、路由，它们本身不存数据，只是引用对象；最上面是数据层：会话表、日志、计数器，是流量的实时体现。

理解这个分层，排障思路会完全不一样。举个例子：你改了一个接口的 IP，引用这个接口的防火墙策略不会消失，策略仍然存在，只是数据面暂时不可用。这个「对象与策略解耦」的设计，是 FortiOS 7 跟很多传统防火墙最大的区别——传统防火墙的策略里直接写 IP，改地址就得改策略；FortiOS 7 里你只需要改地址对象，所有引用它的策略自动生效。

管理指南里反复强调「先建对象、再写策略」，原因就在这里。新手常见的误区是把策略里写的srcaddr当成一段临时文字，实际上它是一个指向地址对象的引用。你在 GUI 界面看到的安全策略列表，本质上是对象的聚合视图。这个视角一旦建立，后面所有操作都会顺畅很多。

另外要提一下 vdom（虚拟域）。FortiOS 7 默认工作在 root vdom 下，多数场景不需要动它。只有在多租户或网络隔离需求下，才需要拆 vdom。每个 vdom 有独立的对象表和策略表，互相不可见。管理指南把它放在靠前的章节，但实际运维中，90% 的设备用 root vdom 就够了。这一块不用深挖，知道边界在哪就行。

2.2 从管理指南提炼拓扑：接口、地址对象、策略、NAT 的绑定关系

我把 FortiOS 7 最核心的配置链路用一段 CLI 配置展示出来。这段配置的价值在于：它把接口、zone、地址对象、策略、NAT 的引用关系全部串在了一条线上，是管理指南里分散在不同章节的知识点的收敛。

# 接口层：把 port2 划入内网 zone（注意 zone 先建好，再把接口加入 member） config system zone edit "LAN-Zone" set member "port2" next end # 接口层：给 port2 配置内网地址与管理访问协议 config system interface edit "port2" set vdom "root" set ip 192.168.10.1 255.255.255.0 set allowaccess ping https ssh next end # 对象层：定义内网网段地址对象 config firewall address edit "LAN-Subnet" set subnet 192.168.10.0 255.255.255.0 next end # 策略层：引用 zone 与地址对象，并开启 NAT config firewall policy edit 1 set name "LAN-to-WAN" set srcintf "LAN-Zone" set dstintf "WAN-Zone" set srcaddr "LAN-Subnet" set dstaddr "all" set action accept set schedule "always" set service "ALL" set nat enable next end

这段配置里，zone 的用法是关键。FortiOS 7 的策略源接口和目的接口既可以写单个物理接口，也可以写 zone。两者的区别是：如果只写单个接口，以后在 zone 里新增接口时，策略不会自动覆盖新接口；如果写 zone，所有属于该 zone 的接口都会匹配这条策略。很多排障案例的根因就在这里——策略配置看起来没问题，但流量就是不通，一查才发现接口没划进 zone，或者策略里写的是物理接口而不是 zone。

set nat enable是策略内 NAT，也就是源地址转换。FortiOS 7 还有一种全局 NAT 模式（central NAT），启用后策略里的 nat 参数会失效，所有 NAT 规则集中到一张表里管理。两种模式不能混用，这是配置前必须先确认的选型点。

2.3 管理指南的章节地图：一张表对应你的日常任务

管理指南很厚，但日常运维真正高频用到的模块是有限的。我整理了一张映射表，把常见任务对应到指南的功能模块和核心命令，照着这个表去翻指南，效率比从头读高得多。

这张表的关键价值是帮你建立「任务到配置位置」的映射。比如你接到一个需求「把内网某台服务器的 8080 端口映射到公网」，你的第一步不是去翻策略，而是去config firewall vip建一个虚拟 IP——因为 FortiOS 7 的 DNAT 是先在对象层定义映射关系，再在策略里引用。这个顺序如果搞反了，你会在策略配置界面里找不到任何可以填公网 IP 的地方。

3. 照着指南配一台出口防火墙：从接口到策略生效的完整路径

3.1 开局三步：接口地址、默认路由与管理白名单

拿到一台全新的 FortiGate，配置顺序建议固定为：接口地址、默认路由、管理白名单。不要先急着建策略，先把设备自身的连通性搞定，后面所有验证才有基础。

# 第一步：配置 WAN 口地址，运营商给的固定 IP config system interface edit "port1" set mode static set ip 203.0.113.2 255.255.255.252 set allowaccess ping https ssh next end # 第二步：配置默认路由指向运营商网关 config router static edit 1 set device "port1" set gateway 203.0.113.1 set dst 0.0.0.0 0.0.0.0 next end # 第三步：限制管理入口，避免设备裸奔在公网 config system admin edit "admin" set trusthost1 192.168.10.0 255.255.255.0 set trusthost6 ::/0 next end

这里有两个细节值得注意。第一，allowaccess里如果没有加ping，你自己排障时想从管理机 ping 设备会不通，容易误判成网络故障。第二，trusthost是管理白名单，只允许指定网段访问管理端口。生产环境里见过太多设备因为没设 trusthost，管理界面暴露在公网上被扫描爆破的情况。FortiOS 的 admin 账号默认支持 trusthost 限制，开局就配上是最低成本的防护。

默认路由配完，可以用execute ping 8.8.8.8验证外网连通性——注意 FortiOS 的命令是execute ping，不是直接ping。如果这一步不通，后面配什么策略都没意义，先回头查接口状态和路由表（get router info routing-table all）。

3.2 地址对象与服务对象：把策略写成可读的规则

FortiOS 7 里策略的可读性，完全取决于你有没有先建对象。比如「内网网段放行到公网 Web 服务器的 443 端口」这条需求，如果直接在策略里写 IP 和端口，策略列表会变成一串数字天书；如果先建对象，策略读起来就是自然语言。

# 建服务对象：定义 Web 服务端口组 config firewall service custom edit "TCP-443" set protocol TCP set tcp-portrange 443 next end # 策略里引用对象，可读性大幅提升 config firewall policy edit 10 set name "LAN-to-WebServer" set srcintf "LAN-Zone" set dstintf "server-Zone" set srcaddr "LAN-Subnet" set dstaddr "WEB-Server-IP" set service "TCP-443" set action accept next end

服务对象的本质是协议与端口组的封装。FortiOS 7 内置了大量预定义服务（HTTP、HTTPS、DNS 等），自定义场景才需要走config firewall service custom。建服务对象的另一个好处是批量管理：如果某天安全策略要求所有走 443 的流量都要过内容检测，你只需要把这个服务对象替换成带检测的策略组，而不用逐条改策略。

这个「先对象、后策略」的习惯，在策略数量多的时候体现出的优势最明显。我有一次在一台设备上维护 300 多条策略，全靠对象命名规范——地址对象用「用途-网段」命名（比如 LAN-Subnet）、服务对象用「协议-端口」命名（比如 TCP-443）。如果没有这套规范，策略审计时根本没法看，更别说批量变更。

3.3 SNAT 与 DNAT 在策略里的配置方式

FortiOS 7 的 NAT 分两个方向：源地址转换（SNAT）和目的地址转换（DNAT）。两者的配置位置完全不同，这是新手最容易混淆的地方。

SNAT 有两种实现方式。最常用的是策略内 NAT：策略里set nat enable，设备会自动把内网源地址转换成出口接口的地址。这种方式的好处是规则跟着策略走，直观好维护。另一种是 central NAT，需要在系统设置里开启全局 NAT 模式，然后单独维护一张 NAT 规则表。central NAT 适合策略和 NAT 职责分离的场景，但开启后策略里的 nat 参数会失效，如果你不确定自己需要它，用默认的策略内 NAT 就够了。

DNAT 的配置链路完全不同。它需要先建虚拟 IP 对象，再在策略里引用。

# DNAT：把公网 IP 的 8080 端口映射到内网服务器 config firewall vip edit "web-server-vip" set extip 203.0.113.10 set extintf "port1" set mappedip "192.168.10.5" set extport 8080 set mappedport 8080 next end # 策略里引用虚拟 IP 作为目的地址 config firewall policy edit 20 set name "WAN-to-WebServer" set srcintf "port1" set dstintf "server-Zone" set srcaddr "all" set dstaddr "web-server-vip" set action accept next end

这段配置里有几个参数需要理解到位。extip是公网侧地址，必须是设备某个接口上真实存在的 IP，或者运营商分配的可用地址；mappedip是内网服务器的真实地址；extport和mappedport分别是公网端口和内网端口，如果映射前后端口一致，只写一个extport也行。策略里的dstaddr指向的是虚拟 IP 对象，不是服务器真实地址——这是 DNAT 配置里最常见的认知偏差，很多人在这里把映射写成了服务器内网 IP，导致整体不可达。

3.4 配置变更的提交、备份与回滚

FortiOS 7 的配置变更默认是即时生效的——你敲完end，变更就已经在数据面生效了。这一点跟某些需要显式提交的网络设备不同，好处是快，坏处是手滑敲错一条命令，可能当场断网。所以养成良好的变更习惯尤其重要。

我一般会在每次变更前先做一次配置备份。FortiOS 7 最可靠的备份方式不是用 TFTP，而是直接拉取配置文件到本地：

# 通过 SSH 拉取完整配置到本地文件 ssh admin@192.0.2.1 "show full-configuration" > fw-backup-$(date +%Y%m%d).conf # 变更后对比确认差异 diff fw-backup-$(date +%Y%m%d).conf fw-current.conf

show full-configuration会输出完整的配置内容，包括所有对象、策略、系统参数。注意输出的顺序和 GUI 里的组织方式不完全一致，但内容是全的。变更后 diff 一下，能确认本次改动只涉及预期范围内的配置，没有意外变更。

回滚的姿势也要提前想好。如果变更后发现问题，最稳妥的方式是恢复备份配置——在 CLI 里执行execute restore config并指定备份文件来源，设备会重新加载配置。但这里有个坑：恢复配置会让设备上的增量变更丢失，所以恢复前一定要确认备份文件是最近的、且包含了恢复点之前的所有必要配置。

4. CLI 比 GUI 快在哪：把 FortiOS 7 日常管理脚本化

4.1 FortiOS 7 的 CLI 层级、补全与批量编辑

FortiOS 7 的 CLI 是典型的树形结构：config进入配置模式，edit选中具体对象，set设置参数，next跳到下一个对象，end退出。这套层级一旦熟悉，操作速度远超 GUI——尤其是批量操作时，GUI 点 50 次鼠标的时间，CLI 一条循环就完成了。

CLI 有几个救命习惯。第一是?键：在任意位置敲?，设备会列出当前位置可用的全部命令或参数，不用背文档。第二是 Tab 补全：输入命令前缀再按 Tab，会自动补全剩余部分，减少拼写错误。第三是show命令：在配置模式下输入show，会列出当前层级下的完整配置，这是查看现状最快的方式。

批量编辑是 CLI 的核心优势。比如你要给 20 个接口批量加管理访问白名单，GUI 里得一个个点进去改，CLI 里一段脚本遍历即可。但要注意 FortiOS 的 CLI 脚本没有循环语法，批量操作要靠外部脚本配合设备命令逐条执行——这也是为什么实际落地时，把 CLI 操作包在外部脚本里是常态。

4.2 写一个巡检脚本：get、diagnose 两条命令线的组合

日常巡检不需要登录 GUI 一台台看，一条 SSH 命令拉一组状态输出就够了。这是我常用的巡检脚本骨架：

#!/usr/bin/env bash # 巡检脚本，从管理机批量拉取 FortiOS 7 设备状态 GATEWAY="admin@192.0.2.1" # 设备管理地址 ssh "$GATEWAY" " get system performance status # 查看 CPU / 内存使用率 get system session status # 查看会话总量与峰值 get system interface physical # 查看物理接口链路状态 diagnose sys session summary # 查看会话协议分布 get system ha status # 查看高可用状态（若配置了 HA） "

这五条命令覆盖了设备健康度、会话容量、链路状态、流量特征四个维度。get system performance status里如果 CPU 长期超过 80%，需要关注是否有异常流量或策略日志开得太多；diagnose sys session summary则能快速看出是 SYN 洪水还是正常连接。FortiOS 的诊断命令体系（diagnose 开头）功能很强，但生产环境慎用，某些 diagnose 命令会临时占用较高系统资源，建议避开业务高峰执行。

脚本化巡检的额外收益是留痕。每次巡检输出都保存下来，时间一长就有了设备的性能基线——下次看到 CPU 从 20% 涨到 60%，你就有历史数据可以参考，而不是凭感觉判断异常。

4.3 什么时候别用 GUI：批量、重复、需要审计的操作

GUI 适合探索性操作——你不确定某个功能在哪，点开界面找一找，比敲命令直观。但有三类操作我建议一律走 CLI。

第一类是批量操作。几十条策略同时加地址对象引用，GUI 逐个编辑容易漏，CLI 脚本可以保证一致性。第二类是重复性操作。比如每周导出一次配置、每天拉一次会话统计，写进脚本交给定时任务，不需要人肉登录。第三类是审计敏感操作。CLI 操作可以通过 SSH 会话日志回溯，而 GUI 操作如果不开启审计日志，事后很难说清楚是谁在什么时间点了什么按钮。

另外，如果设备管理面有集中化管理平台（如 FortiManager），那 GUI 和 CLI 的取舍逻辑又不一样——平台统一管理时，尽量限制管理员直接登录设备，所有变更走平台下发，保证配置基线统一。这个属于管理规范层面的问题，但值得在团队协作时提前定好规矩。

5. 避坑清单：FortiOS 7 日常管理的 5 个踩坑点与排查手法

5.1 策略明明配了对，流量就是不匹配——先查 zone 归属

现象：策略里源接口写的LAN-Zone，目的接口写的WAN-Zone，策略顺序正确、动作是放行，但内网访问外网就是不通。

原因：接口没有加入对应的 zone。FortiOS 7 的策略如果引用了 zone，那么只有属于该 zone 的接口才能匹配这条策略。如果port2没有加入LAN-Zone，即使它的 IP 在预期网段内，流量也不会命中策略。

解决：用get system zone查看 zone 成员，再确认接口归属。或者把策略的源接口直接写成物理接口port2，绕开 zone 的判断。但更推荐维护好 zone——统一在 zone 层面管理接口，后续扩容时策略不用动。

5.2 日志里看到的源地址全是转换后的地址——NAT 顺序导致的误解

现象：开启 NAT 后，流量日志里记录的源地址是公网出口地址，查不到内网真实来源。

原因：这是一层容易误判的地方。策略内 NAT 会在流量匹配策略后、记录日志前完成地址转换，所以日志默认记录的是转换后的地址。很多人在排障时看到日志里全是出口公网 IP，就以为设备丢掉了源地址信息——实际上源地址信息在会话表里一直存在。

解决：用diagnose sys session filter配合diagnose sys session list查会话详情，里面同时有转换前后的地址和端口。另外可以在策略里启用日志记录原始源地址的选项（set logtraffic enable配合日志配置），但要注意这会增加日志量。

5.3 改完策略，在线用户的连接瞬间断掉——会话清理机制

现象：修改某条策略后，正在通过该策略转发的大流量连接立刻中断，应用报错，需要用户重新发起连接。

原因：FortiOS 7 在策略变更时会清理受影响的会话表项。这是个安全设计——防止旧策略下的会话绕过新策略继续转发。但对长连接业务（比如数据库连接、视频流）来说，这种清理意味着瞬间断流。

解决：把策略变更安排在业务低峰期，变更后立即用get system session status观察会话重建情况。对于无法接受断流的核心业务，评估是否需要把相关流量拆分到独立策略，控制在变更影响面。

5.4 GUI 里改的配置被 CLI 覆盖——并发管理会话的冲突

现象：管理员 A 在 GUI 里改了几条配置还没保存，管理员 B 同时用 CLI 执行了批量配置，CLI 的变更生效后，A 在 GUI 里的改动消失或部分失效。

原因：这是并发管理会话冲突。FortiOS 7 的管理会话之间没有乐观锁机制，后来提交的变更可能覆盖先前的未提交修改。GUI 的配置往往在点击「保存」时才真正生效，这中间的时间窗口就是冲突高发期。

解决：团队协作时约定「同一时间只能有一个管理员操作设备」，变更前先在群里通告。更进一步，可以启用设备的配置版本管理，变更前自动记录版本，冲突后可以对比差异再决定保留哪一份。对核心设备，建议接集中管理平台，把多人并发操作变成平台统一编排。

5.5 日志时间与内网 NTP 差几分钟——审计追溯时对不上号

现象：安全事件溯源时，防火墙日志时间和应用服务器日志时间对不上，差了 3 到 5 分钟，无法精确还原攻击时间线。

原因：FortiOS 7 默认使用公网 NTP 服务器同步时间，但如果设备部署在纯内网或公网访问受限的机房，时间同步会失败或漂移。加上时区设置如果不统一，日志时间戳就会出现系统性偏差。

解决：在config system ntp里配置内网 NTP 服务器，并确认时区设置（config system global下的set timezone）跟业务系统一致。配置完后用diagnose sys ntp status确认同步状态。时间同步这件事，看似小，真到溯源审计时就是大问题——日志时间对不上，所有分析都得重新来。

6. 版本化配置备份：把 FortiOS 7 管理从手工作坊拉到可审计

前面讲的都是单次操作和排障，最后分享一个我会向每个刚接触 FortiOS 7 的同行推荐的管理习惯：给设备配置做版本化备份。这个习惯源自一次真金白银的教训——有一台承载核心业务的设备，我没备份就改了一组 NAT 规则，改完业务全断，现场手忙脚乱找原来的配置，全靠记忆往回改，最后花了两个多小时才恢复。从那以后，所有 FortiOS 设备的变更都强制先备份。

具体做法分三步。第一步，把备份脚本化，定时拉取配置：

#!/usr/bin/env bash # 每周日凌晨备份所有 FortiOS 设备配置到本地目录 BACKUP_DIR="/var/forti-backup/$(date +%Y%m%d)" mkdir -p "$BACKUP_DIR" for device in fw-prod-01 fw-prod-02 fw-dr-01; do ssh admin@"$device" "show full-configuration" > "$BACKUP_DIR/$device.conf" done

第二步，用 Git 管理备份目录，每次备份后提交一次：

cd /var/forti-backup git add . git commit -m "config backup $(date +%Y%m%d)"

第三步，变更前手动再拉一次即时备份，变更后对比差异。这一步的关键是用 diff 验证「本次改动只动了该动的」。有一次我就是靠这个对比发现了一条意外被删的静态路由——当时只打算改策略，结果某次操作连带影响了路由配置，如果没有 diff，这个问题要等到业务异常才会暴露。

这套流程的成本极低——一个脚本加一个 Git 仓库。收益是设备配置有了完整历史，任何时间点都能回滚，任何变更都有据可查。配合前面讲的 zone 维护习惯和 CLI 巡检脚本，一套基础可靠的 FortiOS 7 运维体系就搭起来了。这些习惯和踩坑记录，都是从线上设备里一点点磨出来的，希望帮到你。

本文还有配套的精品资源，点击获取