如果你做过网络相关的开发大概率遇到过这种场景执行ip link时机器上莫名其妙多出好几个没有硬件对应的网络设备——物理网卡明明只有一两块列表里却躺着好几个带数字编号的接口有容器带来的有虚拟机带来的偶尔还有几个名字里带tun或tap字样的家伙。我第一次见到 TUN/TAP 时也带着同样的疑惑一个没有插网线的“网卡”到底有什么用后来折腾了好几个晚上才算真正理解这类虚拟网络设备解决的核心问题是让用户态程序能够变成一块“网卡”直接接入内核网络协议栈的收发链路中。这篇文章不打算讲太深的内核源码而是想把 TUN/TAP 的来龙去脉、工作原理、实际落地场景和常见坑讲清楚。适合两类读者一类是刚接触容器、虚拟机网络看到一堆陌生网络设备就头疼的开发者另一类是想写用户态网络程序却不知道程序究竟该怎么“碰”到内核网络栈的人。读完你至少能回答三个问题TUN 和 TAP 到底差在哪它们在真实世界里被谁用着如果自己动手写一个用户态网卡链路该怎么走通1. 从物理网卡到虚拟设备一次对“网卡”概念的重新理解1.1 物理网卡收发数据的链路是怎么走的要理解虚拟网络设备先把物理网卡的工作链路捋一遍。一块普通的以太网卡数据从网线进来后先经过 PHY 芯片完成电平转换再由 MAC 控制器把比特流组装成帧通过 DMA 写入内存中的环形缓冲区。内核驱动拿到这些sk_buff后把它交给协议栈做 IP 解析、TCP 解包最后才把数据放到某个 socket 的接收队列里等应用程序来读。发送方向正好反过来应用程序通过 socket 写入数据协议栈完成路由、分片、封装然后把包交给网卡驱动驱动再通过 DMA 把数据搬到网卡的发送队列最终变成网线上的电信号。这条链路有个关键特征内核拥有通往硬件的唯一通道。普通应用程序只能站在协议栈顶部的 socket 这一端根本没有机会把自己“塞进”硬件和协议栈之间。如果你只是写个客户端、服务端程序这个模型完全够用了可一旦你想做一些更底层的事情比如自己实现一套组网协议、要把某个网段的流量全部截下来做审计、或者让一台虚拟机像插了真实网线一样接入现有网络单靠 socket 是做不到的。1.2 普通应用程序为什么“接不进”内核网络栈有人可能会说我可以用原始套接字啊SOCK_RAW不是能读到 IP 包吗确实原始套接字可以收发指定协议号的报文也可以从数据链路层把帧抓下来。但它本质上是一个“旁观者”——数据已经经过了网卡驱动和协议栈你只是在一个观察点在旁边复制了一份来看。你没法让自己成为协议栈路由决策中的一个合法输出口也没法让内核把发给某个接口的包“直接交给你处理”。还有人会想到 netfilter 钩子也就是 iptables 那一套。它确实可以在内核里拦截、修改网络层包但那是内核态的工作开发、调试链路都比较重而且它依附在协议栈的处理流程上并不是一个独立的网络接口。如果哪天你想在用户态做一个可以随时启停、自然参与路由和 ARP 的“软网卡”常规手段全都差点意思。1.3 TUN/TAP 把内核协议栈的一头“交”给用户程序TUN/TAP 就是专门为这个需求设计的。它的思路很直接内核创建一种特殊的网络设备这个设备的数据面逻辑完全空出来一端连着内核协议栈另一端以一个文件描述符的形式交给用户态程序。当你创建一个tun0并配上地址、路由之后内核在正常组网过程中会把应该从tun0发出的包“交给”这个设备。此时只要你的程序持有这个设备对应的 fd数据就会像水流一样落到 fd 上被你read()到。反过来你的程序往这个 fd 里write()一段网络层数据内核会认为这块虚拟网卡刚刚从外部“收到”了一个包于是按照正常流程做路由、交给本地协议栈或者继续转发。用生活化的比喻来形容物理网卡是内核和外部世界之间的大门门卫是内核驱动TUN/TAP 则是一扇由你的用户态程序扮演门卫的偏门。信使数据包既可以从大门进来也可以从这个偏门进来内核不关心入口是哪扇门只知道路由规则说“这个包该从这扇门走”。这个设计解决了“用户态程序如何接入内核网络栈”的根本问题——不需要碰内核源码不需要处理硬件中断你的程序只需要读写一个文件描述符就相当于接管了一块网卡的全部数据收发工作。TUN/TAP 系列虚拟设备之所以被广泛应用核心原因就在这。2. TUN 与 TAP 到底差在哪一层三层报文与二层帧的分工TUN和TAP经常被连在一起说仿佛它们是同一种东西的两种叫法实际上两者处理的数据单元完全不同适用的场景也大相径庭。2.1 TUN点对点的三层设备TUN 设备工作在第三层也就是网络层。它传递的数据单元是 IP 包不包含以太网头没有 MAC 地址也不需要处理任何 ARP 逻辑。你在用户态从 TUN 设备的 fd 读到的第一个字节就是一个 IPv4 头的版本号字段你写回 fd 的也必须是一个完整的 IP 报文。TUN 设备的链路层是点对点的内核路由到该接口的包会直接进入 TUN 设备而不需要像以太网那样去查目标 MAC。这一点非常关键它天然适合“一群人需要互通但彼此不在同一个二层网络里”的场景。你的用户态程序拿到 IP 包之后可以按自己的需求做封装、加密、变换路径再通过其他物理通道送出去收到响应后再把解出来的 IP 包写回 TUN 设备的 fd让内核把它当成一个从虚拟网卡收到的普通报文。2.2 TAP接入二层世界的“软网线”TAP 设备则工作在第二层也就是数据链路层。它传递的是完整的以太网帧目的 MAC、源 MAC、EtherType可能还带着 VLAN 标签。如果给 TAP 设备接上一根虚拟的“网线”对面再挂一个虚拟交换机那么 TAP 的表现和一块真实网卡几乎没区别——能发 ARP 广播、能处理组播、能参与生成树协议。正因为 TAP 能处理二层帧它经常被用来做桥接。比如虚拟机场景中宿主机创建一个 TAP 设备再把它和物理网卡放进同一个虚拟交换机里虚拟机里的网卡发出的帧会从一个“虚拟网口”进去经过虚拟交换机从 TAP 口出来最终以用户的身份到达你的用户态程序。整个过程对二层协议完全透明虚拟机甚至以为自己就插在办公室的交换机上。TAP 的优势是透明代价则是更重的处理负担。以太网帧里多余的头部信息、ARP 广播、生成树报文都会变成你的用户态程序需要处理的数据。在转发路径上承载 TAP 的桥接设备还必须处理广播风暴、MAC 学习这些二层逻辑性能开销通常会比 TUN 高不少。2.3 选型判断什么场景用 TUN / 什么场景用 TAP维度TUNTAP通信层级L3 网络层L2 数据链路层数据单元IP 数据包以太网帧是否需要 MAC/ARP不需要需要点对点是否通常是桥接接入二层网络性能开销相对小相对大典型场景路由型组网、用户态协议栈、三层隧道虚拟机桥接、二层网络仿真我的选择经验很简单如果你要做的是“把 IP 包从这个点到那个点搬过去”无论是做 Overlay 封装、构建自定义路由逻辑还是把流量送到用户态程序做处理选 TUN 就够用如果你追求的是“像插了一根真实网线一样接入现有以太网”需要程序能够收到 ARP、广播帧那就必须选 TAP。另外提醒一点名字里带“TUN”容易让人误以为它已经帮你完成隧道封装工作了——其实 TUN 设备本身不做任何封装真正的封装和解封装逻辑都得由你的用户态程序自己实现。3. 那些你几乎每天都在用的网络功能底层都站着 TUN/TAPTUN/TAP 听起来像一个很底层的冷门机制但它在实际世界里出现频率远比想象中高。只是大多数时候这些能力被封装在更上层的软件里你可能根本没意识到背后有 TUN/TAP 在默默工作。3.1 虚拟机的网卡TAP 桥接链路最典型的例子是虚拟机网络。常见的虚拟机监控器通常不直接把物理网卡分配给某台虚拟机因为物理网卡是有限资源给了其中一台宿主机和其他虚拟机就都没得用了。更稳妥的做法是虚拟机监控器里的用户态 IO 线程创建几个 TAP 设备把每个 TAP 当作一块“虚拟网卡”接入一台虚拟机同时把宿主机上的物理网卡也放进同一个虚拟交换机里。虚拟机里的操作系统发送一个数据包时包会以完整以太网帧的形式出现在 TAP 设备的 fd 上虚拟机监控器的 IO 线程读取这些帧交给虚拟交换机做转发再决定是送去另一个虚拟机、送去用户态网络协议栈还是通过物理网卡发到外部网络。整个链路都是以太网帧虚拟机感受不到自己使用的是虚拟设备因为它一直在二三层协议栈里正常工作。3.2 容器跨主机网络与云网络中的隧道接入容器网络里更容易看到虚拟设备的影子。单个容器通常通过 veth 这样的虚拟以太网对和宿主机相连——veth 是一对像虚拟网线一样的设备数据从一端进、另一端出用来连接不同网络命名空间。但 veth 只在同一台宿主机上有效容器要跨主机通信就必须想办法把容器网段的流量从一台机器搬到另一台机器。比较常见的设计是每个节点创建一组 TUN 设备给它们分配一个特殊网段的地址并把这组地址的路由指到 TUN 设备上。用户的业务流量走到内核路由层时发现目标地址落在 TUN 设备的路由范围内就会把 IP 包送进 TUN。此时节点上的用户态程序从 TUN 的 fd 读到 IP 包把它包装成高层协议报文、通过物理网络发送到远端节点远端节点解包后再把原始 IP 包写回它本地的 TUN 设备这样远端内核就认为有一块虚拟网卡收到了包继续按本地路由交付给目标容器。这就是云网络里“节点上为什么能看到一堆虚拟网卡”的原因那些带数字编号的接口往往就是你正在使用的 Overlay 网络的接入点TUN 设备在宿主机的视野里表现得和真实网卡一样有地址、有路由、有流量统计。3.3 网络仿真与安全实验环境的搭建需要模拟一套网络拓扑做实验时TUN/TAP 也是首选工具。网络模拟器可以用 TAP 设备把仿真拓扑接到真实网络上让模拟路由器和物理网络里的主机互通也可以用 TUN 设备构造自定义协议栈测试某些协议细节。这类场景对二层和三层都有需求做路由协议实验时TUN 就够用因为关注的只是 IP 包的收发路径做交换类实验、想验证二层 VLAN、STP 之类的行为时就需要 TAP 接入让真实的二层帧在虚拟链路里流动。除此之外TUN/TAP 也常被用于协议健壮性测试和异常报文注入——你想给一个系统喂一些正常程序根本不会构造的特殊报文直接在用户态用 TUN 设备拼包、注入比用真实网卡方便得多还不会把生产网络弄得一团糟。3.4 网络监控与访问控制透明拦截的真实路径再来看一种有意思的用法透明拦截。如果你把一个 TUN 设备接入本机路由表把需要监控的网段全部指到 TUN 设备上那么所有匹配该网段的出站 IP 包都会经过你的用户态程序。程序可以对每个包做检查、识别、改写或丢弃再决定是否写回 TUN 设备继续让它走向真实网络。这种方式对上层应用是完全透明的——应用进程以为自己是在正常往一个目标地址发包事实上数据已经悄悄经过了一道由 TUN 设备构成的检查点。流量审计、访问控制、自定义协议识别这类需求用 TUN 设备实现起来比在内核态写 netfilter 模块要简单得多迭代速度也快。需要注意的是TUN 是三层拦截只能看到 IP 包如果你希望连二层帧一起监管比如限制某个 MAC 的 ARP 行为那就要换 TAP 设备来做了。4. 手写一个最小的 TUN 收发链路从字符设备到路由表讲了这么多原理不如直接动手跑通一条最小链路。目标很简单创建一个 TUN 设备让 ping 包能进入你的用户态程序程序把包原样写回ping 就能通。这等于亲手做了一块“回显网卡”整个过程走一遍你对 TUN/TAP 的认知会上一个台阶。4.1 创建 TUN 设备的 C 代码骨架Linux 下的 TUN/TAP 设备由内核的tun模块提供绵体是一个字符设备节点/dev/net/tun。创建设备的核心操作是open()之后调用ioctl(TUNSETIFF)把IFF_TUN或IFF_TAP标志传进去。先用代码把骨架搭起来#include stdio.h #include stdlib.h #include string.h #include unistd.h #include fcntl.h #include sys/ioctl.h #include linux/if.h #include linux/if_tun.h int tun_alloc(char *dev, int flags) { struct ifreq ifr; int fd, err; if ((fd open(/dev/net/tun, O_RDWR)) 0) { perror(open /dev/net/tun); return -1; } memset(ifr, 0, sizeof(ifr)); ifr.ifr_flags flags; if (*dev) { strncpy(ifr.ifr_name, dev, IFNAMSIZ - 1); } if ((err ioctl(fd, TUNSETIFF, ifr)) 0) { perror(ioctl TUNSETIFF); close(fd); return -1; } strcpy(dev, ifr.ifr_name); return fd; } int main(void) { char tun_name[IFNAMSIZ] tun0; int flags IFF_TUN | IFF_NO_PI; int fd tun_alloc(tun_name, flags); if (fd 0) { return 1; } printf(created tun device: %s\n, tun_name); char buf[2048]; while (1) { ssize_t n read(fd, buf, sizeof(buf)); if (n 0) { perror(read); break; } if (n 0) { printf(read %zd bytes, first byte: 0x%02x\n, n, (unsigned char)buf[0]); /* 把包原样写回 TUN 设备让它重新进入内核协议栈 */ write(fd, buf, n); } } close(fd); return 0; }这里有两个细节值得解释。第一个是IFF_NO_PI默认情况下从 TUN 设备读到的每个包前面会带一个 4 字节的“包信息头”Packet Info用于描述包的类型等信息。加了IFF_NO_PI后这个头会被去掉你读到的直接就是纯 IP 包对初学者来说会少很多困惑。第二个是strncpy(ifr.ifr_name, dev, IFNAMSIZ - 1)你可以在TUNSETIFF时指定设备名如果名字被占用或不可用内核可以自动分配一个内核最终的名字会写回ifr_name所以代码最后执行了strcpy(dev, ifr.ifr_name)把实际名字取回来。编译运行需要 root 权限因为创建 TUN 设备需要CAP_NET_ADMIN能力。如果没权限open(/dev/net/tun)可能成功但ioctl(TUNSETIFF)会报Operation not permitted。4.2 把 IP 数据包从用户态送回协议栈代码跑起来之后tun0这个网络接口应该已经出现在系统里了但光创建还不够它还没有地址、没有路由链路也是 down 状态。需要另开一个终端做三件事sudo ip addr add 10.0.0.1/24 dev tun0 sudo ip link set tun0 up sudo sysctl -w net.ipv4.ip_forward1第二步ip link set up是把设备先启用第三步开启内核的 IP 转发是为了后续测试时内核不会因为“目标地址不是本机”而直接把包丢掉。完成这些之后再用另一个终端 ping 一个和tun0同网段但不在本机的地址比如10.0.0.2ping -c 3 10.0.0.2由于本机没有任何接口配置了10.0.0.2路由层发现目标地址在tun0的网段内就会把 ICMP 请求包送进tun0。紧接着你就应该在运行 C 程序的终端里看到类似这样的输出read 98 bytes, first byte: 0x45 read 98 bytes, first byte: 0x45 read 98 bytes, first byte: 0x450x45正是 IPv4 头的版本号和头部长度的组合说明你读到的确实是 IP 包。程序随后把包原样写回 TUN 设备内核收到后认为这是一块网卡刚从“线路”上收了一个包于是按正常协议栈处理回复了 ICMP reply。整个ping能通就等于你亲手实现了一块用户态网卡。这里的方向感最容易搞混从 TUN fd 读取数据等价于内核准备把包发送到虚拟链路上的“发送方向”也就是协议栈往外走的一侧往 TUN fd 写入数据等价于虚拟网卡从线路上收到了包是“接收方向”数据会重新进入内核协议栈。很多新手第一次做 TUN 程序总想着要把内核的包“收进来”再“发出去”结果在 read 和 write 的语义上绕半天。记住上面这句话能省很多时间。4.3 让网络层“听你的话”路由、ARP 与转发开关刚才的测试能通隐约依赖了一个容易忽略的事实TUN 是点对点三层设备它不需要 ARP 就能把包发到对端。如果换成 TAPping 10.0.0.2之前会出现一连串 ARP 请求“who is 10.0.0.2”因为 TAP 是二层设备要先把目标的 MAC 地址解析出来才能构造完整的以太网帧。TUN 没有这个问题它天然绕开了邻居发现只需要路由表把流量引进来。所以配置好一张 TUN 设备后真正决定流量去向的往往不是设备本身而是路由表。ip addr add 10.0.0.1/24 dev tun0只是让内核知道这个网段可以从tun0出去如果业务流量来自其他网段目标地址又不在tun0网段内你还需要用ip route add把相应网段指到tun0。在更复杂的组网里还要考虑策略路由、多路由表、ip rule之类的规则原理都一样让内核认为这块虚拟网卡是到达目标地址的最优路径。另一个开关是ip_forward。如果不开内核收到一个目的地址不是自己的 IP 包就会直接丢弃不会转发给其他接口。在 TUN 场景里很容易踩坑包明明进入了tun0程序也在用户态处理了但你往另一个接口转发时内核要求必须开启转发功能否则数据就断在半路。4.4 用数据包转发验证整个链路如果想再进一步可以改一下程序逻辑不把包原样写回而是先读出来打印 IP 头里的源地址、目的地址再决定是否写回。用tcpdump -i tun0 -n可以同时从系统侧观察tun0上到底有没有包在走这能帮你区分“包到底有没有到达 TUN 设备”和“用户态程序有没有正确处理”这两类问题。验证时要养成一个习惯先小包后大包。运行ping -c 3 -M do -s 1472 10.0.0.2-M do表示不允许分片-s 1472表示 ICMP 载荷大小是 1472 字节算上 IP 头和 ICMP 头正好是标准 MTU 1500 字节。如果小包能通、大包不通基本可以断定是 MTU 的问题这是我们下面要说的第一个大坑。5. 真正能跑起来的 TUN/TAP我踩过的坑和调优记录把链路跑通只是第一步实际用起来你会发现 TUN/TAP 有很多隐性规则。下面这些坑我基本都踩过有些甚至花了好几天才定位到根因写出来希望你能绕开。5.1 MTU 引发的“大包不通、小包正常”最典型的现象是ping小包正常ping -s 1472不正常或者 SSH 偶尔能连上但一执行重操作就卡死。TUN 设备默认 MTU 是 1500但如果你在用户态程序里给 IP 包又套了一层封装——比如标准的 Overlay 封装或者简单的自定义头部——那最终落到物理网卡上的报文就会超过物理链路允许的最大长度导致“需要分片但又不允许分片”的 ICMP 错误。排查方法很简单先ping -M do -s 1472测通不行就逐步缩小比如 1400、1300直到找出临界值。找出之后把 TUN 设备的 MTU 设置成“物理链路 MTU 减去封装开销”的值比如物理链路是 1500封装要占 50 字节那tun0的 MTU 就设成 1450。TCP 流量会有 MSS 协商通常会根据接口 MTU 自动调整分片大小但 UDP 类应用不会惯着你超了就是直接丢。5.2 路由黑洞包进入了 tun0却没人来处理还有种情况很让人摸不着头脑tcpdump -i tun0能抓到包流量统计也在涨但你的用户态程序就是没收到数据或者程序写回了数据但对端毫无反应。这时候要一步步分层排查。第一层看路由ip route get 目标地址能告诉你内核到底把包交给哪个接口。如果交到了别的接口那就是路由配置问题。第二层看转发开关目标地址不在本机时ip_forward0会把包直接丢弃你在用户态自然什么都看不到。第三层看 fd 本身是不是有多个线程在竞争同一个 fd导致某个线程read()被另一个线程抢占又或者read()返回了EAGAIN但你没处理非阻塞模式下的这个返回值。最后一层看校验和虚拟设备没有硬件校验和卸载tcpdump 在某些版本里会显示 checksum 相关的告警这时候要多用-nn关掉名字解析冷静看是不是程序自己改坏了包。一个排查技巧是让程序先做最朴素的 echo也就是读到什么就写回什么。如果 echo 条件下 ping 能通说明链路本身没问题问题出在你的业务逻辑如果 echo 都不通再回头查路由和转发开关。5.3 性能天花板两次拷贝与用户态切换TUN/TAP 本质是字符设备每次收发数据至少要经历两次内核态与用户态的切换加上两次内存拷贝。在普通服务器上单线程处理几十万包每秒是常见量级再往上就会遇到瓶颈。这个性能水平做控制面、做管理通道、做低频的隧道端点都没问题但如果你指望它撑住高带宽数据面那就不现实了。真要追求数据面性能方向通常是绕开内核协议栈这条路用内核旁路的技术把网卡数据直接映射到用户态内存配合轮询模式和多队列来提升吞吐。TUN/TAP 在多队列场景里也有对应的IFF_MULTI_QUEUE标志可以把流量分散到多个 fd 上但它的定位始终是“灵活、可编程、通用”而不是“最高性能”。5.4 多队列与多线程单 fd 并发读写的陷阱既然提到多核多说一句并发的事。很多人一上来就开多个线程试图同时read()同一个 TUN fd 来提升吞吐结果发现性能没涨反而出现乱序、丢包、甚至崩溃。单个 fd 的并发访问需要你自己在用户态做同步内核并不会帮你保证多线程同时读写时的顺序一致性。更合理的做法是先确认这个场景是否真的需要多线程如果只是几百兆以下的流量一个线程加一个事件循环已经完全够用。真要打散到多核可以用IFF_MULTI_QUEUE让内核给 TUN 设备建立多个队列然后对每个队列单独打开 fd再把不同队列绑定到不同 CPU 上配合接收包 steering 机制做负载均衡。这样每个 fd 由固定线程独占读写既避免了锁竞争又可以利用多核。5.5 一点实用调优参数最后分享几个我经常用到的调优参数按需取用别一股脑全开。# 增大 socket 读写缓冲减少 TUN fd 读写时的丢包概率 sysctl -w net.core.rmem_max4194304 sysctl -w net.core.wmem_max4194304 sysctl -w net.core.rmem_default262144 sysctl -w net.core.wmem_default262144 # 开启 IP 转发TUN 场景下基本必须 sysctl -w net.ipv4.ip_forward1 # 如果反向路径过滤把从 TUN 进来的包误判为“非法路由”可以关掉 # 注意只在受信任的实验网络里这么干生产环境要谨慎评估 sysctl -w net.ipv4.conf.all.rp_filter0 sysctl -w net.ipv4.conf.default.rp_filter0rp_filter是一个值得单独说一嘴的坑。它用来做反向路径过滤防止 IP 欺骗但当你用 TUN 构造一些非对称路由路径时内核可能认为“这个包进来的接口不是路由表里对应的出口接口”从而把包当成非法包丢掉。实验室环境里关掉它往往能让数据突然就通了但生产环境关掉前一定要想清楚有没有安全风险。我自己用 TUN/TAP 时间越长越觉得应该把它们当成“把内核协议栈的一端外接出来”的接口而不是普通的网卡。很多配置上的困惑只要回到这个视角去看都会变得很好理解路由表怎么指流量就怎么进fd 怎么读写协议栈就怎么收发。下次你想快速验证一个自定义协议不妨先起一个 TUN 设备写几十行脚本做一次收包、改包、回包把内核的 TCP/IP 栈全部复用起来比自己造一套协议栈省太多事了。