Linux怎么查看具体的网络数据包在内核协议栈中的流向图

Linux内核并没有那种“一条命令就把数据包流向图直接生成出来”的现成功能。通常得把几种方法配合起来用：一方面，可以结合trace-cmd和kernelshark，围绕tracepoint做跟踪，把时序路径可视化出来；另一方面，也可以用bpftrace在关键函数上打点，核实数据包实际走过的路径。除此之外，forwarding状态、路由规则以及netfilter配置也得一并检查清楚，这样才能最终确认当前真正生效的转发路径。

Linux内核协议栈数据包流向没有现成“流向图”命令

Linux 内核本身不提供一键生成网络数据包完整流向图的命令或工具。所谓“流向图”，本质是数据包从网卡进入后，依次经过 netif_receive_skb() → ip_rcv() → ip_forward() 或 ip_local_deliver() → 各层协议处理（TCP/UDP）→ socket 接收队列的路径。这个路径不是静态拓扑，而是由当前配置（如 iptables、nftables、ebpf、路由表、socket 类型）动态决定的。

用 trace-cmd + kernelshark 可视化关键 tracepoint

最接近“流向图”的实操方式，是跟踪内核网络子系统的关键 tracepoint，并用图形工具还原时序路径。你需要：

• 确保内核启用 CONFIG_TRACING 和 CONFIG_NET_TRACING（主流发行版默认开启）
• 安装 trace-cmd 和 kernelshark（Ubuntu/Debian：`sudo apt install trace-cmd kernelshark`）
• 捕获典型流量（如 `ping` 或 `curl`），同时跟踪网络路径相关事件：

sudo trace-cmd record -e net:* -e skb:* -e napi:* -e irq:* -e tcp:* -e udp:* --filter 'comm == "ping"'

接着，用 kernelshark 打开刚生成的 trace.dat，再按 CPU 或 PID 的时间轴把调用链展开，数据包是怎么在 netif_receive_skb、ip_rcv、tcp_v4_do_rcv 这些函数之间一路流转的，基本就能看得很清楚了。相比单纯看文字描述，这种呈现方式显然更接近“流向图”的直观感受。

cat /proc/sys/net/ipv4/conf/*/forwarding 和 ip rule show 决定实际路径分支

很多用户以为数据包一定走 ip_forward，但实际是否转发、走哪条路由、是否被 netfilter 拦截，全由运行时状态控制。必须检查：

• cat /proc/sys/net/ipv4/conf/all/forwarding 和 /proc/sys/net/ipv4/conf/eth0/forwarding —— 若为 0，则即使有路由也不会转发
• ip rule show 和 ip route show table local —— 决定数据包是否进入 ip_local_deliver 还是 ip_forward
• iptables -t raw -L -v -n 或 nft list ruleset —— PREROUTING 和 OUTPUT 链中的 NOTRACK 或 CT 规则会绕过连接跟踪，改变后续路径

忽略这些配置，单看函数调用顺序，容易误判真实流向。

用 bpftrace 在关键函数打点验证路径

如果只需要确认某类包（比如目的端口 80 的 TCP 包）是否经过某个函数，bpftrace 更轻量：

bpftrace -e '
kprobe:ip_rcv { printf("→ ip_rcv\n"); }
kprobe:ip_forward { printf("→ ip_forward\n"); }
kprobe:ip_local_deliver { printf("→ ip_local_deliver\n"); }
kprobe:tcp_v4_rcv { printf("→ tcp_v4_rcv\n"); }
'

执行后触发流量，输出就是你实际看到的路径。注意：kprobe 不保证 100% 触发（如被 eBPF 程序提前拦截或 fast path 跳过），但它能快速验证“是否可能经过”，比读源码更快。

真正难的不是画出路径，而是理解每个节点是否被跳过、被重定向、或被模块替换（比如 AF_XDP 绕过协议栈，或 XDP 程序直接丢包）。动手前先明确你要验证的是“理论路径”还是“当前生效路径”。