洞察策略风险，用自然语言提问策略问题。 申请演示 →
Published:
如何跨多台防火墙追踪访问路径
by FireMon
当一条连接意外失败或意外成功时，首先要问的问题很简单：为什么？但在现代环境中，回答这个问题并不简单。两个系统之间的一条连接可能会穿越：
- 多台防火墙
- 不同的规则集与优先级
- 网络区域与路由路径
逐台设备逐一检查无法给出完整答案。本文说明如何跨多台防火墙追踪访问路径，以便您准确判定流量被放行或被阻断的原因。
核心问题：访问权限由整个环境共同决定
防火墙原生管理工具的作用范围通常仅限于单台设备。它们展示的是：
- 规则
- 日志
- 配置状态
它们无法展示流量在多个执行点上是如何被评估的。只有在路径上的每一个环节都被放行，连接才能成功建立。
什么是访问路径
访问路径是决定流量能否从源到达目的地的一系列评估过程。它包括：
- 源系统与目的系统
- 端口与协议
- 路由沿途的每一台防火墙、控制点和三层设备
- 在每一环节放行或拒绝流量的规则
追踪访问路径意味着识别上述各项要素及其相互作用方式。
输入与输出
输入
- 源系统
- 目的系统
- 端口与协议
- 整个环境中的防火墙配置
- 网络拓扑与路由路径
- 对象组与地址映射
输出
- 连接是被放行还是被阻断
- 所涉及的执行点顺序
- 放行或拒绝流量的规则
- 可能允许连通的备选路径
第 1 步：定义连接
从一个具体问题开始： App_Server 能否通过端口 1433 与 DB_Server 通信？如果没有明确定义的连接，追踪就会变得含糊不清。
第 2 步：确定预期路径
确定流量应如何在网络中流转。这包括：
- 源区域或源网络
- 中间网段
- 目的区域或目的网络
在许多环境中存在多条可能的路径。在评估规则之前，必须先了解拓扑结构。
第 3 步：评估每个执行点
在每一台防火墙或控制点上： 1. 识别相关规则 2. 评估规则顺序与优先级 3. 判定流量是被放行还是被拒绝
示例
防火墙 A： 放行 App → DB (1433) 防火墙 B： 拒绝 App → DB (1433) 该连接被阻断，因为所有执行点都必须放行该流量。
第 4 步：展开对象组
规则引用的往往是对象组，而非单个系统。这些组可能包含多个地址。
示例
放行 App → DB_Group (1433) DB_Group 可能解析为： DB_Server Backup_DB Reporting_DB 追踪时必须评估展开后的全部成员。
第 5 步：评估规则间的相互影响
规则并非彼此独立地生效。关键因素包括：
- 规则顺序
- 条件重叠
- 覆盖具体规则的宽泛规则
示例
规则 1：允许 App → Any（任意端口） 规则 2：拒绝 App → DB (1433) 该拒绝规则虽然存在，但永远不会被匹配到。
第 6 步：考虑备用路径
即使某一条路径阻断了流量，另一条路径仍可能放行。
示例
路径 1： 防火墙 A 拒绝 App → DB 路径 2： 防火墙 B 允许 App → DB 如果路由允许走路径 2，连接即可建立。路径追踪必须涵盖所有可能的路径。
第 7 步：确定最终结果
在评估以下内容之后：
- 所有执行点
- 规则间的相互作用
- 对象展开
- 可能的路径
您即可确定：
- 连接是被放行还是被阻断
- 是哪条规则起了作用
- 应在何处调整管控
示例：连接为何被放行
问题 App_Server 能否通过端口 1433 访问 DB_Server？ 配置检查结果 防火墙 A：允许 App → DB_Group (1433) 防火墙 B：无显式拒绝规则 规则顺序：宽泛的允许规则优先 实际结果 App → DB (1433) App → Backup_DB (1433) 由于对象组展开和规则优先级的作用，该连接被放行。
手动追踪为何难以为继
在以下情况下，手动追踪会变得困难：
- 涉及多台设备
- 规则集庞大且复杂
- 对象组展开规模显著
由此导致：
- 分析不完整
- 假设有误
- 排障缓慢
使用策略模型评估访问路径
策略模型提供了一种结构化的访问评估方式。 它整合了：
- 防火墙配置
- 网络拓扑
- 对象解析
- 规则评估逻辑
这使团队能够：
- 评估整个环境中的连通性
- 识别所有适用的规则
- 了解访问被放行或被阻断的原因
FireMon 的作用
FireMon 通过以下方式实现访问路径评估：
- 跨防火墙构建标准化的策略模型
- 纳入拓扑与路由信息
- 评估系统之间的连通性
- 识别控制访问的规则
这为回答以下问题提供了一致的方法：这条连接为何被放行或被阻断？
要点总结
- 访问由多个执行点共同决定
- 连接必须在每一个环节都被放行
- 规则顺序和对象展开会影响结果
- 备用路径可能带来意料之外的连通性
- 评估访问需要同时结合策略与拓扑
总结
在排查访问问题时，目标并不是找到某一条规则，而是同时利用控制点与网络拓扑，提供端到端的连接视图，从而清晰地解释流量为何被允许或被阻止。
[ FireMon ]
FireMon 的作用
FireMon 通过在各防火墙之间构建标准化的策略模型、纳入拓扑与路由信息、评估系统之间的连通性并识别控制访问的规则，实现访问路径评估。
常见问题
跨多台防火墙追踪网络流量，是指评估连接在源与目的之间的每一个执行点上如何被处理。它包括分析规则、路由路径和对象组，以确定流量在整个环境中最终是被允许还是被阻止。
追踪流量之所以困难，是因为每台防火墙都独立评估规则，而实际的连通性取决于所有执行点的共同作用。规则顺序、对象组展开以及多条路由路径，使得仅孤立地查看单台设备难以理解最终结果。
首先定义源、目的、端口和协议。然后确定预期的网络路径，评估每台防火墙上的规则，展开对象组，并考虑规则之间的相互作用以及备用路由。最终结果取决于所有执行点如何共同评估该连接。
流量的处理结果取决于规则顺序、允许与拒绝条件、对象组成员关系以及网络路由路径。连接必须在每一个执行点上都被允许，策略或拓扑中即便是微小的变化，也可能改变流量是被成功允许还是被阻止。
如果拒绝规则被优先级更高、范围更宽的允许规则覆盖，或因规则顺序而始终未被命中，该拒绝规则可能不会生效。在某些情况下，备用网络路径可能完全绕过该拒绝规则，从而导致流量出乎意料地被允许。
准确的分析需要在整个环境范围内评估流量，而不仅仅是单台设备。纳入防火墙规则、拓扑和对象解析的策略模型能够识别所有执行点及规则之间的相互作用，从而清晰地解释流量为何被允许或被阻止。