Netfilter包流图中routing decision与reroute check如何选择下一跳

Netfilter包流示意图里的两个路由节点，分支选择逻辑完全围绕包的收发方向、路由属性是否被修改两个核心判定，没有复杂的黑魔法，具体规则和实际场景对应如下：

初始路由决策（routing decision） #

这是数据包刚进入内核协议栈、还没经过任何Netfilter钩子时触发的第一次路由查找，所有方向的包都会走到这个节点，下一跳只看两个判定结果：

• 入站方向的包（从网卡进来的流量）：查路由表判断目标IP是不是属于本机
  • 目标是本机：走本地入站分支，后续依次经过PREROUTING钩子，最终送到本地对应的用户态进程处理
  • 目标不是本机：走转发分支，后续经过FORWARD钩子、POSTROUTING钩子后，从对应出网卡发往外部
• 出站方向的包（本地用户态进程主动发出的流量）：查路由表找到对应的出接口、下一跳地址，直接送入OUTPUT钩子流程

举几个最常见的场景：
假设你本机网卡IP是192.168.1.10，网关是192.168.1.1

• 你在本机ping自己的网卡IP：routing decision判定目标是本机，直接走入站分支，包不会发到网卡上
• 你ping同网段另一台设备192.168.1.20：routing decision判定目标不是本机，走转发分支，直接从二层发往对应设备
• 你ping公网IP8.8.8.8：routing decision判定目标不是本机，下一跳指向网关，走转发分支
• 你在本机用curl访问网站：curl发出的包属于本地出站，routing decision查到走默认网卡出网，直接送入OUTPUT钩子处理

重路由校验（reroute check） #

这个节点是本地出站包专属的校验步骤，只会在包走完OUTPUT钩子之后触发，核心作用是兜底OUTPUT链上的规则对包的修改——毕竟OUTPUT链是可以改包的目标地址、打fwmark标记的，这些改动完全可能让之前的初始路由结果失效。
它的下一跳选择规则非常直接：

• 检查包经过OUTPUT钩子时，有没有改动目标IP、fwmark、源IP这类会影响路由结果的属性
  • 没改动任何路由相关属性：直接沿用初始路由结果，走外发分支，经过POSTROUTING钩子后从网卡发出
  • 改动了路由相关属性：判定原有路由结果作废，走重路由分支，把包送回路由查找流程重新选路，如果改完之后目标IP是本机，甚至会直接走本地入站分支交给本机进程处理

举个非常典型的例子：
你在本机加了一条NAT规则：iptables -t nat -A OUTPUT -d 1.2.3.4 -j DNAT --to-destination 127.0.0.1:8080

• 你在本机curl访问1.2.3.4，初始routing decision查到这是公网IP，准备走外发分支送入OUTPUT钩子
• OUTPUT钩子触发DNAT，把包的目标IP改成了环回地址127.0.0.1，包走到reroute check时，检测到目标IP被修改，原来的公网路由结果已经失效
• 这时候就会触发重路由分支，重新查路由发现目标是本机环回口，最终包被送到本地监听8080端口的进程，根本不会发到外网
• 如果你只是在OUTPUT链给包打了个日志标记，没动任何路由相关属性，reroute check就直接放行走外发流程，不会做多余的路由查找

容易搞混的点 #

两个节点触发场景完全不重叠：

• routing decision是全局首次路由判定，覆盖入站、转发、本地出站所有流量，每个包第一次进协议栈都会走一次
• reroute check只处理本地进程发出的出站包，专门用来校验OUTPUT链的修改对路由的影响，入站、转发的流量根本不会走到这个节点

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