数据包路由至错误接口问题跟进：ip规则与路由配置排查请求

嘿，我来帮你拆解这个问题——核心现象是从10.0.0.13发往10.10.10.10的流量，被引导到了test-interface而非预期的eth1，这说明当前的IP规则优先级或匹配逻辑，可能让自定义表（table 1234）的路由优先于主表路由生效了，和你预期的「规则不应优先级高于路由」目标不符。

下面是一步步的排查思路：

1. 先确认IP规则的优先级顺序 #

首先执行ip rule ls，输出的第一列是优先级数值——数值越小，优先级越高。你需要重点看：

• 指向table 1234的那条规则（比如from 10.0.0.13 lookup 1234），优先级是不是低于主表的默认规则？（主表规则的优先级通常是32766）
• 如果这条自定义规则的优先级数值比32766小，那它会优先匹配并引导流量走table 1234的路由，这就是问题根源。

举个反例，如果你的ip rule ls输出是这样：

0:      from all lookup local 
32765:  from 10.0.0.13 lookup 1234 
32766:  from all lookup main 
32767:  from all lookup default 

那32765的规则优先级高于主表的32766，10.0.0.13的流量自然会先走table 1234的路由，而非主表中指向eth1的路由。

2. 验证自定义表（table 1234）的路由内容 #

执行ip route show table 1234，看看里面是不是包含了针对10.10.10.10的路由，或者默认路由指向了test-interface？比如：

default via 192.168.1.1 dev test-interface 
# 或者
10.10.10.0/24 dev test-interface scope link 

如果是这样，那当规则命中table 1234时，流量肯定会走test-interface，而忽略主表的路由配置。

3. 确认主表路由的正确性 #

再看ip route ls（主表）的输出，确认主表中有没有针对10.10.10.10的有效路由，或者默认路由指向eth1？比如：

10.10.10.0/24 via 10.0.0.1 dev eth1 
# 或者
default via 10.0.0.1 dev eth1 

如果主表有正确的路由，但流量还是走了test-interface，那基本可以锁定是规则优先级的问题。

4. 临时调整优先级验证问题 #

如果确认是规则优先级过高，你可以临时调低它的优先级（让数值比32766大），比如：

ip rule del from 10.0.0.13 lookup 1234
ip rule add from 10.0.0.13 lookup 1234 priority 32767

调整后再测试发流量，看看tshark -i eth1能不能抓到包。如果可以，就说明问题确实是规则优先级设置错误。

5. 额外检查：规则的匹配逻辑是否过宽 #

还要确认你的IP规则是不是匹配条件太宽泛——比如有没有误写为from all to 10.10.10.10 lookup 1234？如果是这样，不管源地址是什么，只要目标是10.10.10.10的流量都会走table 1234，这也会导致你看到的现象。

如果以上步骤还没解决问题，麻烦把以下命令的完整输出贴出来，我帮你进一步分析：

• ip rule ls
• ip route ls
• ip route show table 1234
• ip addr show dev eth1和ip addr show dev test-interface（确认接口IP配置）

内容的提问来源于stack exchange，提问作者Kasper Nielsen