摘要

  • RFC 3704 指出，严格反向路径转发会比较数据包的入接口与路由器回到其源地址时所选的接口；两者不同，合法数据包也可能被丢弃。
  • 可行路径检查可以接受已知的备用路径，但前提是相关路由在执行检查的设备之间一致传播；宽松检查更能容忍非对称路径，却放弃了大部分方向性证据。

路由器检查的是“回程”

设想一个同时连接两家运营商的网络，经运营商 B 发出数据包，源地址属于该网络获准使用的前缀。更远处的路由器从面向 B 的接口收到它，却发现自己的最佳回程路由指向运营商 A。严格反向路径检查（RPF）会拒绝这个包。路由器并没有核实是谁发出的；它只是把入接口与自己的转发表视图作比较。

2004 年 3 月发布的 RFC 3704 是最佳当前实践 BCP 84，更新了更早的 RFC 2827（BCP 38）。入口过滤的目标仍是减少源地址伪造，但多宿接入改变了路由器能观察到的证据：数据包实际走过的方向，未必与路由系统认为返回源地址应走的方向相同。

RFC 3704 没把“RPF”当作单一开关。按接口配置的访问控制列表逐包核对源前缀，规则清晰，但手动列表可能跟不上地址或运营商变更。严格 RPF 则动态查询转发信息库（FIB）：只有当数据包从到达源地址的最佳路由所对应的接口进入时，才放行。它适合路径对称的用户边界；如果路由不对称、前缀缺失，或运营商策略没有接受相关路由，同一规则就可能误丢合法流量。

备用路径不是自动可信

可行路径 RPF 把被保留的替代路由也纳入检查，不再只认当前 FIB 中的单条最佳路由。在多宿场景里，它能避免只因另一条路径暂时胜出就丢掉合法数据包。

但可行路径列表并不是所有可能网络路径的清单。RFC 3704 强调，相关路由必须一致地通告给执行检查的设备。某个前缀可能被一家运营商接受，却被另一家因路由映射或策略过滤。通告被过滤，数据包也可能随之被过滤。于是，一个看似局部的边界规则，实际上依赖多个管理域的控制决策。

宽松 RPF 走向另一个极端：它只问是否存在到源地址的路由，不问该路由是否指向数据包的入接口。这样能容忍非对称流量，但被伪造的、可路由的地址也可能通过。若设备把默认路由也算作“存在路由”，检查还会更弱，除非实现另行处理默认项。RFC 3704 因此不建议把宽松检查作为客户到运营商边界的主要源地址过滤；它更适合在上游拒绝未路由或保留地址，或确认另一张网络至少执行了某种过滤。

文档给出的其他办法进一步说明这不是单点配置问题：让各运营商完整获知客户前缀，必要时使用独立于运营商的地址和 BGP；把每个运营商分配的源前缀只从该运营商方向发出；或从客户数据库自动生成过滤列表。不同方案把工作放在不同位置，但路由状态不会因此成为身份凭证。

RFC 3704 还主张在多个层级过滤。离真实主机越近，越能判断相邻系统可使用哪些地址；更远的路由器通常只能判断源地址可能属于某个可达前缀。多层过滤可以改善追踪线索，却无法确认攻击者身份，也不能证明全网部署覆盖率。2020 年的 RFC 8704 更新 RFC 3704，引入增强型可行路径 uRPF；它说明这个运维折中仍值得完善，不代表所有网络都已采用，也不代表所有拓扑问题已解决。

因此，持久的问题不是“严格”或“宽松”哪个永远更好，而是检查到底知道什么：一条最佳回程路由、若干可行替代路径，还是仅仅存在某条路由。判定会随路由表和检查位置而变。RFC 3704 把路由视图带入安全判断，也把路由完整性变成多方共同承担的责任。

来源