双出口不对称路由排障复盘：回包进错防火墙，会话为什么会丢？

双出口网络里，最怕的不是链路断了。

链路断了，反而好排。

接口 Down、BGP 邻居断、健康检查失败，告警一出来，方向很清楚。

真正麻烦的是：

用户反馈通常是：

• 有时能打开，有时打不开；

• 刷新几次又好了；

• 强制走单出口就正常；

• 双出口同时启用就异常；

• 防火墙策略日志看不到明显拒绝；

• 抓包只看到单方向流量。

这类问题，别只盯着“出口有没有断”。

更应该先问一句：

先说一个容易误解的点：

不对称路由本身不是原罪。

如果中间全是普通三层设备，正向路径和回程路径不一样，不一定有问题。路由器只看目的地址转发，不关心这条流量是不是“有来有回”。

但企业网络很少这么简单。

中间往往有：

• 防火墙；

• NAT；

• VPN 网关；

• WAF；

• 负载均衡；

• SD-WAN；

• 上网行为管理；

• 安全审计设备。

这些设备很多都是有状态设备。

它们不是简单转发包，而是要维护会话表。

比如一条访问：

防火墙会记录：

• 源地址、目的地址；

• 源端口、目的端口；

• 入口、出口；

• 命中的策略；

• NAT 后的地址和端口；

• TCP 状态到了哪一步。

如果 SYN 从 FW-A 出去，SYN/ACK 却从 FW-B 回来，FW-B 没看到前面的 SYN，也没有这条流对应的 NAT 映射条目。

它很可能直接判断：

这不是一条合法会话。

然后丢掉。

注意，这里不是说 FW-B 没有 NAT 配置。

它可能有同样的 NAT 地址池配置，但它没有这条具体流的动态 NAT 映射条目。

这是很多双出口故障的关键。

看一个典型场景。

企业有两条互联网出口：

客户有自有公网段，通过两条运营商线路做多线接入。平时两条出口都启用。

现象是：

• 单独走 ISP-A，业务正常；

• 单独走 ISP-B，业务也基本正常；

• 两条出口同时启用，某个 SaaS 业务偶发超时；

• 出口带宽不高；

• 防火墙策略看起来都放了；

• 用户说“刷新几次，有时候又好了”。

一开始很容易怀疑：

但如果盯住一条具体流之后，问题就清楚了。

在 FW-A 上看到：

在 FW-B 上看到：

这说明什么？

说明请求从 FW-A 出去了，回包却从 FW-B 回来了。

FW-B 没见过这条连接的开始，也不知道怎么还原 NAT，于是把回包丢了。

链路没断。

路由也不是完全没有。

真正的问题是：

同一条业务流没有经过同一台状态设备。

排这种问题，很多人会说：

路由表里不是都有默认路由吗？

但双出口排障不能只看“有没有路由”。

要看的是：

举个例子。

正向路径：

回程路径：

对路由来说，两边都可能“可达”。

但对防火墙和 NAT 来说，这是一条被拆开的会话。

这里还要补一个细节：

所以，不对称路径的核心不是“TCP 不喜欢”，而是：

状态设备没有看到完整会话。

如果企业有自己的公网地址段，同时通过 ISP-A、ISP-B 做 BGP 宣告，那么回程路径就不完全由你决定。

你从 ISP-A 出去，不代表对端一定从 ISP-A 回来。

公网回程可能受这些因素影响：

• 上游运营商选路；

• AS Path；

• Local Preference；

• MED；

• Community；

• 对端网络策略；

• CDN 或云厂商边界调度。

这里有个常见误区：

不是把公网段切更细宣告出去，就一定能控制回程。

很多运营商对 IPv4 小于 /24 的明细路由会过滤。

所以 BGP 控制回程，只能“影响”，不能保证全网都按你想的走。

双出口最常见的坑，就是 NAT、出口、路由没有绑定清楚。

稳妥做法应该是：

如果一条流从 A 出去，却用了可能从 B 回来的地址，故障就会变成随机的。

尤其是双防火墙、共享地址池、自有公网段、多线 BGP 场景，更要注意这个问题。

很多人喜欢双防火墙 Active-Active，觉得带宽利用率高。

但这里要分清两件事：

会话同步解决的是：

路由一致性解决的是：

这两个问题不是一回事。

即使会话同步正常，如果两台设备的：

• 路由表不一致；

• PBR 不一致；

• NAT 策略不一致；

• 安全策略不一致；

• 上下行路径不一致；

仍然可能出问题。

Active-Active 不是不能做，但一定要确认：

少一个都可能埋雷。

这里也要说严谨一点。

大多数现代 ECMP 默认不是逐包负载，而是基于五元组做哈希，尽量保证同一条流走同一路径。

真正危险的是：

• 链路抖动；

• BFD/健康检查频繁切换；

• 下一跳集合变化；

• SD-WAN SLA 判断频繁漂移；

• 策略路由动态调整；

• 某些设备启用了逐包负载。

这些都会导致会话中途路径发生变化。

对普通路由来说，这可能只是换条路。

但对经过 NAT、防火墙、审计设备的 TCP 会话来说，就可能直接断。

不对称路径排障，最忌讳泛泛地看。

不要一上来就问：

这些都太粗。

正确做法是锁定一条具体五元组：

然后看它的完整路径。

可以按这 4 个问题查。

第一，SYN 从哪台设备出去？

看防火墙会话表、策略日志、NAT 表、抓包。

不同设备命令不同，但检查方向类似。

示例：

常见命令方向：

不要死背命令，重点是看：

• 入接口；

• 出接口；

• NAT 后地址；

• 会话状态；

• 命中的策略。

第二，NAT 映射建在哪台设备上？

如果 FW-A 做了源 NAT，那么回包最好也回到 FW-A。

因为 NAT 映射条目在 FW-A 上。

FW-B 即使有相同的 NAT 规则，也不代表它有这条流的动态映射。

这是很多人容易混淆的点。

第三，SYN/ACK 从哪回来？

这一步最关键。

如果 FW-A 只看到：

而 FW-B 看到：

那基本就坐实了：回程走错了。

抓包时可以用类似过滤条件：

重点不是抓很多包，而是看同一条流有没有完整三次握手：

第四，有没有 RPF / 反欺骗丢包？

很多防火墙或路由设备会做反向路径检查。

如果一个包从某个接口进来，但设备查路由后发现：

到这个源地址的回程不应该走这个接口

就可能触发：

这种日志非常有价值。

看到它，不要只改策略，要回头查路径。

排双出口故障时，先把现象做个归类，别一上来全网乱查。

这类问题的解决方式，一般有 5 类。

最基础，也最有效。

不要让出口、NAT 地址、路由策略三者各管各的。

不是所有业务都适合负载均衡。

像这些业务，稳定性往往比带宽利用率更重要：

• ERP；

• OA；

• 银行接口；

• 视频会议；

• 云数据库；

• 专线互联；

• 重要 SaaS 系统。

可以用 PBR、SD-WAN 应用策略、路由策略固定出口。

如果是自有公网段多线接入，就要设计 BGP 回程策略。

常见手段包括：

• AS Path Prepend；

• MED；Community；

• 更优路由宣告；

• 主备宣告；

• 分运营商策略。

但要记住：

公网里的最终路径选择，不只由你决定。

如果业务稳定性要求高，很多时候主备比双活更简单可靠。

如果必须双活，就要确认：

• 会话是否同步；

• NAT 是否同步；

• 路由是否一致；

• PBR 是否一致；

• 策略是否一致；

• 回程是否可能打到另一台设备。

有些设备可以开启 asymmetric routing 或放宽 TCP 状态检查。

但这更像临时止血，不建议当长期设计。

因为它可能降低安全检测、会话审计和日志准确性。

多路径负载时，要确保同一条 TCP 流尽量走同一条路径。

尤其不要在有状态安全设备前后做不可控的逐包负载。

如果健康检查频繁抖动，要先解决链路质量和策略阈值，不要让业务会话在不同出口之间来回漂。

双出口网络里，最怕的不是断链。

断了，告警会告诉你。

真正麻烦的是：

排这种问题，要先画两条线：

然后盯住同一条五元组，看它有没有经过同一台状态设备。

这才是不对称路由排障的关键。

你现场遇到过这种“双出口偶发失败”的问题吗？