前言
最近在负责高校校园网的深信服零信任（aTrust）项目时，遇到了一个非常典型的集群故障。在控制中心组建集群后，出现了"主节点访问正常，从节点访问失败"的诡异现象。经过层层抽丝剥茧，最终发现竟然是交换机上一条不起眼的"全局策略"在作祟。本文将完整复盘这次从流量镜像到trace-pkt抓包的排错全过程。
一、 故障现象与环境拓扑环境背景：
深信服aTrust控制中心已组建分布式集群（1主1从），业务运行在虚拟化环境中。
故障表现：
1.访问集群VIP（或主节点IP）时，业务正常，控制台登录无异常。
2.直接访问从节点IP时，页面加载超时或报错，无法打开管理界面。网络拓扑简述：
客户端 -> 核心交换机1->核心交换机2 -> 深信服aTrust集群（分发器部署在主节点上，用户请求由分发器分发给主节点/从节点）
二、 初步排查：流量都去哪了？
既然主节点正常，首先怀疑是集群分发逻辑或从节点本身的问题。为了验证猜想，我在交换机的上联口以及深信服设备的业务口做了端口镜像，抓取流量进行分析。
镜像流量分析结果：
1.分发器（主节点）行为正常： 抓包显示，集群分发器成功接收到了客户端的请求，并按照负载均衡算法将请求转发给了从节点。
2.从节点行为正常： 从节点确实收到了分发器转发过来的请求包，并且操作系统内核也成功返回了响应包（Response）。
3.诡异的现象： 分发器（主节点）始终没有收到从节点的回包。然而，在交换机的上联口（连接防火墙或上层网络的方向），竟然抓到了从节点发出的回包！初步结论：
从节点的回包"迷路"了。它没有按预期返回给集群分发器，而是被交换机"偷运"到了上联口。
三、 深度诊断：trace-pkt 抓包定位
为了进一步确认数据包在设备内部的走向，我登录到核心交换机，在诊断模式下使用 trace-pkt 命令进行诊断。
通过 trace-pkt 的输出，我发现了一个关键细节：
- 从这个可以看出，从节点回包正常到了交换机，但是交换机在进行转发的时候，从两台核心互联的接口发出去了。
这说明数据包在离开从节点网卡时是正常的，但在经过交换机转发的瞬间，被"动了手脚"。
四、 根因分析：被"劫持"的流量
既然问题出在交换机转发层面，我立即对核心交换机的配置进行了排查。经过对ACL（访问控制列表）和策略路由的逐一核对，终于发现了一条命中该流量的全局策略。故障根因：
该交换机上配置了一条全局策略（Policy-Based Routing / 策略路由），其原本的业务意图是："为了让访问指定公网地址的请求转到对应的交换机/出口上"。
然而，由于集群是后来组建的，没有从核心交换机的该条策略中排除集群地址，导致从节点返回给分发器的流量也被这条策略命中。交换机强制将这些回包进行了重定向（Redirect），直接转发给了上联口，而不是在本地局域网内正常交换给分发器。
这就解释了为什么：
1.从节点认为自己发了包（MAC正确）。
2.分发器收不到包（被交换机半路劫持）。
3.上联口却收到了莫名其妙的回包（被策略重定向到了那里）。
五、 解决方案
定位到问题后，解决起来就非常简单了。优化方案：
修改交换机上的全局策略，在匹配条件中排除掉深信服集群的IP地址。配置修改并保存后，再次测试访问从节点，业务瞬间恢复正常。通过 trace-pkt 再次验证，回包顺利回到了分发器，上联口也不再出现异常流量。
六、 总结与后续
这次故障排查再次印证了网络运维中的一条铁律："双向流量都要看"。很多时候我们只关注请求是否到达，却忽略了回包是否迷路。交换机上的策略路由虽然强大，但如果配置不当，极易引发这种隐蔽的"非对称路由"或"流量黑洞"问题。