策略路由概念：路由与策略路由的区别、基于策略的路由规则
先说说“路由”到底在干什么
我们平时说的路由，其实是个很朴素的东西。设备收到一个数据包，看一眼目的IP，查路由表，找到下一跳，扔出去。就这么简单。路由表是怎么填的？静态配一条，或者跑个OSPF、BGP自动学。核心逻辑就是：目的地址 → 下一跳。
我在项目里见过不少刚入门的同学，觉得路由嘛，就是查表转发。嗯，这句话没错，但只对了一半。路由确实只关心“目的地在哪”，它不关心这个包是谁发的、长什么样、是不是要加密。它就是个“快递员”，只看收件地址，不问包裹内容。
那策略路由又是什么？
策略路由就不一样了。你可以把它理解成一个“有脾气的快递员”——它不仅看收件地址，还要看寄件人、包裹大小、是否易碎、甚至今天心情好不好。说白了，策略路由允许你根据更多的条件来决定数据包的转发路径。
举个我在实际运维中碰到的场景：公司有两条出口线路，一条走电信，一条走联通。平时默认路由走电信。但是财务系统访问银行专线，必须走联通，因为银行那边只认联通IP。怎么办？你没法改目的IP，因为银行地址就一个。这时候策略路由就派上用场了：源IP是财务网段 → 下一跳指向联通出口。你想想看，如果没有策略路由，你只能整条默认路由切到联通，那其他业务怎么办？
路由 vs 策略路由，我习惯这么对比
| 对比维度 | 传统路由 | 策略路由 |
|---|---|---|
| 匹配依据 | 目的IP地址（最长匹配） | 源IP、目的IP、协议、端口、DSCP、入接口… |
| 处理时机 | 路由查找 | 在路由查找之前介入 |
| 灵活性 | 低，只能按目的转发 | 高，几乎可以匹配任何报文特征 |
| 性能开销 | 低，硬件加速友好 | 较高，需要逐包匹配规则 |
| 典型场景 | 互联网接入、骨干转发 | 多出口选路、流量负载分担、VPN分流、DLP重定向 |
看表就知道，策略路由的代价是性能。我在一个日处理百万级连接的网关上试过，如果策略路由规则写得太多太复杂（比如用了深度报文检测的匹配项），CPU直接飙到80%。所以，能用路由解决的问题，不要硬上策略路由。
基于策略的路由规则长什么样？
不同设备实现细节不一样，但核心套路是统一的：
- 定义匹配条件：源地址、目的地址、协议、端口、报文长度、ToS字段……甚至可以用ACL引用。
- 指定动作（Action）：设置下一跳、出接口、VPN实例、甚至丢弃或重定向到某个服务链。
- 绑定到入接口：策略路由通常只对特定入口的报文生效，不像路由表全局生效。
- 设置优先级/顺序：规则从上到下匹配，命中即停止。
我记得有一次做金融客户的项目，他们要求所有HTTPS流量都走一条专门的加密隧道出去审计。我就在网关上配了一条策略路由：匹配目标端口443 → 下一跳到隧道接口。但是有个坑——TLS握手时客户端会先发一个ClientHello，如果隧道本身还需要建立连接，就会死循环。后来我在规则里加了一个条件：忽略从隧道接口进来的报文。这就是典型的“避坑指南”。
策略路由的执行流程（SVG）
下面这张图展示了策略路由的核心判断逻辑。说白了，它就是在路由表干活之前，先插一腿。
规则如何组织？我一般用ACL做匹配模板
实际配置中，策略路由通常依赖ACL（访问控制列表）来定义匹配条件。比如华为设备上的traffic-policy结合流分类，或者Cisco的route-map配合match ip address。核心都是一样的：把匹配条件和动作封装成一个“策略”，然后应用到接口上。
# Cisco IOS 示例：通过 route-map 实现策略路由
access-list 100 permit ip 192.168.1.0 0.0.0.255 any
!
route-map PBR permit 10
match ip address 100
set ip next-hop 10.0.20.1
!
interface GigabitEthernet0/1
ip policy route-map PBR上面这段代码应该很眼熟。我在多个项目里都用过这种模式。注意两点：一是route-map的顺序很重要，默认最后一个隐含deny all；二是set ip next-hop后面如果写多个地址，设备会按顺序尝试，直到一个可达。
debug ip policy看匹配计数，确认规则生效后再上线。不然你可能配了半天，结果流量根本没进策略路由，全走默认路由了——别问我怎么知道的。
策略路由在DLP集成中的角色
回到我们的课程主题。API网关做DLP，本质是要把特定流量“截获”出来，送给DLP引擎检测。怎么截？策略路由就是那个“交通指挥员”。你可以在网关上配置：匹配HTTP POST包含敏感字段 → 重定向到DLP检测接口。这样做的好处是不动客户端配置，也不需要在每个业务服务器上装Agent。
但这里有个性能陷阱：DLP检测通常是串联的，意味着流量先到DLP引擎，再回到网关继续转发。如果策略路由规则没写对，很容易造成环路。我早期就吃过这个亏——一条策略路由把检测完的流量又送回了检测接口，结果CPU直接打满。后来加了一条跳过来源为DLP引擎的报文的规则才解决。