简介这份资源是山石网科HillstoneStoneOS 5.5R2 版本的官方用户手册全册面向网络安全运维人员、防火墙管理员以及正在备考相关认证的技术学习者用于系统掌握山石防火墙的配置与命令行操作。压缩包内仅含1个PDF文件体积约22.87MB属于典型的官方技术文档型资料适合作为日常查阅与系统学习的案头参考。手册内容覆盖CLI介绍、命令模式与提示符、执行模式、全局配置模式、子模块配置模式、命令模式切换、命令行错误信息提示、命令缩写形式、自动列出与补齐命令关键字等核心章节并配有手册约定与内容约定说明帮助读者准确理解WebUI界面元素与CLI语法的对应关系。目前已有2382人学习下载说明该手册在防火墙技术圈内具有较高的参考价值。读者可借助它快速熟悉StoneOS的命令体系与操作规范减少配置误操作提升设备管理与排障效率。1. 山石防火墙用户手册全册从 CLI 到 StoneOS 的实战拆解很多人拿到山石防火墙的第一反应是找一份「山石防火墙用户手册全册」翻了几百页 PDF 之后发现真正干活时用到的其实就那么几块StoneOS 的命令行体系、安全策略的匹配顺序、NAT 的转换逻辑、以及日志排查的入口。手册本身是权威参考但它不是操作指南——它告诉你「有什么」不告诉你「先做什么、后做什么、哪里会翻车」。这篇内容面向两类人一是刚接手山石设备、需要快速把策略跑通的网络运维二是已经在用 StoneOS但对手册里某些参数含义和 CLI 行为拿不准的老手。我会按「概念对齐 → 环境准备 → 策略配置 → 排错验证 → 进阶技巧」的路径把手册里散落的关键点串成一条能复现的操作线。不追求覆盖全册每一个角落而是把最常踩坑、最影响交付的部分讲透。2. StoneOS 命令行体系与手册查阅方法2.1 为什么 CLI 是绕不开的入口山石防火墙的 StoneOS 提供了 Web 界面WebUI和命令行CLI两套管理入口。WebUI 适合做策略的初次编排和可视化监控但一旦涉及批量配置、版本对比、脚本化巡检CLI 就是唯一选择。手册里关于 CLI 的章节通常放在「系统管理」或「命令行参考」部分但很多人翻手册时只看了 WebUI 的操作截图忽略了 CLI 的命令树结构。StoneOS 的 CLI 采用分层视图模式类似 Cisco IOS 但有自己的层级命名。登录后进入的是用户视图提示符通常是hostname执行enable后进入特权视图hostname#再通过configure进入配置视图hostname(config)#。这个层级逻辑和手册里「命令模式」章节的描述一致但手册不会告诉你在配置视图下不同模块如interface、policy、nat有各自的子视图退出时要用exit逐层回退而不是end一把跳回——end在部分 StoneOS 版本里会直接提交并退出到特权视图如果你只是想切出去看一眼状态这个操作会让你丢失未保存的上下文。常见做法是日常巡检用show类命令在特权视图完成配置变更才进configure。手册里show命令的索引很全但实际高频使用的就那么十几个后面我会列一个常用命令表。2.2 手册的三种查阅姿势「山石防火墙用户手册全册」通常以 PDF 或在线 HTML 形式提供结构上分为配置指南、命令参考、快速入门、版本说明几大块。直接从头读效率极低我一般按三种方式查阅第一种是「按功能模块定位」。比如要做 NAT先翻到「网络地址转换」章节看它支持的 NAT 类型源 NAT、目的 NAT、双向 NAT、NAT64 等再对照命令参考里的nat相关命令。手册的配置指南会给出 WebUI 的操作路径命令参考则给出 CLI 语法两者对照看才能把参数含义对齐。第二种是「按命令反查」。当你在 CLI 里敲了一个命令但不确定参数取值范围时用?补全然后拿命令关键字去手册的命令参考里搜。比如set policy后面能跟哪些匹配条件手册里会有完整的参数列表和默认值。第三种是「按版本差异查」。StoneOS 不同大版本之间命令语法和功能支持有差异。手册的版本说明章节会列出新增、废弃、变更的命令。如果你是从旧版本升级上来的这一步不能跳过否则会出现「手册里有的命令设备上敲不出来」的情况。提示手册的 PDF 版本建议用支持全文检索的阅读器打开按CtrlF搜命令关键字比翻目录快得多。在线 HTML 版本通常有搜索框但索引更新可能滞后于最新版本。2.3 常用 CLI 命令速查下面这张表是我在实际项目中反复用到的 StoneOS 命令按用途分类。手册里每个命令都有详细说明这里只列高频项和关键参数。用途命令示例关键说明查看接口状态show interface关注 up/down、IP、zone 绑定查看路由表show ip route确认默认路由和明细路由查看会话show session可加filter参数过滤源/目的 IP查看策略命中show policy id n显示匹配计数和字节数查看 NAT 转换show nat source确认转换规则和命中情况保存配置save config不保存则重启丢失查看日志show log可加module和level过滤这些命令在手册的命令参考章节都能找到完整语法但手册不会告诉你哪个命令在排错时最先用。我的习惯是先show interface确认链路再show ip route确认路径然后show session看会话是否建立最后show policy看策略是否命中。这个顺序能覆盖大部分「不通」的问题。3. 安全策略与 NAT 配置的落地步骤3.1 安全策略的匹配逻辑与 zone 概念山石防火墙的安全策略基于 zone安全域来定义流量的进出方向。每个接口必须绑定到一个 zone策略则定义「从哪个 zone 到哪个 zone、匹配什么源/目的/服务、执行什么动作」。手册里关于 zone 的章节会强调zone 是逻辑概念一个 zone 可以包含多个接口但一个接口只能属于一个 zone。策略匹配是从上到下逐条进行的一旦命中就执行动作permit/deny不再继续往下匹配。这意味着策略的顺序直接影响结果。手册里通常会在「策略配置」章节用一段话说明这个顺序但不会给出具体的排序建议。我的经验是把最精确的策略放在最上面宽泛的放下面。比如先放「特定源 IP 到特定目的 IP 的特定端口」再放「整个 zone 到 zone 的默认拒绝」。配置策略的 CLI 步骤大致如下# 进入配置视图 configure # 创建安全策略指定从 trust zone 到 untrust zone set policy from trust to untrust src 192.168.1.0/24 dst 10.0.0.0/8 service http permit # 查看刚创建的策略 show policy from trust to untrust # 保存配置 save config这段代码的逻辑是在configure视图下用set policy命令定义一条从 trust 到 untrust 的策略源地址是 192.168.1.0/24目的地址是 10.0.0.0/8服务是 http动作是 permit。show policy用来确认策略是否写入成功save config把当前配置持久化。参数说明from和to后面跟的是 zone 名称必须和接口绑定的 zone 一致src和dst支持单个 IP、网段、地址簿名称service可以是预定义服务如 http、https、ssh或自定义服务组。手册的命令参考里会列出所有预定义服务的名称但实际项目中我建议用自定义服务组因为预定义服务的端口范围有时和业务实际需求不一致。3.2 源 NAT 与目的 NAT 的配置差异NAT 是山石防火墙手册里篇幅较大的一个章节因为它涉及源 NATSNAT、目的 NATDNAT、双向 NAT、NAT 豁免等多种类型。实际项目中最常用的是源 NAT 和目的 NAT。源 NAT 用于内网访问外网时隐藏内网地址通常配置在出接口上。手册里会区分「基于策略的 NAT」和「基于接口的 NAT」前者更灵活后者更简单。我一般用基于策略的 NAT因为可以和策略绑定排查时更容易定位。# 创建源 NAT 规则将内网地址转换为出接口地址 set nat source rule 1 from trust to untrust src 192.168.1.0/24 translate-to interface # 查看 NAT 规则 show nat source rule 1这段代码创建了一条源 NAT 规则编号为 1方向是从 trust 到 untrust源地址 192.168.1.0/24 转换为出接口地址。translate-to interface表示使用出接口的 IP 作为转换后的地址这是最常见的「多对一」NAT 场景。目的 NAT 用于将外部访问映射到内部服务器配置时需要指定外部 IP、外部端口、内部 IP、内部端口。# 创建目的 NAT 规则将公网 IP 的 80 端口映射到内网服务器 set nat destination rule 1 from untrust to trust dst 203.0.113.10 port 80 translate-to 192.168.1.100 port 8080 # 查看目的 NAT 规则 show nat destination rule 1参数说明dst是外部访问的目标 IPport是外部端口translate-to后面的 IP 和端口是内部服务器的实际地址和端口。手册里会强调目的 NAT 规则必须配合安全策略使用策略里放行的应该是转换后的内部地址而不是外部地址。这一点新手很容易搞反导致「NAT 配了但策略没放行」的翻车现场。3.3 策略与 NAT 的联动验证配完策略和 NAT 之后验证是必须的。手册里关于验证的章节通常只讲「查看配置」但实际排错需要看会话和计数。# 查看会话过滤源 IP show session filter src 192.168.1.10 # 查看策略命中计数 show policy from trust to untrust # 查看 NAT 转换命中 show nat source rule 1这三条命令的组合逻辑是先确认会话是否建立show session再确认策略是否命中show policy最后确认 NAT 是否转换show nat。如果会话建立了但策略计数不增长说明流量没有匹配到预期策略可能是 zone 方向搞反了如果策略命中了但 NAT 计数不增长说明 NAT 规则的方向或匹配条件有问题。注意show session的输出里会显示会话的源/目的地址是转换前还是转换后的。如果看到的是转换后的地址说明 NAT 已经生效如果看到的是原始地址说明 NAT 没匹配上。这个细节手册里不会专门讲但排错时非常关键。4. 日志、调试与常见故障排查4.1 日志模块与级别设置山石防火墙的日志系统按模块划分常见模块包括policy、nat、interface、routing、system等。手册里关于日志的章节会列出所有模块和级别但实际排错时不需要全开否则日志量会淹没关键信息。# 设置日志级别为 debug模块为 policy set log module policy level debug # 查看实时日志 show log module policy # 恢复日志级别为 info set log module policy level info这段代码的逻辑是临时把 policy 模块的日志级别调到 debug观察策略匹配的详细过程排查完后恢复为 info。手册里会说明各级别的含义emerg、alert、crit、err、warning、notice、info、debug但不会告诉你debug 级别只在排错时开长期开启会影响设备性能。参数说明module后面跟模块名称level后面跟级别。不同 StoneOS 版本支持的模块名称可能略有差异以手册的命令参考为准。4.2 常见故障排查清单下面按「现象 → 原因 → 解决」列出 5 条我实际踩过的坑。现象一策略配了但流量不通会话表里没有记录。原因接口没有绑定 zone或者 zone 方向搞反了。策略是从 trust 到 untrust但流量实际是从 untrust 到 trust。 解决用show interface确认接口的 zone 绑定用show session看会话的 zone 方向。如果方向反了调整策略的 from/to 或者调整接口的 zone 绑定。现象二NAT 配了但内网访问外网还是显示内网 IP。原因NAT 规则的方向和策略方向不一致或者 NAT 规则的优先级低于其他规则。 解决用show nat source确认规则顺序用show session看会话的转换后地址。如果 NAT 规则编号靠后把它调到前面。现象三目的 NAT 映射后外部访问不通但内网直接访问服务器正常。原因安全策略里放行的是外部地址而不是转换后的内部地址。 解决检查策略的 dst 是否写成了内部服务器的 IP。目的 NAT 场景下策略匹配的是转换后的地址。现象四设备重启后配置丢失。原因配置修改后没有执行save config。 解决养成修改后立即保存的习惯。手册里会说明save config的作用但不会提醒你「不保存就丢」这个血泪教训。现象五日志里大量 deny 记录但不知道是哪条策略拒绝的。原因默认拒绝策略没有显式配置日志或者日志级别不够。 解决在默认拒绝策略上开启日志或者临时把 policy 模块日志级别调到 debug。手册里关于默认策略的章节会提到「建议配置显式拒绝并记录日志」但很多人会忽略。4.3 调试命令的安全使用边界StoneOS 提供了一些debug类命令可以抓包或跟踪特定流量。手册里会说明这些命令的用法但不会强调debug 命令在生产环境要慎用尤其是debug packet这类抓包命令在高流量场景下可能导致 CPU 飙升。我一般只在两种情况下用 debug一是问题可以复现且流量很小二是已经通过show命令缩小了范围需要用 debug 确认最后一个细节。用完立即关闭不长期开启。# 开启针对特定 IP 的调试 debug packet src 192.168.1.10 dst 10.0.0.1 # 关闭调试 no debug packet这段代码的逻辑是只抓源 192.168.1.10 到目的 10.0.0.1 的包避免全量抓包。no debug packet关闭调试。手册里会列出 debug 命令的参数但不会告诉你「抓完就关」这个习惯有多重要。5. 版本升级与配置迁移的实操技巧5.1 升级前的配置备份与兼容性检查StoneOS 版本升级是运维中的高风险操作。手册的版本说明章节会列出升级路径和兼容性矩阵但实际操作中我习惯在升级前做三件事第一完整备份当前配置。用save config保存后通过show config导出全文或者用 WebUI 的配置导出功能下载配置文件。手册里会说明配置文件的格式但不会提醒你不同版本的配置文件格式可能有差异直接导入新版本可能报错。第二检查当前配置里是否有新版本废弃的命令。手册的版本说明会列出废弃命令清单逐条对照当前配置提前修改。比如某些旧版本用set policy的某个参数新版本改成了另一个名称升级后配置会加载失败。第三确认升级路径。有些版本不能跨大版本直接升级需要中间版本过渡。手册里会有升级路径图按图走不要跳。5.2 配置迁移中的常见差异处理升级后配置迁移最常见的差异是接口名称和 zone 绑定的变化。比如旧版本接口叫ethernet1/1新版本可能叫ge1/1如果配置文件里写的是旧名称加载后会报错。处理方法是升级前用show interface记录当前接口名称和 zone 绑定升级后用同样的命令对比发现差异手动修正。手册里不会专门讲这个但这是升级后「配置加载失败」的主要原因之一。另一个差异是 NAT 规则的编号方式。部分版本升级后NAT 规则编号会重新排列导致策略引用的 NAT 规则 ID 对不上。处理方法是升级后逐条检查 NAT 规则和策略的引用关系必要时重新配置。# 升级后检查接口和 zone 绑定 show interface # 检查 NAT 规则 show nat source show nat destination # 检查策略引用 show policy这三条命令的组合逻辑是先确认接口层没问题再确认 NAT 层没问题最后确认策略层没问题。按这个顺序排查能快速定位升级后的配置差异。5.3 回滚方案的设计升级前必须准备回滚方案。山石防火墙通常支持双系统分区升级失败可以回滚到旧版本。手册里会说明双系统分区的切换方法但不会告诉你回滚后配置文件可能也需要回滚否则新版本的配置在旧版本上加载会报错。我的习惯是升级前把旧版本的配置文件和旧版本的系统镜像一起备份回滚时先切系统分区再导入旧配置文件。两步都完成才算真正回滚。提示双系统分区的切换命令通常在特权视图下执行具体命令以手册为准。切换后设备会重启重启期间业务中断所以升级窗口要选在业务低峰期。5.4 升级后的验证清单升级完成后不要只看设备起来了就完事。按下面的清单逐项验证验证项命令预期结果系统版本show version显示目标版本号接口状态show interface所有业务接口 up路由表show ip route路由条目完整策略命中show policy关键策略计数增长NAT 转换show nat sourceNAT 规则命中会话建立show session业务会话正常日志无异常show log无大量 err 级别日志这个清单覆盖了从系统层到业务层的验证按顺序走一遍基本能确认升级成功。手册里不会给这么具体的清单但这是实际项目中总结出来的。6. 用 CLI 脚本做批量巡检与配置对比6.1 为什么需要脚本化巡检单台设备的巡检用手敲命令没问题但如果有十几台山石防火墙逐台登录、逐条敲show命令效率低且容易漏。手册里不会讲脚本化巡检但这是实际运维中绕不开的需求。StoneOS 支持通过 SSH 执行 CLI 命令所以可以用 Python 的paramiko或netmiko库写脚本批量登录设备、执行巡检命令、收集输出。下面是一个最小可用的巡检脚本示例。import paramiko import time # 设备列表实际使用时从配置文件或数据库读取 devices [ {host: 192.168.1.1, user: admin, pass: password}, {host: 192.168.1.2, user: admin, pass: password}, ] # 巡检命令列表 commands [ show version, show interface, show ip route, show policy, show session, ] def inspect(device): client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(device[host], usernamedevice[user], passworddevice[pass], timeout10) shell client.invoke_shell() time.sleep(1) # 进入特权视图 shell.send(enable\n) time.sleep(1) output for cmd in commands: shell.send(cmd \n) time.sleep(2) output shell.recv(65535).decode(utf-8, errorsignore) client.close() return output for dev in devices: result inspect(dev) # 实际使用时写入文件或发送到日志平台 print(f {dev[host]} ) print(result[:500])这段代码的逻辑是用paramiko建立 SSH 连接进入 shell 后发送enable进入特权视图然后逐条发送巡检命令收集输出。time.sleep是为了等待命令执行完成实际使用时可以根据设备响应速度调整。参数说明devices列表里的 host、user、pass 需要替换为实际值commands列表按巡检需求增减timeout是 SSH 连接超时时间内网设备可以设短一些。手册里不会讲 Python 脚本但 StoneOS 的 CLI 兼容标准 SSH所以这套方法是通用的。6.2 配置对比的实用技巧配置对比是变更管理中的关键环节。升级前后、变更前后都需要对比配置差异。StoneOS 的配置文件是文本格式可以用diff命令直接对比。# 导出当前配置到文件 show config /tmp/config_before.txt # 变更操作后再次导出 show config /tmp/config_after.txt # 对比差异 diff /tmp/config_before.txt /tmp/config_after.txt这段代码的逻辑是用show config导出配置到文件变更后再导出一次用diff对比。手册里不会讲这个技巧但这是实际运维中确认「改了什么」的最快方法。参数说明show config的输出可能包含敏感信息如密码哈希导出文件要注意权限控制。diff命令的输出格式是「行号 变更内容」表示变更前表示变更后。6.3 巡检脚本的边界与注意事项脚本化巡检虽然方便但有几个边界要注意。第一不要用脚本做配置变更只做只读巡检。配置变更涉及上下文和顺序脚本很难处理异常情况。第二脚本里的密码不要硬编码用环境变量或密钥管理工具。第三巡检频率不要太高避免对设备造成不必要的负担。我一般把巡检脚本设为每天凌晨执行一次输出结果写入日志文件第二天上班时查看。发现异常再手动登录设备确认。这个习惯帮我提前发现过多次接口 down、路由丢失的问题比等到业务报障再处理主动得多。希望帮到你。本文还有配套的精品资源点击获取