防火墙 ha 会话

理解您对 RBM（远端备份管理）会话切换细节的关注。您提到的两种场景，其核心区别在于故障切换后，防火墙 B 如何“接手”并处理流量。下面我将为你详细剖析。

 RBM 的核心：会话热备

首先需要明确，无论是 VRRP 还是路由模式，关键在于 RBM 的会话热备功能。这意味着：

• 主设备 A 在处理业务时会实时创建会话表项（Session Entry）。

• RBM 会立即将这些会话信息通过心跳线同步到备设备 B 的热备表中。

• 因此，当 A 发生故障时，B 的内存中已经拥有了一份所有正在进行的会话副本。

 场景一：VRRP 模式下的会话处理

在 VRRP 模式下，您对外的接口 IP 是虚拟的，由 A 和 B 共享。

疑问1：A 故障后，内网访问百度的流量上到 B，会话是新建还是匹配？
答案是：直接匹配备设备中的热备会话，无需新建。

• 原理：由于您内网的访问流量（如 192.168.1.100→百度 IP）的源目 IP 和端口等信息，已被 RBM 实时从 A 同步到 B。

• 过程：当流量被 VRRP 自动导向 B 后，B 收到报文，首先会搜索自己的会话表。它会发现此报文与之前 A 同步过来的会话完全匹配，于是直接按该会话记录进行转发，连接不会中断。整个过程对用户来说是无感知的。

疑问2：此时百度的回包回到 B，会话匹配和转发流程是怎样的？
同样是直接匹配热备会话进行转发。

• 百度服务器的回包（源 IP 百度，目的 IP A的NAT地址）到达 B 后，B 会匹配之前同步过来的会话表。

• 匹配成功后，B 会根据该会话记录中的内网源 IP 192.168.1.100 进行目的地址转换（DNAT），并将报文正确送达给您的内网用户。

 场景二：路由模式下的会话处理

在路由模式下，两台防火墙使用各自不同的物理 IP 对接上下行网络。其切换依赖于动态路由协议（如 OSPF）的收敛。

疑问1：内网访问百度的流量上到 B，会话是新建还是匹配？
答案是：匹配热备会话，但前提是业务切换已完成。

• RBM 结合路由模式，是通过在 A 故障时，由 RBM 通告路由协议调高 A 的路由开销值（Cost） 或撤销路由，使流量收敛至 B。

• 一旦切换完成（依赖路由收敛速度），流量到达 B 后，B 同样会发现报文信息与自己热备表中的会话相匹配，从而直接转发，无需重建连接。

疑问2：百度的回包回到 B，会话匹配和转发流程是怎样的？
流程与 VRRP 模式类似，但有一个关键的 NAT 地址适配问题。

这里需要特别注意：如果两台防火墙使用接口地址池（即 Easy IP 方式）做源 NAT，那么从 A 发出的报文使用的是 A 的接口 IP IP_A。当 B 收到百度的回包时，其目的 IP 是 IP_A。由于 IP_A 不在 B 的接口上，会导致回包被丢弃，业务中断。

 路由模式的最佳实践

为确保路由模式下主备切换的完美，必须使用以下地址规划：

因此，在路由模式下，务必使用地址池方式做源 NAT 出口，并确保该地址池在两台设备上都已配置。

 核心差异总结

两种模式的本质区别在于流量如何从 A 切换到 B，而非会话本身的处理逻辑。

你提到的“VRRP方式”和“路由主备方式”，其实就是H3C防火墙RBM（Remote Backup Management，远端备份管理）双机热备的两种核心部署模式。VRRP方式适合传统三层网络，而路由主备方式多用于与动态路由（如OSPF）协议配合的场景。

虽然这两种模式的流量切换机制不同，但在会话处理逻辑上完全相同。理解清楚这一点，你的两个疑问就都迎刃而解了。

故障切换下的会话处理流程

你担心的“会话中断”问题并不会发生，因为主防火墙（A墙）在处理用户访问百度的流量时，已经实时将这条会话的完整信息（源/目的IP、端口、协议等）同步给了备墙（B墙）。这个备份过程非常快，对于用户业务来说是无感知的。

具体到你的疑问，流程是这样的：

1. 故障前（会话已备份）

   • 用户Host访问百度，流量经过A墙，A墙建立了一条会话。

   • A墙（主设备）立即通过RBM数据通道，将这条会话信息实时备份给了B墙。

   • 此时，B墙的会话表里已经有一条完全相同的会话信息，只是处于“备用”状态，不转发数据。

2. 疑问 1：故障后，内网请求上到B墙，会话会新建吗？

   • 答案：不会新建。

   • 流程： A墙故障 -> 流量切换发生 -> B墙升为新主设备。

   • 匹配： 用户Host的请求报文到达B墙。B墙在自己的会话表里查找，完美匹配到了之前从A墙备份过来的那条会话。因此，B墙知道这个报文属于一个已有连接，直接允许它通过并转发出去，从而保证了业务不中断。

3. 疑问 2：故障后，百度的回包回到B墙，如何匹配转发？

   • 答案：同样完美匹配。

   • 流程： 百度服务器的回包到达B墙。回包的源IP是百度，目的IP是你内网主机的IP。

   • 匹配： B墙在会话表里查找（会话表里记录了正向和反向的信息），同样能完美匹配到这条会话。因此，B墙知道这个回包应该发给谁，并正确地将报文转发给内网的Host。

   • 这个过程保证了TCP/IP连接的双向通信都是正常的。

补充说明：VRRP方式与路由主备方式的区别

这两种方式主要在于流量如何“切”到B墙，但B墙接到流量后，查找备份会话的处理逻辑是完全一样的。

操作与验证

如果想确认这个机制的运行情况，可以在设备上进行验证：

1. 查看会话表：在A墙和B墙上分别执行命令 display session table brief，你会看到两边的会话表项几乎是一样的。

2. 查看备份状态：通过命令 display rbm status 或Web界面中的“高可靠性 > 高可靠性状态”，可以确认会话表项备份状态是否为“开启”。

总结来说，H3C防火墙的RBM双机热备机制，核心就在于“会话备份”和“流量切换”的联动。正是由于会话已经提前同步，故障后无论是内网新请求还是外网回包，到达B墙后都能直接匹配已有会话，从而实现了业务的无缝接管。