这种情况确实挺让人头疼的——明明集群各项功能（故障转移、实时迁移、CSV访问）都正常跑着，防火墙那边却冒出了完全不符合逻辑的跨网段SMB流量：从管理网卡的IP发往其他主机的CSV网段IP，而且还走了默认网关。我来分享几个实用的排查方向，你可以逐一验证：

• 重新确认集群网络的优先级与角色配置
  虽然你提到其他网络只配置了集群通信，但还是建议再核对一遍：

  • 用Get-ClusterNetwork命令查看所有集群网络的Metric值，这个数值越小优先级越高。确保CSV专用网络的Metric比管理网络低，这样集群服务才会优先选择CSV网卡进行内部通信。
  • 检查每个集群网络的角色设置：CSV网络应该只勾选「允许集群通信」，管理网络勾选「允许集群和客户端通信」，别搞反了配置。

• 验证主机路由表与ARP缓存状态
  手动traceroute正常不代表系统路由逻辑一直没问题：

  • 执行route print命令，找到CSV子网对应的路由条目，确认它是直连路由（Next Hop显示为On-link，Interface对应的是CSV网卡），没有被错误的静态路由覆盖。
  • 尝试清空ARP缓存（arp -d *），然后观察防火墙的流量情况——有时候ARP缓存异常会导致系统错误选择源网卡。

• 排查SMB多通道与绑定配置
  Hyper-V集群依赖SMB多通道优化存储流量，这部分配置出问题也可能导致源IP选择错误：

  • 用Get-SmbServerConfiguration查看是否启用了SMB多通道，再用Get-SmbMultichannelConnection检查当前SMB连接的网卡绑定情况，看有没有把管理网卡错误绑定到CSV相关的SMB会话上。
  • 如果发现异常，可以用Set-SmbServerNetworkInterface调整SMB对网卡的绑定规则，确保CSV网段的网卡被优先用于CSV的SMB通信。

• 深挖集群服务日志与跟踪信息
  日志往往能找到问题的蛛丝马迹：

  • 打开事件查看器，定位到「Applications and Services Logs > Microsoft > Windows > FailoverClustering」，搜索和SMB、网络接口选择相关的警告或错误事件，看有没有异常提示。
  • 如果默认日志不够详细，可以用Set-ClusterLog -Level 5开启高级别集群日志，重现问题后执行Get-ClusterLog导出日志，搜索关键词「SMB」「network interface」，应该能找到系统选择错误源IP的具体原因。

• 检查Windows源IP选择策略
  Windows的源IP选择遵循RFC 3484规则，可能存在边缘配置影响了逻辑：

  • 用netsh interface ipv4 show policy查看当前的源IP选择策略，确认没有自定义规则干扰直连网段的源IP选择。
  • 核对各个网卡的Interface Metric：CSV网卡的Metric应该低于管理网卡，这样系统在访问直连的CSV网段时，会优先选择CSV网卡作为源接口。

这些步骤应该能帮你定位到问题根源，毕竟集群本身运行正常，大概率是某个网络配置或服务的细微偏差导致了错误的路由选择。

备注：内容来源于stack exchange，提问作者Goran