当同一台防火墙可以把流量走两条路时，你可能并不是网络故障的受害者，而是被“等价路由”悄悄耍了一把——我同事小王就是这么吃过亏，幸好有办法补救。说实话，那天他接到加急工单，说局域网用户访问位于ISP2的Server2时，网速忽快忽慢，文件传输断断续续，大家都以为是服务器或链路问题，结果抓包一看，流量竟然走了不止一条路径，而其中一条明显不是最短路径，延迟和丢包就从那儿冒出来的。
问题的根源很简单也很容易被忽视：防火墙做多链路出接口时，如果存在等价或覆盖的路由条目，流量可能根据路由表里的不同下一跳走向不同的出口。不得不说，这种路由“随缘”行为对状态感知型防火墙尤其致命，防火墙的连接跟踪会由于前后包经不同路径而失配，导致会话重置、NAT不一致和用户体验崩盘。反正我是这么觉得，许多运维把注意力放在链路本身，却忽略了路由选择策略——这才是问题的真正开关。
好消息是有术可以解：运营商地址库选路把ISP网段批量写入防火墙，绑定到具体出接口后，设备会生成面向该运营商的路由条目，让发往该ISP网络的流量优先从约定接口发出。以华为防火墙为例，厂商出厂时就预置了像china-mobile.csv、china-unicom.csv、china-telecom.csv和china-educationnet.csv这样的运营商地址文件，管理员也可以把各个ISP的IP段分别整理到CSV里导入。指定接口关联运营商名称后，防火墙会批量生成到该运营商网络的ISP路由，路由表里显示的协议类型一般标为UNR，路由优先级为70，这个数值低于手工静态路由设定的优先级（列如60），所以如果你有更高优先级的静态策略，UNR不会无条件覆盖，但它能自动把大量目标IP指向预期出口，极大减少误走非最短路径的概率。
在实际操作里，有几个容易被踩的坑需要提前说明。第一不要盲目导入默认CSV就完事，厂商预置的运营商地址库可能不是最新的，尤其是ISP合并、IP段重分配后会出现遗漏或过期条目。我那次协助小王排查时，先把原有路由备份出来，再把各ISP的网段按实际BGP公告或运营商公布的段拆成CSV导入，随后在防火墙上把对应的接口和运营商名称做关联，导入后检查路由表确认UNR条目出现并指向期望的下一跳，然后用traceroute逐跳验证流向是否变成了最短路径。其次要关注静态路由与UNR的优先级关系，如果有业务必须走特定出口，保留优先级更高的静态路由；对于绝大多数面向互联网的访问，交给ISP选路处理可以把路径稳定性和性能都提升。还有一点常被忽略，流量从不同ISP出去回程的路径也可能不一致，引起NAT或会话问题，遇到这种情况可以思考对公网服务使用源NAT，或者对关键应用做会话保持的策略路由。
从运维视角来看，未来多链路、多运营商并存会越来越常见，许多公司会逐步把这类细粒度路由交给SD-WAN层或更智能的流量引擎去管，但在过渡期内，掌握和善用运营商地址库选路是成本最低、见效最快的手段之一。我朋友小李的项目就是靠这招把外部访问延迟稳定下来，省下了好几次加班和客户投诉；当然如果你的网络里有大量对路径敏感的应用，还是要把路由策略、NAT策略和会话追踪一起做全盘思考。
说到这里，想听听你们的经历：你有没有遇到过由于路由“走偏”导致应用异常的案例？你是怎么发现并解决的，说说你的做法和踩过的坑吧。
暂无评论内容