表 200 里的 VPN 默认路由藏起了你的 LAN 路由

四项检查能把策略表故障与路由故障区分开：哪条规则命中、该规则指向哪张表、那张表里有什么、表内哪条路由胜出。一旦较早的表给出了路由，主表就不再被查询，所以你在主表里看到的 LAN 条目可能与你正在测试的数据包无关。按顺序做这四项检查，缺失的路由会在第三步而不是第四步暴露出来。

最长前缀匹配只在一张表内部进行；它不会把所有表的路由当成一个列表来比较。

查询在第一张给出答案的表处终止

设想一条策略：来自某个子网的流量先查表 200，表 200 里有一条经隧道的默认路由，而主表里有 LAN 前缀。发往 LAN 地址的数据包可能匹配表 200 里的那条默认路由，并停在那里。由于查询已经产出了路由，后面那条主表规则就再也没有机会提供更具体的那一条。结果就是数据包进了隧道，而一条完全可用的 LAN 路由闲置不用。

较早的规则和机器自身的本地地址查询仍然生效，所以测试必须使用真实流量所携带的源、标记和接口。换用别的条件去查，LAN 可能被正确选中，这恰好掩盖了你正在找的那个故障。

把 LAN 例外放在它该在的地方

被选中的表可以携带它所需的 LAN 路由、直连路由和端点路由，这样策略就能自给自足。另一种设计使用针对 LAN 前缀的显式前置规则，或者一条故意抛出的路由，把前缀交给后面的查询。每种都是有不同归属者的正当模式。选择依据应是预期策略以及谁来维护这些路由，而不是哪种写起来更短。

无论采用哪种模式，例外都必须出现在定义策略的地方。手工添加却没有记录的路径会在下次重启时消失，诊断也会随之而去。

不要把主表整表复制过来

把主表里的每条路由都复制到策略表里，看起来像修复，实际上只是造了一个快照。管理员可能动态增删地址和接口，副本会在无人察觉的情况下过期。让路由的生命周期归属于它的配置所有者，从配置重新生成这张表，而不是从某个时间点复制。

复制出来的表同样违背初衷，因为它复制了策略本应约束的回退行为。

把回程与路由分开检查

即使查询选中了预期路径，回程仍可能因与表无关的原因失败。转换可能被应用在错误的接口上，反向路径校验可能拒绝从意外路径到达的数据包，或者端点干脆不回应。这些是证据各不相同的独立故障，改路由条目一条也修不好。

在改动前后都为那条具体流量保存查询结果，让修正保持可见。全局关闭反向路径校验或清空规则，既补不出缺失的路由，也会削弱不相关的控制。

记录规则、表、胜出的路由和回程路径。正是这份记录把策略失误和坏掉的服务分开。