一条数据包从虚拟机里发出来，经过一个外观上和 eth0 没有区别、但实际由用户态程序在背后模拟出来的网卡，再进入另一台机器的协议栈——这套机制落到内核里，主角就是 TUN/TAP。做容器网络、虚拟化、SDN 的开发者，迟早都要和这两个名字打交道。这篇文章就把它们讲透：为什么需要虚拟网络设备、TUN 和 TAP 到底差在哪、有哪些绕不开的应用场景，以及我从零创建并打通一条 TUN 链路的完整实操记录。新手看完能直接动手，老手也可以当作速查手册来用。
1. 为什么需要虚拟网络设备：物理网卡的三个边界问题
1.1 物理网卡的硬限制
先想一个问题：一台服务器上物理网卡就那么几块，PCIe 插槽、板载端口都是定死的。可现代业务根本不是这么玩的——一台物理机要跑几十个虚拟机，每个虚拟机都得有一块自己的 eth0；同一个机器上可能要同时做内网互通、流量采集、链路限速，甚至模拟一条断掉的线路。物理网卡数量不够用，转发规则写在硬件里改不动，这是第一个瓶颈。
第二个瓶颈更致命：真实网卡的收发路径被内核协议栈牢牢握住。应用层程序想“看一眼”经过网卡的原始数据包，要么用 AF_PACKET 原始套接字，要么挂 netfilter 钩子，要么改驱动。这些手段要么性能开销大，要么移植性差，要么需要动内核模块。想做点灵活的、应用层可控的网络逻辑，在物理网卡上非常别扭。
第三个瓶颈是隔离。虚拟化场景里，每个虚拟机都想拥有独立网络栈、独立 MAC、独立路由表，但物理网卡只有一个。要把一块物理网卡切出几十个虚拟接口，靠硬件本身做不到。哪怕用 VLAN 也只能做简单的隔离，想模拟“一个完全独立的路由器”依然没戏。
这三个问题指向同一个答案：把网卡本身变成软件，用代码模拟一块能配 IP、能收发报文、能参与路由的虚拟网卡。这就是虚拟网络设备存在的根本理由。
1.2 软件定义网络的破局点：把网卡变成代码
虚拟网络设备的本质，是让你在网络协议栈的“设备层”插入一个由用户态程序控制的入口。它对外表现得和真实网卡一模一样：可以ip addr add配地址，可以进路由表，可以设置 MTU，可以 up/down。但真正收发数据时，数据不是通过网线出去，而是通过文件描述符交给了用户态进程。
这个机制的意义非常深远。你可以把它想象成邮政系统：真实网卡是一条固定的邮路，信件交给邮局后怎么分拣、怎么运输完全不归你管；而虚拟网卡相当于你在自己家开了一个收发室，所有信件到你手里之后，你想拆开看、想重新打包、想贴上别的标签转投他处，都自己说了算。
在用户态程序拿到数据包之后，你可以做的事情包括：
- 原样转发给另一台机器，封装成任何你能想到的格式；
- 解析、过滤、统计，把流量当成数据来审计；
- 修改报文内容再写回网络栈，做网关类的透明拦截；
- 干脆丢到某个加密通道里，实现跨公网的内网互通。
这就是 SDN、叠加网络、容器网络这些概念的技术地基。TUN/TAP 正是把“网卡变成代码”这件事落到内核里的关键设备，所以它在虚拟化网络里是个绕不开的底层角色。
1.3 TUN/TAP 在虚拟网卡家族里的定位
Linux 内核里提供的虚拟设备其实不少，常被拿出来说就有 Veth、Bridge、macvlan、TUN、TAP。很多新手一上来容易搞混。先给一张定位表，后面再展开：
| 设备类型 | 工作层次 | 数据路径 | 典型用途 |
|---|---|---|---|
| TUN | 三层（IP层） | 内核协议栈 ↔ 用户态程序 | 隧道封装、路由实验、自定义网络协议 |
| TAP | 二层（链路层） | 内核协议栈 ↔ 用户态程序 | 桥接、虚拟交换机、流量镜像、捕获分析 |
| Veth | 二层 | 成对出现，一端写入另一端收到 | 容器网络命名空间之间的虚拟接线 |
| Bridge | 二层 | 连接多个虚拟/物理网卡 | 虚拟交换机，让多个网卡共享一个二层域 |
Veth 和 Bridge 都是“内核内部的虚拟接线工具”，数据不离开内核；而 TUN/TAP 是唯一一类直接把报文交到用户态的虚拟设备。弄清楚这个区别之后，很多架构问题就迎刃而解了——容器网络里用 Veth 就够了，因为容器和宿主机在一个内核里；而跨主机的网络隧道要走用户态，那就得上 TUN/TAP。
2. TUN 和 TAP 到底差在哪：一个路由层，一个链路层
2.1 打开 /dev/net/tun 的秘密
TUN 和 TAP 在 Linux 里不是按两个独立模块实现的，而是共用同一个杂项设备/dev/net/tun，主设备号 10，次设备号 200。用户态程序第一次接触 TUN/TAP，通常就是open("/dev/net/tun", O_RDWR)。
但打开这个文件的时候，你并没有拿到一个具体的网卡。你只是拿到了一个“建卡接口”，真正确定自己要 TUN 还是 TAP、要叫什么名字，靠的是下一步的 ioctl：
#include <fcntl.h> #include <sys/ioctl.h> #include <linux/if_tun.h> #include <string.h> int tun_alloc(char *dev, int flags) { struct ifreq ifr; int fd = open("/dev/net/tun", O_RDWR); if (fd < 0) return -1; memset(&ifr, 0, sizeof(ifr)); ifr.ifr_flags = flags; // IFF_TUN 或 IFF_TAP if (*dev) strncpy(ifr.ifr_name, dev, IFNAMSIZ); if (ioctl(fd, TUNSETIFF, &ifr) < 0) { close(fd); return -1; } strcpy(dev, ifr.ifr_name); return fd; }这个函数我每次写网络工具都要用一遍。调用ioctl(fd, TUNSETIFF, &ifr)之后，内核会新建一个虚拟网卡，并把“这张网卡的收发端”绑定到你手里这个 fd 上。之后你对这个 fd 做read()，就能拿到从网卡方向进来的数据包；做write()，就相当于从网卡发出了一个数据包。
需要注意的是，ioctl 里通常会带上IFF_NO_PI标志。加了它，读写时就是纯粹的 IP 包或以太网帧；不加的话，每个包前面还会多出 4 字节的 packet info 头，新手容易在这上面多吃几个小时的苦头。我建议除非你要用 packet info 里的标志位，否则一律加IFF_NO_PI。
2.2 TUN 把 IP 包交给你
TUN 设备工作在第三层，也就是网络层。你从 fd 里读到的，是内核已经处理好协议栈之后、即将“发到网线上”的完整 IP 包；你往 fd 里写一个完整的 IP 包，内核会当作“从这块网卡收到了一个包”，然后交给本机 IP 协议栈处理。
举个例子，假设我创建了一个叫tun0的 TUN 设备，配好地址10.0.0.1/24并启用。这时我执行ping 10.0.0.2，数据包在内核里走的是：
- ping 程序构造 ICMP 报文，交给 TCP/IP 协议栈；
- 路由表匹配到出接口是
tun0； - 协议栈把 IP 包“发送”到这个虚拟网卡；
- 内核发现 tun0 属于 TUN 类型，于是把这个 IP 包通过 fd 交给用户态程序。
如果用户态程序不读，这个包会被丢弃；如果用户态程序读到了，再原样写回同样的 fd，内核就会觉得 tun0 又收到一个包，继续往上送。所以 TUN 设备本质上是在“路由决策之后”和“链路层之前”开了一道用户态的天窗。
2.3 TAP 把以太网帧交给你
TAP 设备工作在第二层，也就是链路层。差别在于：TUN 给你 IP 包，TAP 给你完整的以太网帧——包含源 MAC、目的 MAC、还可能带 VLAN 标签那种。
TAP 的强大之处在于，它让你在用户态模拟一整个二层网络。你可以在上面跑 ARP、跑 STP、跑任何依赖 MAC 地址的协议。最经典的用法是把一个 TAP 设备和一个真实网卡同时加进 Linux Bridge，数据包到达真实网卡后会被桥接逻辑交给 TAP，用户态程序就能“偷窥”到整个二层流量。
相比之下，TUN 设备不关心 MAC 地址，天然不需要处理 ARP。因为 ARP 是链路层协议，三层隧道根本不需要它。这也是为什么做“点对点 IP 隧道”时大家都选 TUN，而做“虚拟交换机”“流量镜像”时必须上 TAP。
2.4 一张表看懂差异
| 对比维度 | TUN | TAP |
|---|---|---|
| 工作层次 | 三层（Network） | 二层（Link） |
| 读写内容 | IP 包 | 以太网帧 |
| 是否处理 ARP | 不需要 | 需要 |
| 与 Bridge 搭配 | 通常不直接搭 | 非常常见 |
| 典型场景 | 隧道、路由、自定义协议 | 虚拟交换、流量捕获、桥接 |
| 数据包体积 | 相对较小 | 多了 14 字节以太网头 |
| 用户态处理负担 | 低 | 略高，需要处理二层逻辑 |
有两个选择经验可以分享：跨主机连通性业务优先考虑 TUN，因为它只关心 IP，不需要处理 MAC 层的广播、ARP；如果你要做的是“把一台物理机变成一台虚拟交换机”，那就用 TAP，因为二层帧才能和 Bridge、VLAN 无缝配合。
3. TUN/TAP 到底被用在哪：几个绕不开的实际场景
3.1 虚拟化和云平台里的虚拟网卡
用过 KVM/QEMU 的朋友应该见过类似启动参数：
-netdev tap,id=net0,ifname=tap0,script=no,downscript=no这里用的就是 TAP 设备。QEMU 创建了一个 TAP 网卡，然后把它桥接到宿主机上的虚拟交换机里，虚拟机里的 eth0 发出的 ARP 请求、IP 包，全部都从 TAP fd 走到了宿主机用户态程序，再被注入到 Bridge。整个过程对虚拟机里的系统来说，就是一块正常的网卡。
虚拟化平台之所以选 TAP 而不是 TUN，是因为虚拟机需要完整的二层语义——虚拟机里要跑 DHCP、要解析 ARP、要和其他虚拟机处于同一个广播域。这一层语义 TUN 给不了，只有 TAP 能做到。
3.2 容器网络那边是怎么处理的
容器网络常被拿来和虚拟机网络对比，但这里有个容易搞错的地方：Docker 默认的 Bridge 网络，用的不是 TUN/TAP，而是 Veth。Veth 是一对虚拟网线，一端放在容器命名空间里，一端放在宿主机网桥上。因为容器和宿主机共享同一个内核，数据在 Veth 对之间直接转发，根本不需要经过用户态。
那 TUN/TAP 在容器世界里还有位置吗？有，而且很重要。一旦涉及“跨主机”的容器网络，比如自研 CNI 插件、构建 Overlay 网络，你就需要把报文从宿主机 A 搬到宿主机 B。Veth 只能在单机内核里搬运数据，跨主机就要靠用户态封装，这时 TUN/TAP 就是最直接的抓手。
一句话总结：Veth 负责“同一台机器里把容器接上线”，TUN/TAP 负责“把网络包送到用户态做跨机器搬运”。各有各的活儿。
3.3 网络模拟、丢包注入与流量审计
我在本地搭实验环境的时候，经常需要模拟“一条时好时坏的链路上跑业务”的场景。真实物理链路很难精准控制丢包和延迟，但配合 TUN 设备加tc netem就很容易：
ip tuntap add dev tun0 mode tun ip addr add 192.0.2.1/30 dev tun0 ip link set tun0 up tc qdisc add dev tun0 root netem loss 10% delay 50ms所有经过 tun0 的包都会在用户态被调校一遍，丢包率、延迟、乱序都能精确模拟。这种可控干扰对测试拥塞控制算法、验证应用超时重试逻辑非常有用。
流量审计和入侵检测场景则更偏爱 TAP。需要“看”网络里的所有二层帧时，把一个 TAP 设备接进旁路镜像口，用户态程序读到的就是最原始的以太网帧。相比给真实网卡挂tcpdump，TAP 的方式更容易灵活处理报文，也方便做多路分析管道。
3.4 隧道与叠加网络的底层地基
TUN/TAP 最广为人知的应用，大概是各种隧道工具的内核地基。这个技术方向本身是中性的：把本机的 IP 包封装进 UDP、TCP 或者其他自定义协议，送到对端主机后再解封装注入回对端内核网络栈。
我举一个完全在自有主机之间进行组网的例子：公司有两台分别部署在两个机房里的 Linux 服务器，你想让它们像连在同一台交换机上一样互通。可以在 A 机和 B 机各自创建一个 TUN 设备，各写一个小用户态程序：
- 从本地 TUN fd 读到 IP 包，封装成 UDP 报文发到对端；
- 收到对端的 UDP 报文，解封装成 IP 包写进本地 TUN fd。
这样两端的 TUN 设备就组成了一条三层链路，原本互相隔离的两个机房内网就此打通。如果再在封装里加上加密和认证，那就是一套功能完整的加密通道——很多开源隧道工具的核心思路都是这个。生产项目不会自己去把加密、重传、密钥交换全部重造一遍，但理解了 TUN 在这里的位置，你再看任何隧道工具的架构文档都会顺畅很多。
4. 动手实操：从零创建并打通一条 TUN 链路
4.1 先检查环境和权限
TUN/TAP 是内核模块，大多数 Linux 发行版默认编译为模块或者直接编译进内核。动手前先确认：
ls -l /dev/net/tun正常情况下能看到一个字符设备/dev/net/tun，主设备号 10，次设备号 200。如果不存在，手动创建一下：
sudo mkdir -p /dev/net sudo mknod /dev/net/tun c 10 200 sudo modprobe tun权限是另一个大坑。创建 TUN/TAP 设备需要CAP_NET_ADMIN能力。在普通 Linux 主机上最简单的方式是sudo执行；如果是在 Docker 容器里，则必须加上相应 capability：
docker run --cap-add NET_ADMIN --device /dev/net/tun ...我在容器里调试 TUN 设备时经常一上来就遇到Operation not permitted，十次里有八次是忘了带这两个参数。
4.2 用一条命令创建 TUN 设备
现代 Linux 用ip命令就能直接管理 TUN/TAP，不必再装老旧的tunctl：
sudo ip tuntap add dev tun0 mode tun sudo ip addr add 10.0.0.1/24 dev tun0 sudo ip link set tun0 up三条命令之后，tun0就是一个正经的、可用的三层网卡。你可以执行ip addr show tun0看到它，也可以ping 10.0.0.2，但此时不会有任何回包——因为没有用户态程序在另一端处理数据。你 ping 出去的包会被内核想办法交到用户态，但没人接收，直接丢掉。
删除设备用：
sudo ip tuntap del dev tun0 mode tun4.3 最小读写程序：亲眼看看数据进 TUN
下面这个 Python 脚本是我每次验证环境都会跑的“最小抓包器”。它打开 tun0，把里面流过的 IP 包解析出协议号、源地址、目的地址打印出来：
import os import fcntl import struct import socket import select TUNSETIFF = 0x400454ca IFF_TUN = 0x0001 IFF_NO_PI = 0x1000 def open_tun(name): fd = os.open("/dev/net/tun", os.O_RDWR) ifr = struct.pack("16sH", name.encode()[:15], IFF_TUN | IFF_NO_PI) fcntl.ioctl(fd, TUNSETIFF, ifr) return fd def parse_ip(pkt): if len(pkt) < 20: return None ihl = (pkt[0] & 0x0f) * 4 proto = pkt[9] src = socket.inet_ntoa(pkt[12:16]) dst = socket.inet_ntoa(pkt[16:20]) return proto, src, dst def main(): fd = open_tun("tun0") print("tun0 ready, fd =", fd) while True: ready, _, _ = select.select([fd], [], [], 1.0) if not ready: continue pkt = os.read(fd, 2048) info = parse_ip(pkt) if info: print("len=%d proto=%d %s -> %s" % (len(pkt), info[0], info[1], info[2])) if __name__ == "__main__": main()用 root 权限跑起来之后，另开一个终端：
ping -c 3 10.0.0.2脚本里就会打出len=84 proto=1 10.0.0.1 -> 10.0.0.2。proto=1 就是 ICMP，也就是 ping 的包。看到这行输出，TUN 设备的用户态链路就算通了。
4.4 两台主机之间的封装转发 Demo
单机验证完，我们来点真正有价值的东西：用 UDP 封装，把一台主机的 TUN 流量转发到另一台主机。两台主机各自运行同一份 Python 脚本，假设 A 机 IP 是 192.0.2.10，B 机 IP 是 192.0.2.20，两边各建 tun0 并配好 10.0.0.1/24 和 10.0.0.2/24：
import os import fcntl import struct import socket import select TUNSETIFF = 0x400454ca IFF_TUN = 0x0001 IFF_NO_PI = 0x1000 def open_tun(name): fd = os.open("/dev/net/tun", os.O_RDWR) ifr = struct.pack("16sH", name.encode()[:15], IFF_TUN | IFF_NO_PI) fcntl.ioctl(fd, TUNSETIFF, ifr) return fd def main(tun_name, local_udp_port, peer_ip, peer_udp_port): tun_fd = open_tun(tun_name) udp_fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) udp_fd.bind(("0.0.0.0", local_udp_port)) print("relay ready, tun=%s udp=%d -> %s:%d" % (tun_name, local_udp_port, peer_ip, peer_udp_port)) while True: ready, _, _ = select.select([tun_fd, udp_fd], [], [], 1.0) if tun_fd in ready: pkt = os.read(tun_fd, 2048) udp_fd.sendto(pkt, (peer_ip, peer_udp_port)) print("tun -> udp: %d bytes" % len(pkt)) if udp_fd in ready: pkt, addr = udp_fd.recvfrom(2048) os.write(tun_fd, pkt) print("udp -> tun: %d bytes" % len(pkt)) if __name__ == "__main__": import sys main(sys.argv[1], int(sys.argv[2]), sys.argv[3], int(sys.argv[4]))A 机上执行：
python3 relay.py tun0 7000 192.0.2.20 7000B 机上执行：
python3 relay.py tun0 7000 192.0.2.10 7000然后在 A 机ping 10.0.0.2，B 机的 tun0 就会收到这个 ICMP 包并交给协议栈，协议栈发现目标地址是自身，于是产生回包。一个最小封装的跨主机三层链路就通了。
这段代码刻意去掉了加密、认证、粘包处理，真实项目不要去生产环境这么裸跑，但作为理解 TUN 转发原理的 Demo 非常合适。
4.5 抓包验证和 MTU 调整
链路跑通之后，用抓包工具验证是最直观的：
sudo tcpdump -i tun0 -nn你会看到10.0.0.1 > 10.0.0.2: ICMP echo request，这就证明数据确实从 tun0 走了。如果换成抓外层物理网卡，还会看到这些 ICMP 被包进了 UDP 报文里，这正是“封装”二字的直观含义。
这里有个非常关键的参数调整经验：TUN 设备默认 MTU 是 1500，但我用 UDP 封装后，外层又多了一层 IP 头（20 字节）和 UDP 头（8 字节）。如果内层包刚好是 1500 字节，加上外层 28 字节就超过了物理链路 MTU，会导致分片，分片在某些网络环境里会被丢弃，表现出来就是“小包通、大包不通”。解决办法是把 TUN 设备的 MTU 调到 1400 左右：
sudo ip link set dev tun0 mtu 1400很多隧道工具让你手动调 MTU 不是没事找事，就是在治这个病。容器网络里 VXLAN 要把 MTU 设成 1450，也是同一个道理。
5. 常见问题与排查技巧实录
5.1 /dev/net/tun 打不开的三种原因
| 现象 | 原因 | 解决方法 |
|---|---|---|
No such file or directory | tun 模块未加载或设备节点未创建 | modprobe tun，mknod /dev/net/tun c 10 200 |
Operation not permitted | 当前用户缺少CAP_NET_ADMIN能力 | 加sudo，容器里加--cap-add NET_ADMIN |
| 虚拟机里无法使用 | 宿主超管理器未开启嵌套虚拟化 | 检查虚拟化设置，或在物理机/有权容器里测试 |
这个设备节点是全局共享的，只创建一次就行。真正创建具体 TUN/TAP 接口靠的是 ioctl，而不是重复 mknod。
5.2 用户态程序一退出，设备就不见了
TUN/TAP 有两种创建方式，很多人在这里被绕晕：
- 用
ioctl(TUNSETIFF)让用户态程序创建设备，如果没设置IFF_PERSIST标志，程序结束时设备会被内核回收； - 用
ip tuntap add预先创建设备，设备本身和用户态程序没有生命周期绑定，程序退出后接口还在，但数据没人读，自然就只是“挂着”。
我调试时更习惯先用ip tuntap add把设备建好，再跑用户态程序，这样程序崩溃了设备不会跟着消失，方便排查。
5.3 tun 通了但上层服务不通，怎么排查
如果ping能通，但 TCP 服务不通，按这个顺序排查：
ip addr show tun0确认 IP、掩码没问题；ip route get <对端IP>确认路由指向 tun0，而不是被默认路由截走；tcpdump -i tun0 -nn看 TCP 握手包是否真的进出 tun0；- 检查 MTU，大包场景直接调低到 1400 再试；
- 如果用了 TAP 还要重点查 ARP 表，TAP 要能正常收发 ARP 请求与响应。
我遇到最多的情况不是封装逻辑写错，而是路由被系统默认路由抢先了。记住一句话：TUN 设备只处理内核明确路由给它的包，不是所有包都会自动走它。
5.4 写回环路：新手最隐蔽的 Bug
有个行为特别坑：用户态程序从 TUN fd 读到一个包，如果没想清楚就原样write回同一个 fd，内核会认为“从这块网卡收到了一个新包”，再次交给用户态程序。于是程序又读到一个包，又写回，无限循环，CPU 直接飙满。
这不是写回操作本身非法，而是“读出来再写回同一个设备”构成了环路。如果你想要的是转发，应该写到别的 fd（比如 UDP socket、另一个 TUN fd、真实网卡 fd），而不是原路返回。如果只是做流量分析，读完就丢，绝不写回。这个教训我是在一次调试流量分析工具时踩进去的，日志刷屏刷了几万行才反应过来。
5.5 性能、多队列与后续扩展
单队列 TUN 设备在大量小包场景下很容易成为瓶颈，因为所有包都挤在一个 fd 上，用户态只有一个线程在read。内核支持为 TUN/TAP 开启多队列：
ip tuntap add dev tun0 mode tun multi_queue开启后，可以用多条 fd 分别绑定到不同队列，用户态多线程并行读取，吞吐量会好不少。但多队列也意味着用户态要处理多路并发、包乱序，复杂度直线上升。
如果只是轻度实验，单队列完全够用。要是想在高性能场景里玩出花，可以关注一下 eBPF/XDP 方向——在那套架构里，数据包可以在内核里直接编写程序处理，TUN/TAP 负责的是把包交到用户态的“最后一段路”。两者不是替代关系，而是互补关系。
我个人在实际操作中的体会是：TUN/TAP 的上手门槛其实不高，核心就是“一个文件描述符”和“两个方向”，但真正理解它，需要亲手跑一遍完整链路——创建、读写、封装、对端注入、抓包验证。走完这一套，你对 Linux 网络栈的掌控感会提升一个台阶。后续如果再写进阶内容，我打算从“基于 TUN 自建可控三层通道的完整工程实现”讲起，把加密、重连、路由策略一个个加进去，那才是真正把 TUN/TAP 的威力完全用起来的样子。
