文章总结： 该文档详细介绍了反测绘网关采用单臂透明代理部署方案的技术实现，核心要点包括：现有核心交换机保持默认网关职责，通过策略路由将指定流量牵引至反测绘网关进行协议识别、测绘工具检测和欺骗防御；网关异常时核心交换机自动撤销引流策略实现故障开放保障业务连续性。文档系统阐述了正常防护、故障切换、恢复回切、灰度引流等六大场景的流量路径与验收要点，特别强调了回程PBR配置对路径对称性的关键作用。 综合评分： 87 文章分类： 解决方案,安全建设,网络安全,应用安全,技术标准

---

反测绘网关单臂透明代理部署方案

百晓Phil 百晓Phil

百晓安全

2026年6月30日 16:12 北京

在小说阅读器读本章

去阅读

反测绘 #透明代理 #单臂部署 #PBR #FailOpen

适用读者

面向售前、售后和客户运维的反测绘网关单臂透明代理部署说明，覆盖正常防护、故障开放、恢复、灰度引流、维护绕行和排障场景

读完本文后，你可以了解：

1. 反测绘网关部署后是否会替换现有网关
2. 哪些流量会进入反测绘网关
3. 网关如何识别扫描、欺骗扫描器并放行正常业务
4. 网关故障时业务为什么还能继续访问
5. 实施和验收时应重点检查哪些路径

一句话结论

反测绘网关推荐采用单臂透明代理部署：现有核心交换机仍然是默认网关，核心交换机通过策略路由将指定流量牵引到反测绘网关，网关完成协议识别、测绘工具识别、欺骗防御和透明转发；当网关异常时，核心交换机自动撤销引流策略，让业务流量直接走原有默认路由，实现 Fail Open。

这个模式的价值在于：不改变现有网络拓扑，不修改服务器或终端默认网关，也不接管互联网出口，但可以按业务、网段、端口、VLAN 或安全域逐步引入防护能力。

部署模型

核心角色

| 角色 | 职责 | | — | — | | 核心交换机 / 三层网关 | 保持默认网关职责，配置 ACL、PBR、健康检测和 Track | | 反测绘网关 | 处理被引流的业务流量，完成识别、欺骗、阻断、蜜罐联动和透明转发 | | 出口路由器 / 防火墙 | 维持原有互联网出口和安全边界 | | 客户端 / 业务服务器 | 不需要修改默认网关和业务配置 |

典型拓扑

注意：这里的“单臂”不是指设备只能有一块网卡，而是指流量从同一侧网络进入和返回，不要求把网关串接到出口链路中。反测绘网关不是新的默认网关，也不是出口防火墙的替代品。

正常防护流量如何走

以客户端 192.168.10.100 访问互联网目标 1.1.1.1:443 为例：

1. 客户端仍按原有配置把流量发给默认网关，例如核心交换机 192.168.10.1。
2. 核心交换机根据 ACL 匹配流量，例如源网段 192.168.10.0/24、目标端口 80/443。
3. 命中 ACL 后，去程 PBR 将下一跳设置为反测绘网关业务地址，例如 192.168.10.200。
4. 反测绘网关接收流量，执行协议识别、TLS / HTTP 特征识别、测绘工具识别、欺骗策略匹配和透明代理转发。
5. 正常浏览器或业务客户端请求继续转发到真实目标；扫描器、测绘工具或异常探测按策略阻断、欺骗或牵引到蜜罐。
6. 响应流量必须按部署方式回到正确路径：若网关保留客户端源地址，应通过回程 PBR 重新牵引回反测绘网关；若网关对外建连时使用自身地址，响应会自然回到网关。

为了保证技术口径准确，实施时需要区分两种链路：

• 用户态透明代理链路：网关接管客户端侧连接，并代表客户端向真实目标或蜜罐目标建立上游连接。若上游连接使用网关自身出口地址，响应会自然回到网关，再由网关回写客户端。
• 透明保源链路：网关转发或建连时保留客户端源地址，真实目标的响应默认会回到核心交换机并指向客户端。此时必须配置回程 PBR，把响应方向重新牵引到反测绘网关，否则代理状态机会失效。
• 旁路检测 / 清洗链路：网关处理后把报文回注核心交换机，响应可能不再经过网关。这类链路更适合单向检测或清洗，不应当直接等同于完整透明代理。

项目落地时，如需要协议识别、HTTP / TLS 语义处理、欺骗响应和蜜罐牵引，建议按完整透明代理链路设计，并确认回程路径不会绕过网关状态机。

回程 PBR 与路径对称

单臂透明代理现场最容易遗漏的是：只配置客户端到目标方向的去程 PBR，却没有处理目标到客户端方向的回程流量。

是否需要回程 PBR，取决于网关对外建连方式：

| 上游建连 / 转发方式 | 是否必须配置回程 PBR | 原因 | | — | — | — | | 网关使用自身出口地址对真实目标建连 | 通常不需要 | 真实目标响应的目的地址是网关，响应天然回到网关 | | 网关保留客户端源地址透明转发 | 必须配置 | 真实目标响应的目的地址是客户端，默认会绕过网关 | | 要求响应方向也被检测、欺骗或审计 | 视建连方式而定 | 网关必须看到完整请求与响应；若网关使用自身地址建连，响应已天然回到网关，若保源则必须配置回程 PBR | | 仅做单向旁路检测或清洗 | 可不配置 | 但这不能宣称为完整用户态透明代理 |

需要双向牵引时，推荐把核心交换机上的策略拆成两组：

| 策略方向 | 匹配条件示例 | 下一跳 | 绑定状态 | | — | — | — | — | | 去程 PBR | 源地址为受保护客户端 / 服务器网段，目的端口为 80/443 或指定业务端口 | 反测绘网关业务地址 | 与网关健康检测 Track 绑定 | | 回程 PBR | 源地址为真实目标 / 互联网返回方向，目的地址为受保护客户端 / 服务器网段，协议和端口与去程会话反向匹配 | 反测绘网关业务地址 | 与同一 Track 或等价 Track 绑定 |

厂商中立的配置骨架可以理解为：

1. 定义去程 ACL
   match: 受保护源网段 -> 目标网段 / 互联网，业务目的端口 80/443/指定端口
   action: set next-hop 反测绘网关业务地址
   track: 网关健康检查 UP 时生效

2. 定义回程 ACL
   match: 目标网段 / 互联网 -> 受保护网段，响应方向流量
   action: set next-hop 反测绘网关业务地址
   track: 与去程 PBR 使用同一健康检查状态

3. 定义排除项
   exclude: 反测绘网关业务地址、管理地址、健康检测流量、网关回写客户端流量
   purpose: 防止网关自身流量被再次牵引形成环路

不同厂商对 ACL、route-map、traffic policy、NQA / IP SLA / Track 的命名不同，但逻辑必须一致：请求方向能在网关健康时进入反测绘网关；需要响应方向进入网关时，应通过回程 PBR 或天然回流实现；网关故障时，受影响的引流策略都恢复默认路由。

匹配条件需要按业务方向调整：

• 客户端访问互联网：去程通常匹配 客户端网段 -> 互联网目标，目的端口 80/443；回程通常匹配 互联网目标 -> 客户端网段，源端口 80/443 或厂商支持的会话 / ACL 等价条件。
• 外部访问受保护服务器：去程通常匹配 外部来源 -> 受保护服务器，目的端口 80/443；回程通常匹配 受保护服务器 -> 外部来源，源端口 80/443。
• 东西向业务：根据发起方和响应方所在 VLAN / 安全域，分别在两个方向的三层接口上配置 PBR。

配置回程 PBR 时要特别注意：

• 回程 PBR 应应用在响应流量进入核心交换机的方向，例如出口防火墙回核心方向、服务器区回核心方向或对应三层接口入方向。
• 回程 PBR 的匹配范围要精确，避免把全网返回流量都牵引到网关。
• 去程 PBR 与回程 PBR 应绑定同一健康检测结果；网关故障时两侧策略都应撤销，避免只撤去程、回程仍指向故障网关。
• 必须排除网关自身业务地址、管理地址、健康检测流量，以及网关回写客户端的流量，避免形成环路。
• 如果现场已经通过 SNAT / 源地址改写让响应天然返回网关，应在实施文档中明确“无需回程 PBR”的理由，避免售后误配。

健康检测与故障开放

单臂透明代理方案的高可用核心不在网关自己“宣布故障”，而在核心交换机主动检测网关状态。

推荐健康检测优先级：

1. HTTP / HTTPS 应用层检测，例如 GET /health
2. TCP 端口检测
3. BFD 或厂商等价快速检测
4. ICMP 探测

应用层健康检查比单纯 Ping 更可靠，因为它可以反映代理服务是否真正可用，而不只是主机是否还在线。

当健康检测失败时：

1. 核心交换机的 Track 状态变为 Down。
2. 与 Track 绑定的去程 PBR 以及已配置的回程 PBR 同时失效，或不再把网关作为下一跳。
3. 原本被引流的业务流量恢复默认路由，直接走核心交换机到出口。
4. 业务保持连通，实现 Fail Open。

Fail Open 保障的是业务可访问性，不保证已经建立的 TCP 长连接完全不中断。网关故障瞬间，已经进入代理链路的连接可能被重置；浏览器、客户端 SDK 或业务系统通常会重新建立新连接，新连接会根据当时的 Track 状态选择直连路径或代理路径。

场景一：正常防护场景

现场状态

• 核心交换机健康检测成功，Track 为 Up。
• PBR 策略已生效。
• 反测绘网关透明代理服务正常运行。
• DPI、协议识别、扫描器指纹、蜜罐联动策略已加载。

流量路径

请求：客户端 -> 核心交换机 -> 去程 PBR -> 反测绘网关 -> 核心交换机 / 上游网络 -> 真实目标
响应：真实目标 -> 核心交换机 -> 回程 PBR 或天然回流 -> 反测绘网关 -> 核心交换机 -> 客户端

具体路径会随 NAT、源地址保留、上游建连方式和现场路由设计变化，但验收目标不变：需要进入代理状态机的流量必须被网关看到完整请求和必要响应。若采用透明保源链路，应把回程 PBR 作为验收项，而不是只检查去程 PBR。

防护效果

| 流量类型 | 网关动作 | 客户体验 | | — | — | — | | 正常浏览器访问 | 透明放行或按业务策略转发 | 无感访问 | | Masscan / Zmap 类高速探测 | 识别并阻断或限速 | 探测失败或结果缺失 | | Nmap 指纹探测 | 伪装响应、延迟响应或诱导到蜜罐 | 扫描器获得误导性结果 | | 异常 HTTP 探测 | 按规则重写、欺骗、阻断或记录 | 攻击侧难以确认真实资产 | | 命中蜜罐策略 | 牵引到蜜罐并记录事件 | 攻击侧进入诱捕环境 |

验收要点

• 核心交换机 ACL 命中计数增加。
• 去程 PBR 下一跳为反测绘网关业务地址。
• 需要保源或双向检测时，回程 PBR 命中计数同步增加。
• 网关可看到请求日志、协议识别日志和处置日志。
• 网关抓包可看到同一会话的请求与响应两个方向。
• 正常业务访问无明显异常。
• 扫描器测试结果符合策略预期。

场景二：设备故障与 Fail Open 场景

现场状态

反测绘网关可能出现以下异常：

• 代理进程退出
• 透明监听异常
• CPU 挂死或系统负载过高
• 策略加载失败
• 网关业务口不可达

切换过程

健康检测失败
      |
      v
Track Down
      |
      v
PBR 自动失效或跳过网关下一跳
      |
      v
业务流量恢复默认路由
      |
      v
客户端继续访问业务

故障前路径

请求：客户端 -> 核心交换机 -> 去程 PBR -> 反测绘网关 -> 上游网络 -> 真实目标
响应：真实目标 -> 核心交换机 -> 回程 PBR 或天然回流 -> 反测绘网关 -> 核心交换机 -> 客户端

故障后路径

请求：客户端 -> 核心交换机 -> 上游网络 -> 真实目标
响应：真实目标 -> 核心交换机 -> 客户端

预期结果

• 新建连接不再经过反测绘网关。
• 去程 PBR 以及已配置的回程 PBR 均不再把流量指向故障网关。
• 业务访问保持连通。
• 反测绘识别、防护、欺骗和蜜罐牵引能力暂时失效。
• 已经经过网关的长连接可能断开并重连。

售后说明口径

Fail Open 是为了保障业务连续性。它的设计目标是“安全设备异常时不拖垮业务”，不是保证安全能力在故障期间继续生效。故障期间流量绕过网关，业务可用性优先于反测绘检测能力。

场景三：设备恢复与自动回切场景

现场状态

• 网关主机恢复。
• 透明代理服务重新启动。
• /health 或 TCP 健康检测重新成功。
• 核心交换机 Track 变为 Up。

恢复过程

网关恢复
   |
健康检测成功
   |
Track Up
   |
PBR 重新生效
   |
新建连接重新进入反测绘网关

预期结果

• 新建连接重新进入反测绘网关。
• 防护日志、协议识别日志恢复增长。
• 原本在故障期间直连的存量连接可能继续直连，直到连接结束或客户端重新建连。

运维注意事项

恢复后不建议只看主机 Ping 是否成功。应同时检查：

• 健康检测状态
• PBR 命中计数
• 网关透明代理服务状态
• 网关请求日志是否恢复
• 正常业务访问是否稳定
• 扫描器测试是否重新命中策略

场景四：灰度引流与分阶段上线场景

为什么需要灰度

存量网络中一次性把所有业务流量导入安全网关风险较高。单臂透明代理的优势是可以通过 ACL / PBR 精准选择流量，让上线过程从小范围开始。

推荐灰度顺序

1. 只引流测试网段或测试 VLAN。
2. 只引流单个业务系统的 80/443 流量。
3. 扩展到低风险业务网段。
4. 扩展到核心业务，但先观察只记录或低强度处置策略。
5. 根据误报、性能和客户反馈逐步开启阻断、欺骗和蜜罐牵引策略。

验收要点

• 每个阶段都有明确的 ACL 范围。
• 每次扩大范围前确认网关 CPU、内存、连接数和日志写入能力。
• 对核心业务先启用观察模式，再逐步开启主动处置。
• 出现异常时可以快速删除或禁用对应 ACL / PBR 条目，而不是回退全网配置。

场景五：计划内维护与临时绕行场景

适用情况

• 网关版本升级
• 策略大规模更新
• 硬件维护
• 网络割接
• 客户要求临时关闭安全检测

推荐做法

维护前由客户网络运维在核心交换机侧临时撤销或禁用 PBR，不建议只停止网关服务。

禁用去程 PBR 和已配置的回程 PBR -> 确认业务直连正常 -> 维护网关 -> 恢复健康检测 -> 启用去程 PBR 和已配置的回程 PBR -> 验证防护

为什么不建议直接关网关

直接关闭网关虽然也可能触发 Fail Open，但切换依赖健康检测超时，存在几秒到几十秒的等待窗口。计划内维护应主动撤销去程 PBR 和已配置的回程 PBR，切换到直连路径，避免业务方感知短暂抖动。

场景六：配置异常与排障场景

常见异常一：PBR 已配置但网关没有日志

可能原因：

• ACL 没有命中目标流量
• PBR 没有应用到正确的三层接口或 VLAN 接口
• Track 状态为 Down，PBR 被自动跳过
• 下一跳地址配置错误
• 回注或上游路径被路由策略绕开

排查顺序：

1. 查核心交换机 ACL 命中计数。
2. 查 PBR 是否绑定到正确接口。
3. 查 Track / 健康检测状态。
4. 查网关业务口抓包。
5. 查网关透明代理监听和策略加载状态。

常见异常二：业务访问变慢或连接异常

可能原因：

• 网关资源不足
• 上游建连源地址选择错误
• 回程路径不对称
• PBR 把网关自身流量再次牵引回网关，形成环路
• 阻断或欺骗策略误命中正常业务

排查顺序：

1. 查看网关 CPU、内存、连接数和队列。
2. 检查 PBR 是否排除了网关业务地址和网关自身上游连接。
3. 检查需要保源或双向检测的流量是否配置了回程 PBR。
4. 检查正常业务是否命中误报策略。
5. 检查回包是否经过预期路径。
6. 临时缩小 PBR 引流范围验证是否恢复。

常见异常三：只有请求日志，没有响应日志

可能原因：

• 只配置了去程 PBR，未配置回程 PBR。
• 回程 PBR 应用接口或方向错误。
• 回程 ACL 只匹配了请求方向端口，没有按响应方向调整源 / 目的条件。
• 上游 NAT 或防火墙策略改变了返回报文字段，导致回程 ACL 未命中。

排查顺序：

1. 在核心交换机查看回程 ACL / PBR 命中计数。
2. 在反测绘网关抓包，确认是否看到响应方向报文。
3. 在出口防火墙或上游三层设备查看返回报文源、目的和端口是否与 ACL 预期一致。
4. 临时缩小到单一客户端、单一目标、单一端口验证回程 PBR。
5. 若网关采用自身地址建连，确认响应是否已经天然回到网关，避免重复配置回程 PBR 造成环路。

常见异常四：健康检测正常但代理不可用

可能原因：

• 健康检测只做 ICMP，未检查代理进程
• /health 只返回主进程存活，未检查透明监听或策略加载
• 健康检查打到管理口，但业务引流口异常

建议：

• 生产环境优先使用应用层健康检查。
• 健康接口应覆盖代理主循环、透明监听、策略加载和关键依赖。
• 健康检测目标尽量贴近实际业务引流地址。

实施检查清单

网络侧

• 核心交换机支持 ACL、PBR、Track 或等价健康检测联动能力。
• PBR 应用于正确的三层接口、VLAN 接口或入方向。
• PBR 范围足够精确，避免一次性牵引全网未知流量。
• 需要保源时，已配置回程 PBR；需要双向检测或完整代理状态机时，已确认响应天然回流或已配置回程 PBR。
• 去程 PBR 与已配置的回程 PBR 绑定同一健康检测 Track，网关故障时能同时失效。
• 网关业务地址与核心交换机三层互通。
• 网关自身流量、回注流量和健康检测流量不会被重复 PBR。
• Track Down 时流量能恢复默认路由。

网关侧

• 透明代理模式已启用。
• 协议识别、扫描器识别、蜜罐联动和处置策略已加载。
• 健康检查接口可用，并能反映真实代理状态。
• 日志、事件和告警可被售后或客户运维查看。
• 资源容量满足灰度阶段的实际流量。

验收侧

• 正常业务访问通过。
• 去程 PBR 命中计数符合预期；已配置回程 PBR 时，回程命中计数也符合预期。
• 扫描器测试命中预期策略。
• 停止代理服务后，PBR 自动失效，业务仍可访问。
• 恢复代理服务后，新建连接重新进入网关。
• 长连接业务的重建行为符合客户预期。
• 维护绕行流程经过演练。

对外沟通常见问答

会不会改变客户现有网络拓扑？

不会。核心交换机仍是默认网关，出口路由器 / 防火墙仍保持原职责。反测绘网关只是被 PBR 引流的旁路处理节点。

需要改服务器或终端默认网关吗？

不需要。终端和服务器仍使用原默认网关。

网关故障会不会导致业务中断？

按推荐方案配置健康检测和 Track 后，网关故障会触发 Fail Open，核心交换机会停止把流量引到网关，新建业务连接恢复原路径。已有经过网关的长连接可能重建。

故障期间还有防护能力吗？

故障期间流量绕过网关，反测绘识别、欺骗和蜜罐牵引能力暂时不可用。该方案优先保障业务连续性。

可以只保护部分业务吗？

可以。PBR 可以按源地址、目的地址、端口、协议、VLAN 或安全域精准引流，适合灰度上线和分阶段扩容。

为什么推荐 HTTP 健康检查，而不是只 Ping？

Ping 只能说明主机 IP 可达，不能说明透明代理服务、策略加载和业务处理链路正常。应用层健康检查更接近真实防护能力。

总结

单臂透明代理部署让反测绘网关可以在不改变客户现有网络拓扑的前提下进入关键业务流量路径。它的关键不是把网关放到网络中就结束，而是把三件事设计清楚：

1. 由核心交换机通过 PBR 精准引流。
2. 根据建连方式确认响应是天然回到网关，还是需要回程 PBR 保持路径对称。
3. 由反测绘网关完成透明代理、防护识别和欺骗处置。
4. 由核心交换机通过健康检测和 Track 实现 Fail Open。

实施时，应重点验证“PBR 命中、回程路径、健康检测、故障开放”；运维接手时，应掌握“如何临时绕行、如何判断 Track 状态、如何确认流量是否进入网关”。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：百晓安全 百晓Phil 百晓Phil《反测绘网关单臂透明代理部署方案》