多次调用bpf_clone_redirect仅向最后一个地址发数据包问题

问题根源 #

连续调用bpf_clone_redirect时，第一次操作会修改原skb的元数据（如输入接口标识、数据包方向标记），导致第一个克隆包在网络栈后续处理中被丢弃——虽然tcpdump能在lo接口抓到包，说明链路层已收到，但上层协议栈因元数据异常拒绝接收，而第二个克隆包基于已修改的skb生成，恰好适配了回环接口的处理逻辑。

修复方案 #

1. 为每个重定向创建独立skb副本 #

不要直接复用原skb多次调用bpf_clone_redirect，而是每次先通过bpf_skb_clone生成干净的副本，再对副本执行重定向：

// 替换原连续调用逻辑的代码
struct __sk_buff *clone1 = bpf_skb_clone(skb, BPF_F_CLONE_MASK);
if (clone1) {
    bpf_clone_redirect(clone1, LO_IFINDEX_1, 0); // LO_IFINDEX_1为第一个回环的接口索引
}

struct __sk_buff *clone2 = bpf_skb_clone(skb, BPF_F_CLONE_MASK);
if (clone2) {
    bpf_clone_redirect(clone2, LO_IFINDEX_2, 0); // LO_IFINDEX_2为第二个回环的接口索引
}

接口索引可通过ip link show命令获取（回环接口通常为lo，多回环则是lo:1等对应的index）。

2. 确认重定向标记参数 #

bpf_clone_redirect的第三个参数（flags）设为0即可，无需额外标记——回环场景下不需要反转数据包方向，BPF_F_INGRESS仅在跨接口转发且需要调整方向时使用。

3. 排查上层过滤规则 #

若修复后仍有问题，检查是否存在iptables/nftables规则过滤回环接口的数据包，或者通过trace-cmd跟踪skb_drop函数，定位第一个克隆包被丢弃的具体环节。

关键说明 #

tcpdump基于链路层抓包，不依赖上层协议栈的校验逻辑，所以能看到所有数据包，但上层协议栈会严格校验skb的skb->dev、skb->pkt_type等元数据。复用原skb多次重定向会污染这些元数据，导致第一个克隆包无法通过校验。通过独立克隆每个skb，能保证每个重定向的数据包都携带原始、正确的元数据，被上层正常接收。

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