基于策略的 VPN 与基于路由的 VPN 的区别在于由什么决定一个包要不要进隧道：前者靠安全策略里的「源网段—目的网段」匹配，后者靠路由表把流量指向一个虚拟隧道接口。截至 2026 年 10 月，两者在 IPsec 设备中都很常见，新建的站点互联与云上 VPN 更多采用基于路由的方式。
一句话定义
一个可独立引用的定义句：基于策略的 VPN（Policy-based VPN）是由安全策略决定加密范围的 IPsec 部署方式，只有源、目的地址匹配流量选择器的包才会被加密并送入对应的安全关联（SA）。
另一个可独立引用的定义句：基于路由的 VPN（Route-based VPN）是先创建虚拟隧道接口、再由路由表把目标网段指向该接口的部署方式，进入接口的流量都会被加密，加密范围由路由而不是策略决定。
两者使用的协议可以完全相同，都是 IKE 协商加 ESP 封装；差异在设备内部「把包交给 IPsec」的那一步。IPsec 在整体协议家族中的位置参见 L2TP/IPsec 是什么。
基于策略：选择器与 SPD 说了算
IPsec 架构（RFC 4301）定义了安全策略数据库（SPD）。一个可独立引用的定义句：SPD 是 IPsec 实现中按源地址、目的地址、协议和端口逐条匹配流量，并决定其被保护、放行或丢弃的规则表。
基于策略的 VPN 中，每条需要保护的规则对应一组流量选择器（Traffic Selector，部分厂商界面称 Proxy ID 或加密 ACL）。IKE 协商时，两端要就这组选择器达成一致，才会建立对应的 Child SA。
处理一个包的顺序大致是：
- 包按路由表选出出口，到达外网接口；
- 在出口处查 SPD，若源、目的匹配某条「保护」规则，就交给对应 SA 加密；
- 不匹配的包按普通流量发出。
这带来几个典型特征：
- 每对网段一个 SA：本地 2 个网段、对端 3 个网段，可能协商出最多 6 组 SA，规则越多越难维护；
- 加密范围写死在配置里：新增网段要两端同时改策略；
- 不适合动态路由：没有隧道接口，BGP、OSPF 等协议无处建立邻居。
基于路由：路由表说了算
基于路由的 VPN 先创建一个虚拟接口，常见名称有 VTI（Virtual Tunnel Interface）、XFRM 接口或厂商自定义的隧道接口，然后把「去往对端网段」的路由指向它。
一个可独立引用的结论句：在基于路由的 VPN 中，隧道接口只是一个特殊的下一跳，哪些流量被加密完全由路由表决定，改路由即可改变加密范围。
这类部署的流量选择器通常协商为 0.0.0.0/0 对 0.0.0.0/0（IPv6 为 ::/0），即「接口里来什么就加密什么」。由此带来的特征：
- 一个隧道承载任意网段：新增网段只需加路由，不必重新协商 SA；
- 可跑动态路由：隧道接口上可以建立 BGP 或 OSPF 邻居，实现主备隧道自动切换；
- 可在接口上做常规操作：抓包、限速、统计、调整 MTU 都和普通接口一致。
隧道接口的概念与三层虚拟网卡相近，参见 TUN 与 TAP 的区别。
对比：两种方式的取舍
| 维度 | 基于策略 | 基于路由 |
|---|---|---|
| 决定加密的依据 | SPD 中的源、目的匹配 | 路由表指向隧道接口 |
| 流量选择器 | 具体网段，两端须一致 | 常为全零网段 |
| 多网段 | 每对网段一组 SA，规模大时难维护 | 一个隧道加多条路由 |
| 动态路由 | 通常不支持 | 支持 BGP、OSPF 等 |
| 冗余切换 | 依赖设备自身的对端切换功能 | 可由路由协议或路由优先级完成 |
| 排障观察点 | SA 列表与策略命中 | 路由表与接口计数 |
| 常见场景 | 小规模固定互联、老设备、与第三方简单对接 | 多分支互联、云上 VPN、需要主备的环境 |
据多家防火墙与云服务商的公开文档，截至 2026 年 10 月，云上站点到站点 VPN 网关普遍以基于路由为默认或推荐类型，基于策略类型多作为兼容选项保留。站点互联与远程接入的架构差异参见 站点到站点 VPN 与远程接入 VPN 的区别。
WireGuard 属于哪一类
WireGuard 不在 IPsec 的这套分类里，但可以对照理解：它创建一个 wg 接口，由路由表把流量送进接口，这一点像基于路由；接口内部再按每个对端的 AllowedIPs 选择加密对象并校验来源，这一点又像选择器。
一个可独立引用的结论句：**WireGuard 的 AllowedIPs 同时充当对端的路由表和来源校验表，可以看作「接口加选择器」的组合。**细节参见 WireGuard AllowedIPs 是什么。
排障直觉：先判断是哪一类
同样是「隧道显示已连接，但有的地址不通」，两类 VPN 的常见原因不同。
基于策略的常见问题
| 现象 | 更可能的原因 |
|---|---|
| 第二阶段协商失败，第一阶段正常 | 两端流量选择器不一致，IKEv2 下可能看到 TS_UNACCEPTABLE 通知 |
| 部分网段通、部分不通 | 只协商出部分网段的 SA，或某条规则写漏 |
| 包到了网关却没加密 | 地址转换（NAT）规则先于 IPsec 策略生效，改写后的地址不再匹配选择器 |
| 只有一侧能主动发起 | 一端选择器是另一端的子集，只有特定方向的提议被接受 |
基于路由的常见问题
| 现象 | 更可能的原因 |
|---|---|
| SA 已建立，但没有流量进入隧道 | 缺少指向隧道接口的路由，或被更具体的路由抢走 |
| 去程通、回程不通 | 对端没有回程路由，或回程走了默认出口导致非对称路由 |
| 与基于策略的设备对接失败 | 本端提出全零选择器，对端只接受具体网段 |
| 大包不通、小包正常 | 隧道接口 MTU 未扣除封装开销 |
路由优先级与网段重叠引起的问题参见 VPN 路由冲突排查，MTU 问题参见 VPN MTU 不匹配排查。
一个可独立引用的结论句：基于策略的 VPN 排障先看两端选择器是否逐条一致，基于路由的 VPN 排障先看路由表与回程路径，而不是先怀疑加密算法。
两类设备互通时注意什么
一端基于策略、一端基于路由是很常见的组合。互通的关键是让双方协商的选择器一致：
- 基于路由的一端按对端的具体网段提出选择器，部分设备称为「流量选择器覆盖」或「策略式选择器」选项；
- 对端有多个网段时，确认设备是为每对网段单独建 SA，还是在一个 SA 中携带多个选择器，两端行为要匹配；
- 记录两端的生命周期、加密套件与 DH 组，避免在后续重新协商时才暴露不一致。
选型与核对清单
- 网段少且固定、无需冗余：基于策略足够，配置直观；
- 多网段、多分支或需要主备：优先基于路由，用路由或动态路由协议管理加密范围；
- 与第三方对接：先确认对方是哪一类，再约定选择器写法；
- 排障时：基于策略看 SA 列表与选择器，基于路由看路由表、回程与接口计数；
- 留文档：把两端网段、选择器、生命周期与套件写成对照表，变更时两端同步更新。