本文详解为何通过 udp 隧道转发的原始 ip 数据包在 tun 接口出站后无法被本地 tcp/udp 应用程序接收，并提供基于双 tun 架构的可靠解决方案，涵盖内核路由、ip 栈处理机制及关键配置要点。

在构建基于 UDP 封装的透明 IP 隧道（如自定义 overlay 网络）时，一个常见却极易被忽视的问题是：解封装后的 IP 数据包虽能成功写入 TUN 接口，却无法触发内核网络栈的上层协议处理（即不交付给监听中的 TCP/UDP socket）。这正是你所遇到的现象——Wireshark 显示数据包结构完整、校验和正确、L3/L4 头部无误，但 netstat -tuln 或 ss -tuln 中监听的服务完全收不到 SYN 或 UDP 报文。

根本原因在于 Linux 内核对 TUN 接口输入数据包的处理路径与常规物理/虚拟接口存在关键差异：

• 当数据包从 AF_PACKET 原始套接字或 AF_INET + SOCK_RAW 读取后，直接 write() 到 TUN 设备时，内核将其视为“来自外部网络”的入向流量（ingress）；
• 此类流量会经过完整的 netfilter（iptables/nftables）、rp_filter（反向路径过滤）、路由查找（ip route input）等流程；
• 最关键的是：若该数据包的目的 IP 地址不属于本机任一接口（包括 loopback），且未启用 ip_forward=1 或路由未导向 lo，内核将静默丢弃它，根本不会进入 tcp_input() 或 udp_queue_rcv_skb()；
• 即使目的 IP 是本机地址（如 192.168.1.2），若 TUN 接口未配置对应 IP（仅作为 L3 tunnel endpoint 存在），内核可能因“无匹配 local route”而拒绝交付——TUN 接口本身不自动拥有 IP，需显式 ip addr add 才能参与 local delivery。

你尝试的 SOCK_RAW + IPPROTO_RAW 方案失败，正是因为该套接字默认将数据包注入 lo 接口（MAC 全零即标志 loopback），但内核对 lo 的校验更严格：要求源 IP 必须是 127.0.0.0/8 或本机有效地址，且需通过 rp_filter 检查；而隧道解封装包的源 IP 往往是远端真实地址（非 127.0.0.1），导致被 lo 的 ingress 过滤逻辑拦截。

✅ 正确解法：使用双 TUN 架构，让解封装流量经由内核标准 L3 路由路径闭环

原理是：将解封装后的原始 IP 包（不含以太网头）写入一个已配置 IP 地址的 TUN 接口（如 tun0），并确保其目的 IP 属于本机子网；内核会像处理物理网卡收到的包一样，执行 ip_route_input() → local_delivery → 协议分发。

以下是可立即部署的接收端修复代码（替代原 socket + tun.write() 方案）：

# 接收端：UDP 解封装 → 写入已配 IP 的 TUN 接口（tun0）
import os, struct, socket, fcntl

# 1. 创建并配置 tun0（需提前执行或在此处调用 ioctl）
#    ip tuntap add mode tun dev tun0
#    ip addr add 10.0.0.1/24 dev tun0
#    ip link set tun0 up

tun_fd = os.open("/dev/net/tun", os.O_RDWR)
ifr = struct.pack("16sH", b"tun0", 0x0001 | 0x1000)  # IFF_TUN | IFF_NO_PI
fcntl.ioctl(tun_fd, 0x400454CA, ifr)  # TUNSETIFF

# 2. 绑定 UDP 接收
udp_sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
udp_sock.bind(("192.168.1.2", 5556))

print("UDP tunnel receiver ready on 192.168.1.2:5556")
while True:
    packet, _ = udp_sock.recvfrom(65535)
    # 剥离原始以太网头（若发送端加了）→ 保留纯 IP 包（IPv4 header + payload）
    ip_packet = packet[14:] if len(packet) > 14 and packet[12:14] == b'\x08\x00' else packet

    # 写入 tun0 —— 内核将按标准流程处理此 IP 包
    os.write(tun_fd, ip_packet)

? 关键前提配置（执行一次）：

# 创建 tun0 并分配属于本机的 IP（必须！）
sudo ip tuntap add mode tun dev tun0
sudo ip addr add 10.0.0.1/24 dev tun0  # 或任意本机可达子网
sudo ip link set tun0 up

# 关闭反向路径过滤（避免因源 IP 不匹配被丢弃）
echo 0 | sudo tee /proc/sys/net/ipv4/conf/tun0/rp_filter
echo 0 | sudo tee /proc/sys/net/ipv4/conf/all/rp_filter

# 确保 IP 转发开启（即使本机终结，某些路径仍需）
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

⚠️ 注意事项：

• 发送端 dummy1 接口需确保捕获的是去往本机协议栈的流量（如目标为 192.168.1.2 的 TCP 连接），而非转发流量；
• 若隧道需双向通信，发送端也应使用 TUN 接口（而非 AF_PACKET）捕获 tun0 出向包，再 UDP 封装；
• 所有涉及的 IP 子网（如 10.0.0.0/24）必须在两端路由表中明确可达，建议用 ip route show table local 验证 local route 是否包含目的地址；
• 使用 tcpdump -i tun0 -nn 可验证包是否成功进入 tun0；用 ss -tuln 和 tcpdump -i lo port 可确认上层交付是否生效。

总结：TUN 接口不是“万能数据管道”，其行为严格受内核网络栈控制。绕过协议栈（raw socket）或错误假设 TUN 输入即等于本地交付，是此类问题的根源。唯一健壮方案是让解封装包走标准 IP 输入路径——即写入一个已配置、可路由的 TUN 接口，并确保其目的 IP 被内核识别为 local。