📚 课程目录第4章使用EOS内置工具进行配置审计

4. 使用EOS内置工具进行配置审计

在合规治理的日常工作中，最直接、最不依赖外部平台的审计手段，就是利用 EOS 自身提供的命令行工具对运行配置进行比对与回溯。EOS 内置的 show running-config、show diff、show rollback 三条命令，分别对应“当前状态是什么”“与基线差在哪里”“如何回到已知良好状态”三个核心问题。掌握它们，就能在不引入第三方系统的情况下完成一次可复现的配置审计。

一、审计的三个基本问题与命令分工

配置审计的本质是回答三个问题：设备现在长什么样、它和应该长的样子差多少、如果改错了怎么退回去。EOS 的命令设计恰好与这三个问题一一对应：

show running-config：输出当前生效的完整配置，是审计的“事实来源”。
show diff：将当前运行配置与指定的回滚点、启动配置或另一份配置进行差异比对，直接给出增删行。
show rollback：列出可用的回滚点及其时间戳、标签和触发原因，是变更追溯与恢复的入口。

这三条命令的组合使用，构成了 EOS 上最小可用的配置审计闭环。下面这张图展示了从“取当前配置”到“定位偏差”再到“决定是否回滚”的完整信号链，其中每个节点都对应真实命令与真实输出对象。

二、用 show running-config 建立审计基线

审计的第一步不是比对，而是先固定一个“应该长什么样”的参照。EOS 允许把当前运行配置导出为文本，也可以直接引用启动配置或某个回滚点作为基线。实际操作中，推荐在变更窗口之前先执行一次导出：

switch# show running-config > flash:baseline-20240601.cfg
switch# show running-config | section ntp
ntp server 10.10.10.1 prefer
ntp server 10.10.10.2
ntp source Management1

这里用 | section ntp 做局部过滤，是因为完整配置动辄数千行，直接肉眼比对效率极低。审计时通常按功能域分段检查：管理面（NTP、AAA、SNMP、日志）、控制面（路由协议、BFD、STP）、数据面（VLAN、ACL、QoS）。分段之后，每一段都可以单独与基线做 diff，偏差定位会快很多。

需要注意的是，show running-config 默认会隐藏部分默认值。如果基线中显式写了某条命令、而当前配置因为恢复默认值而不再显示，diff 会把它识别为“缺失”。因此审计前应确认双方是否使用了相同的 show running-config all 或 | no-more 等输出选项，避免把默认值差异误判为合规问题。

三、用 show diff 定位具体偏差

show diff 是审计中最核心的命令。它可以把当前运行配置与指定对象做逐行比对，输出中以 + 表示当前多出的行，以 - 表示当前缺少的行。常见用法有三种：

switch# show diff rollback-patch running-config flash:baseline-20240601.cfg
switch# show diff startup-config running-config
switch# show diff rollback-patch running-config rollback 3

第一种是与文件基线比对，适合定期审计；第二种是与启动配置比对，适合判断“运行配置是否已保存”；第三种是与某个回滚点比对，适合变更后快速确认改了什么。下面是一段示例输出，用于说明如何读 diff：

switch# show diff rollback-patch running-config flash:baseline-20240601.cfg
--- running-config
+++ flash:baseline-20240601.cfg
@@ -45,7 +45,7 @@
 interface Ethernet1
-   mtu 9000
+   mtu 1500
@@ -88,3 +88,6 @@
+ntp server 10.10.10.3
+logging host 10.20.30.40
+snmp-server community auditRO ro

这段输出里，mtu 9000 被改成 mtu 1500，属于“值不一致”类偏差；而 NTP、日志、SNMP 三行在基线中存在、当前缺失，属于“缺失类偏差”。审计人员要做的不是看到 diff 就回滚，而是先判断每一行偏差是否属于预期变更。例如 MTU 从 9000 降到 1500 可能是为了排查分片问题而临时调整，那就需要确认是否有对应的变更单；如果没有，就应视为违规偏差。

读 diff 的顺序建议：先看 - 行（当前缺少什么），再看 + 行（当前多出什么），最后看成对出现的值变化。缺失类偏差通常风险更高，因为它可能意味着安全策略、日志外送或时间同步被意外移除。

四、用 show rollback 做变更追溯与恢复

EOS 会在每次配置变更时自动生成回滚点，show rollback 列出这些点的编号、时间、标签和触发方式。审计时它有两个用途：一是确认“最近一次变更是什么时候、由谁触发”，二是当偏差被判定为必须纠正时，选择一个已知良好的回滚点执行恢复。

switch# show rollback
Rollback Point 1  2024-06-01 09:12:33  by user admin  (manual)
Rollback Point 2  2024-06-01 14:05:10  by user netops (manual)
Rollback Point 3  2024-06-02 08:30:44  by user admin  (manual)
switch# configure replace rollback 2

执行 configure replace rollback 2 之前，务必先用 show diff rollback-patch running-config rollback 2 预览将要发生的变化。回滚不是“撤销上一步”，而是“把配置整体替换为某个历史状态”，因此它可能同时撤销多个变更。如果回滚点 2 之后还有合规的变更，直接回滚会把它们一并抹掉。更稳妥的做法是：先用 diff 确认回滚范围，必要时只针对偏差行做手工修正，而不是整机回滚。

回滚前必须确认：回滚点是否包含当前必要的管理面配置（如管理接口地址、AAA、SSH）。如果回滚点早于某次管理面加固，回滚后可能直接失去远程登录能力，需要带外或 Console 恢复。

五、一次完整的手动审计示例

假设某台接入交换机在变更后需要做合规检查，基线为 flash:baseline-20240601.cfg。审计过程可以按以下顺序展开：

执行 show running-config > flash:current-20240603.cfg，固定当前状态。
执行 show diff rollback-patch running-config flash:baseline-20240601.cfg，得到偏差清单。
逐条判断偏差类型：缺失、多余、值不一致、顺序变化。
对每条偏差核对变更单，确认是否为预期变更。
对非预期偏差，执行 show rollback 找到变更前的回滚点，预览 diff 后决定是回滚还是手工修正。
修正完成后再次执行 diff，确认输出为空或仅剩已批准的预期变更。

这个流程不依赖任何外部平台，全部在设备本地完成，适合作为日常巡检或变更后验证的标准动作。它的局限也很明显：只能逐台执行，无法跨设备汇总，也无法自动判断“偏差是否合规”。因此它更适合作为合规治理的底层手段，与后续的自动化审计工具配合使用。

六、审计中容易踩的坑

第一，把 show diff 的输出直接当成“错误清单”。diff 只反映差异，不反映对错。一条 + 行可能是违规的临时命令，也可能是本次变更单里明确批准的配置。审计人员必须结合变更记录判断。

第二，忽略配置中的顺序敏感性。ACL、route-map、prefix-list 等对象的条目顺序会影响匹配结果。diff 有时会把顺序调整显示为大量增删行，看起来像大改，实际只是条目重排。遇到这种情况应单独查看相关段落，而不是只看 diff 统计。

第三，回滚点数量有限。EOS 默认保留的回滚点数量有限，长时间不清理会被新变更覆盖。如果审计周期较长，应定期把关键基线导出到 flash 或外部服务器，而不是依赖设备上的回滚点长期保存。

第四，忘记保存。运行配置与启动配置不一致时，设备重启会丢失未保存的变更。审计结束、确认配置合规后，应执行 copy running-config startup-config，并用 show diff startup-config running-config 确认两者一致。

把这三条命令用熟，配合分段过滤、变更单核对和回滚预览，就能在 EOS 本地完成一次结构清晰、可追溯、可复现的配置审计。它不追求自动化，但胜在直接、可靠，是每一位网络运维人员都应掌握的基本功。