搞网络的人，迟早会迎面撞上 TUN/TAP 这两个名字。哪怕你不做内核开发，在虚拟化、容器、软件定义网络的日常里，总会在某个配置文件或者某条启动脚本里看到tun0、tap0的身影。它们看起来像是网卡，又不像物理网卡那样插在机箱上；它们可以接收和发送数据包，但真实的数据通道却直接通向用户态程序。这套设计到底图什么？这篇文章我会从物理网卡的天花板讲起，把 TUN 和 TAP 放在一张图上对比，再带你把 TUN 设备跑起来，亲眼看看报文是怎么从内核协议栈“走”到一个用户程序里的。想深入理解虚拟网络设备、看过很多资料但总觉得隔着一层纸的朋友，这篇文章可以帮你把这层纸捅破。
1. 为什么需要虚拟网络设备，物理网卡到底输在哪
1.1 从一张真实网卡的工作方式说起
先回到最基础的模型。一张物理网卡的本质，是 CPU、内存和外部网络之间的搬运工。数据到达网卡后，PHY 芯片把电信号转成数字帧，MAC 控制器按以太网协议把这个帧收下来，DMA 引擎把它丢进内存里的 ring buffer，接着网卡驱动会向内核注册一个net_device，并把收到的 skb（socket buffer）上交给协议栈。发送方向则是完全反过来，协议栈把待发送的报文交给驱动，驱动写 DMA 描述符，硬件再按照链路层规则把帧发出去。
整个过程本身没什么问题，可一旦你站在虚拟化的视角审视它，就会立刻发现物理网卡有几个绕不开的约束。
第一，物理网卡是稀缺的硬件资源。一台服务器主板上能插的网卡数量有上限，PCIe 通道数量、槽位、功耗都有天花板。而虚拟机一台接一台地跑，容器动辄几十个起步，如果每个网络端点都要占用一块物理网卡，这生意根本做不下去。
第二，物理网卡绑定的是所在物理机的协议栈和网络命名空间。我要在宿主机上隔离出 50 个容器，每个容器都要有自己的 IP、自己的路由表和防火墙规则，物理网卡不可能为每个容器提供一套独立的协议栈视图。
第三，物理网卡只能把报文从“硬件链路”收进来，或者发到“硬件链路”上去。可是在虚拟网络里，很多流量本质上只是内存里的数据拷贝，根本不经过线缆。比如两台虚拟机跑在同一台物理机上，它们之间的通信完全没必要绕到交换机再回来。
所以内核需要一种“长得像网卡、但不依赖真实硬件”的设备。协议栈往这种设备上发包时，报文不会交给 DMA 和 PHY，而是会被直接转送给一个用户态程序，或者一根虚拟管道；反过来，用户态程序往里写入一段数据，内核会把它模拟成一个“刚从网络上收到”的报文，再塞回协议栈。TUN 和 TAP 就是这类虚拟网络设备的代表。
1.2 虚拟网络设备真正解决的三件事
我把实际使用体验总结成三个核心价值，你在后面看应用场景时会反复遇到。
第一点，它把网络端点从硬件上解耦了。虚拟机也好，容器也好，用户态程序也好，只要内核愿意给它分配一个net_device，它就可以拥有自己的地址、路由和链路状态。物理网卡只需要负责最外层的出入流量，其余的网络端点全部在内核内部虚拟完成。
第二点，它打开了“用户态处理网络报文”的大门。物理网卡的报文路径里，用户态程序只能通过 socket 访问经过协议栈处理后的数据，永远拿不到最原始的链路层帧。而 TUN/TAP 设备可以直接把原始报文暴露给用户态程序，你想自己实现协议栈、做内容识别、做流量重组，都不需要改内核模块，一个普通的进程就能接管整条数据通路。
第三点，它让虚拟网络拓扑变得完全由软件编排。你可以把 TAP 设备插进虚拟交换机，可以把 TUN 设备配在某个路由命名空间里，可以随时创建、删除、改名、迁移。物理网络做不到的灵活，在这里都是小事。
打个比方，物理网卡相当于公寓楼的总水表和主管道，每个住户想用水都得走这一条管线。TUN/TAP 则是在每家户内重新布了一套分水管，虽然源头还是那一套供水系统，但每家都有自己的阀门、水表和控制开关。虚拟化环境需要这种“每家一个独立入口”的能力，TUN/TAP 就是内核提供的基础管件。
2. TUN 与 TAP 核心原理拆解：一个在三层，一个在二层
2.1 报文在虚拟设备里走的是哪条路
很多人第一次接触 TUN/TAP 都会困惑：它到底是怎么工作的？你只需要记住一条主线：TUN/TAP 是内核协议栈与用户态程序之间的管道。
以内核视角来看，TUN/TAP 是一个注册在协议栈下的net_device，所以它具备网卡的一切行为特征——可以被 up/down，可以配置 IP，可以进路由表，可以加入 bridge。但这个设备的驱动层并不连接硬件，连接的是/dev/net/tun这个字符设备。用户态程序打开/dev/net/tun，通过 ioctl 告诉内核“我要创建一张 TUN 网卡”或“我要创建一张 TAP 网卡”，之后内核给出一张虚拟出来的tun0或者tap0。
进程往外发包时，如果这条数据包的路由指向tun0，内核协议栈完成路由决策、封装等步骤之后，会把 skb 送到 TUN 驱动。驱动发现这个设备背后有一个用户态程序正在读/dev/net/tun，就把这份报文直接拷贝到设备文件对应的缓冲区里。用户态程序read()从字符设备拿到的，就是完整的数据包。
相反的路径同样简单。用户态程序调用write()，把一段字节流写到/dev/net/tun上，TUN 驱动会用这些字节构造一个 skb，然后调用内核的接收路径接口，把报文“注入”到协议栈里。协议栈完全感知不到这份报文来自一个普通进程，它以为是这张虚拟网卡从外面收到了数据。于是接下来就按正常流程做上送、做转发、做 IP 层处理。
你可以用下面这条链快速理解：
用户态程序 <-> /dev/net/tun <-> TUN/TAP 驱动 <-> 内核协议栈 <-> socket 接口 <-> 进程关键点在于，TUN/TAP 两边都是“真实的网络语义”。协议栈一侧看到的是标准网卡行为，用户态一侧看到的是原始报文流。至于中间数据是不是经过拷贝，那只是性能层面的问题，不影响这整套模型的价值。
2.2 TUN：只认 IP 报文的三层虚拟网卡
TUN 设备被设计成一种点对点（point-to-point）的三层网络设备。它没有 MAC 地址，不参与 ARP，不过问链路层细节。内核在路由层面做完决策后，把 IP 报文交给 TUN 设备；用户态程序从/dev/net/tun上读出来的，也是一段从 IP 头开始的完整 IP 报文。
这带来一个好处：TUN 设备的数据路径很干净。你不需要维护以太网帧头，不需要处理 ARP 请求和广播风暴，只需要关心 IP 层的逻辑。对绝大多数“我要接管路由、我要做三层转发”的场景来说，TUN 是最省心的选择。
但它的限制也在这里。TUN 设备不能直接挂到二层交换机上完成桥接，因为桥接需要二层帧，而 TUN 天生不提供 MAC 层语义。你给tun0配上地址之后，它跟对端之间就是一条纯粹的三层链路，流量在路由表驱动下流入流出。
2.3 TAP：带有 MAC 地址的二层虚拟网卡
TAP 则完整模拟了一张以太网卡。它拥有自己的 MAC 地址，可以处理以太网帧，参与 ARP、组播、广播、以及一切链路层协议。用户态程序从 TAP 设备读出来的字节流，是完整的二层帧：目标 MAC、源 MAC、EtherType、payload、以及可能的 VLAN 标签和 FCS 信息。
正因为 TAP 具备二层的完整性，它最大的用武之地是桥接。你可以把tap0直接加进 Linux bridge，让它和真实网卡处于同一个二层广播域中。一旦加进 bridge，虚拟机和物理机之间就呈现出“同一台交换机上两台主机”的效果：ARP 能找到对方，广播能达，DHCP 也能正常下发。很多虚拟化平台里，虚拟机网卡后端对接的就是 TAP 设备。
代价则是 TAP 带来的开销比 TUN 大，帧更长，还要处理链路层确认、广播、可能的 VLAN 逻辑，而且如果用户态处理不当就会收到一堆 ARP 噪声。所以选 TUN 还是 TAP，本质是选你要处理三层语义还是完整二层语义。
2.4 一张表看懂 TUN 与 TAP 的区别
| 对比项 | TUN | TAP |
|---|---|---|
| 工作层级 | 网络层（L3） | 链路层（L2） |
| 处理的数据单元 | IP 报文（可含更上层头） | 完整以太网帧 |
| 自身 MAC 地址 | 无 | 有 |
| 参与 ARP | 不参与 | 正常参与 |
| 能否加入 Linux Bridge | 不能直接桥接 | 可以直接桥接 |
| 数据流从用户态读到什么 | 从 IP 头开始的报文 | 从目的 MAC 开始的帧 |
| 典型使用方向 | 路由、用户态协议栈、三层隧道 | 虚拟机接入、二层组网、抓包审计 |
| 资源开销 | 略低 | 略高（多一层链路层语义） |
这张表可以陪你快速做技术选型。你只需要分清：你的系统需要看到 IP，还是需要看到整个以太网帧。
3. 这些场景里 TUN/TAP 是幕后主力
3.1 虚拟机与容器网络的“虚拟网线”
我最早接触 TUN/TAP，是因为当时在折腾虚拟化实验。一台 Linux 宿主机要同时跑好几台虚拟机，每个客户机都要有自己的网络接口，宿主机不可能给每台虚拟机都直通一块物理网卡。常见做法是：宿主机创建一个 TAP 设备，然后把这个 TAP 设备传给虚拟机进程；虚拟机进程内部把这块 TAP 当作客户机网卡的“后端”。客户机发送的每个以太网帧，都会从虚拟机内部走到宿主机的用户态进程，再被写入 TAP 设备；此时 TAP 就像一根网线，把客户机和宿主机网络直接连通。
这根“网线”的另一头往哪接，完全由你控制。你可以把它加进 Linux bridge，让虚拟机出现在局域网里，获得一个 192.168.1.x 的地址，跟物理机互相 ping 通；也可以把它放进某个隔离的 bridge，让虚拟机只能访问一个虚拟网络。这套模型到现在依然是许多虚拟化平台的标准网络接入方案。
容器方案里的网络命名空间其实也是同一套理念。虽然容器默认多走 veth 对，但一旦需要 macvlan、ipvlan，或者需要用户态容器网络插件去接管三层转发，TUN/TAP 依然会频繁出现。它可以作为网络命名空间里一个独立的端点，配合路由策略，把流量导进用户态程序做进一步处理，再注入另外的端点。
3.2 网络模拟与实验平台的组网基石
做网络实验的人会特别爱 TAP 设备。假设你手上没有三台真机和一堆交换机，却想验证一个跨节点组网方案是否可行，你可以在同一台 Linux 机器上开三四个网络命名空间，每个命名空间里放一个 TAP 设备，再通过软件交换机把它们桥接成任意拓扑。这时 TAP 对上层网络协议栈来说就是一块真实存在的网卡，跑路由协议、测试生成树、验证二三层互通都没有问题。
这种用法在不少网络模拟软件中也能看到。它们本质上就是在一个模拟器进程里创建大量虚拟网元，背后通过 TAP 设备把报文交给宿主机的 Linux 网络栈。你在 TAP 上抓包，能看到原汁原味的以太网帧，这对验证协议行为、排查二层问题非常有用。一个 TAP 设备配合 tcpdump，基本就是一个可编程的“观察口”。
3.3 用户态协议栈与流量审计
TUN/TAP 真正迷人的地方，是允许普通用户态程序接管网络数据处理能力。以往你想对流量做深层次的处理，要么写内核模块，要么靠 iptables 和 netfilter 钩子。而有了 TUN 设备，你可以把路由表的默认出口指向tun0，之后所有匹配路由的 IP 报文都会进入用户态程序。程序拿到原始 IP 报文，可以先做解析，再决定是记录日志、做格式转换、做内容过滤，或者原封不动地写回 TUN 设备继续转发。
流量审计就是一个经典场景。内部网络把流量通过策略路由导入 TUN 设备，用户态审计程序拿到每一条流的三层报文，统计连接数、识别访问对象、按规则阻断异常连接。整个过程不需要改内核，不需要抢占物理网卡，一个普通进程就能完成全流量观测和策略执行。很多网关类、审计类、SDN 控制器下发策略后的执行组件，底层跑的就是这套“TUN 接管流量”的模型。
同样，如果一段流量协议栈的姿态比较特殊，比如你要测一款自研 IP 协议栈的实现是否正确，TUN 设备就是你最好的测试入口。你可以在用户态构造各种刁钻报文塞进 TUN，内核和协议栈会像收到外来数据一样处理它们，这比拿真实网卡模拟要可控得多。
4. 动手实操：从创建 TUN/TAP 到用 Python 读取报文
4.1 先确认你的环境支持
TUN/TAP 是现代 Linux 内核标配能力，一般发行版的内核都开启了CONFIG_TUN。第一步先确认设备文件存在：
ls -l /dev/net/tun如果不存在，先加载模块再手动创建设备节点：
modprobe tun mkdir -p /dev/net mknod /dev/net/tun c 10 200 chmod 600 /dev/net/tun平时不需要mknod，因为 udev 会在模块加载时自动帮你建好。但如果你在容器里跑，会发现容器内没有/dev/net/tun，这时就需要在容器启动时给它暴露这个设备，并赋予相应的 capabilities。没有 root 权限时操作 TUN/TAP 基本寸步难行，因为创建虚拟网卡需要CAP_NET_ADMIN。开发时最省心的办法就是sudo执行。
4.2 用 ip 命令创建和管理 TUN/TAP
现代 Linux 有ip tuntap命令，比老的tunctl更直观。创建一个 TAP 设备的命令是：
ip tuntap add dev tap0 mode tap user root ip link set tap0 up创建一个 TUN 设备同理，把 mode 换成 tun：
ip tuntap add dev tun0 mode tun user root ip link set tun0 upuser root这个参数表示允许 root 用户后续打开/dev/net/tun后去接管这个设备。如果你要把 tap0 加进网桥，可以这样：
ip link add br0 type bridge ip link set tap0 master br0 ip link set br0 up ip addr add 192.168.100.1/24 dev br0这里我把 TAP 设备挂到 bridgebr0上，给网桥配一个 IP，这样后续只要另一侧的端点地址在 192.168.100.0/24 内，就能和宿主机直接互通。TAP 设备被加入 bridge 后，它本身就变成了一个二层端口，不再单独承担三层转发职责。
删除虚拟设备也很简单：
ip link set tap0 down ip tuntap del dev tap0 mode tap这里有个细节：删除 TUN/TAP 设备时，mode参数要和创建时一致，否则命令会提示找不到对应设备。
4.3 编写一个读取 TUN 报文的 Python 程序
纸上谈兵到这里可以停了，我直接给你一个能跑起来的 Python 示例。这个程序会打开/dev/net/tun，创建一个 TUN 设备，然后循环读取内核交给它的 IP 报文并打印摘要：
import os import fcntl import struct TUNSETIFF = 0x400454CA IFF_TUN = 0x0001 IFF_TAP = 0x0002 IFF_NO_PI = 0x1000 # 打开 tun 设备 tun_fd = os.open("/dev/net/tun", os.O_RDWR) # 构造 ifreq，16字节设备名 + 2字节flags，补齐到 40 字节 # IFF_NO_PI 表示不要4字节的额外包信息头，读出来的直接是IP报文 ifr = struct.pack("16sH", b"tun0", IFF_TUN | IFF_NO_PI) ifr += b"\x00" * (40 - len(ifr)) # 用 ioctl 把 fd 变成 tun0 设备 fcntl.ioctl(tun_fd, TUNSETIFF, ifr) # 配置好网络层：让它 up 并分配地址，这样内核路由表会生成路由 os.system("ip link set tun0 up") os.system("ip addr add 10.0.0.1/24 dev tun0") print("tun0 is up, waiting for packets...") while True: # 从虚拟网卡读取原始IP报文 packet = os.read(tun_fd, 2048) if not packet: continue # 粗略解析IP头 version_ihl = packet[0] protocol = packet[9] src_ip = ".".join(str(b) for b in packet[12:16]) dst_ip = ".".join(str(b) for b in packet[16:20]) print(f"proto={protocol} {src_ip} -> {dst_ip} len={len(packet)}")运行前要给这个 Python 脚本提权，因为创建设备和配置网络都需要权限：
sudo python3 tun_demo.py &然后在另一个终端里，往tun0网段发送一个 ping：
ping -I tun0 10.0.0.2 -c 3这时再看运行脚本的终端，你会看到类似下面的输出：
tun0 is up, waiting for packets... proto=1 10.0.0.1 -> 10.0.0.2 len=84 proto=1 10.0.0.1 -> 10.0.0.2 len=84 proto=1 10.0.0.1 -> 10.0.0.2 len=84proto=1表示 ICMP。你发出的 ping 报文被内核路由到tun0，然后 TUN 驱动把这些报文直接交给你这个用户态程序。程序现在只做了“读出来并打印”，没有回包，所以 ping 不会通。但你应该已经能直观感受到 TUN 设备的工作机制：内核把协议栈处理好的 IP 报文“吐”给了用户态进程。
如果想真正把这条路走通，你可以让程序构造一份 ICMP Echo Reply 写回tun_fd，这样 ping 就能通了。不过那部分代码量会明显增加，建议先把“读报文”跑通，再慢慢往里加转发、过滤和回包逻辑。
4.4 用 tcpdump 直接观察 TUN/TAP 流量
如果你想绕过写代码，直接看 TUN/TAP 设备上的流量，用 tcpdump 是最省事的。以 TUN 为例：
sudo tcpdump -i tun0 -n在另一个终端执行ping -I tun0 10.0.0.2，tcpdump 会打印出 ICMP 报文。这时你会看到 TUN 设备对上层来说完全就是一张网卡，tcpdump 照常工作。TAP 设备也同理：
sudo tcpdump -i tap0 -n观察点不一样：tap0 上能抓到 ARP 请求、广播帧等二层报文，而 tun0 上永远只会有 IP 层和更上层的报文。这个差别抢在抓包阶段就能明显体会到。
5. 踩坑实录：常见问题与排查方法
5.1 ioctl 报 Operation not permitted
创建 TUN/TAP 最常见的报错就是TUNSETIFF: Operation not permitted。原因基本只有一个：当前进程没有CAP_NET_ADMIN权限。普通用户直接操作肯定不行。开发期用sudo最稳妥；如果要在服务里降权运行，可以创建好设备后把设备或整个程序放到对应的 capability 环境里，或者用setcap cap_net_admin+ep赋予脚本对应能力。
另外容器场景里如果提示open /dev/net/tun: No such file or directory，那就不是权限问题，而是容器没暴露这个设备。容器启动时加上类似--device=/dev/net/tun的参数并保留相关 capabilities 即可解决。
5.2 TUN 设备一直收不到包
程序跑起来了，路由也配了，但用户态程序就是读不到任何数据。我踩过几回，经验是优先看三个位置。
第一，确认路由真的指向 TUN 设备。用ip route get 10.0.0.2看一下，如果不走 tun0，而是走 eth0，那数据包根本不会出现在你的程序里。第二，确认 TUN 设备状态是 UP，ip link show tun0如果显示 DOWN，内核不会往这个设备发包。第三，确认程序里有没有丢掉前 4 字节的歧义问题。如果你创建设备时没有设置IFF_NO_PI，用户态读到的每个包前 4 字节是struct tun_pi，包含 flags 和协议类型，必须跳过这 4 字节再解析。很多人一开始没设IFF_NO_PI，然后拿着读出的 4 字节垃圾头当 IP 头解析，当然什么都解析不对。
5.3 MTU 引发的性能与丢包问题
TUN/TAP 设备默认 MTU 一般是 1500 字节，但一旦你在这个虚拟网络上叠加了隧道封装或者 overlay 头部，1500 字节就不够了。假设外层封装要占用 50 字节，内层报文还是按 1500 字节往里放，整包超过链路 MTU，要么分片要么被丢弃，延迟和丢包率都会很难看。
这个时候要主动调小虚拟设备上的 MTU，原则很简单：
虚拟设备 MTU = 底层物理链路 MTU - 隧道/封装头部长度比如物理链路 MTU 是 1500，封装头占 50，那么 TUN 设备 MTU 设成 1450 才合理。命令也顺手：
ip link set tun0 mtu 1450在抓包阶段看到大量fragmented IP报文，别急着怀疑驱动或网卡，先检查一下内层 MTU 和外层 MTU 是不是打架了。
5.4 TUN 设备上 ping 不通对端
配好10.0.0.1/24后，很多人的第一反应是 ping 一下同网段某个地址。如果对端并没有在 TUN 路径上真实响应，你自然会得到“不通”的结果。这个不算故障，但可以反映设计问题：TUN 是三层点对点设备，它不会帮你做二层广播，也不会去回应 ARP。如果你要的是“插上就能和局域网内所有主机互通”，那应该用 TAP 加网桥，而不是 TUN。
如果你确实要用 TUN 做路由转发，记得补路由。比如你知道另一个网段走对端可以到达，就静态指一条：
ip route add 192.168.50.0/24 dev tun0 via 10.0.0.2TUN 设备自己不会凭空生成跨网段路由，这些都得你在用户态程序或路由脚本里设计好。
5.5 写回数据包却没有响应
用户态程序把报文write回/dev/net/tun之后，协议栈会正常收下，但这不意味着网络一定通。常见坑是校验和、长度字段、以及报文到达的内外方向不对。如果你自己构造 IP 报文再写回，必须要保证 IP 头校验和、首部长度、总长度等字段正确；同时写回的数据格式要和创建设备时一致——如果设了IFF_NO_PI，就直接写原始报文；如果没设，还得补 4 字节的tun_pi头。
我自己调试时最笨也最有效的办法，是先把正常 ping 进来的包原封不动地把源目地址对调一下再写回，看看对端能否收到回包。确认通路正常后，再去改报文内容，这样可以把“通路问题”和“报文内容问题”分开。
6. 选型建议：到底该用 TUN 还是 TAP
6.1 一个快速决策表
我在实际项目里总结了一套快速选择的方法，核心是回到你的数据链路需求：
| 需求 | 建议使用的设备 | 原因 |
|---|---|---|
| 只要三层路由互通 | TUN | 不处理 ARP/广播，数据路径短 |
| 虚拟机需要接入二层局域网 | TAP | 需要 MAC 地址参与广播域 |
| 抓取并分析二层帧 | TAP | 能拿到完整以太网帧，包含 ARP |
| 用户态实现 IP 协议栈、做 IP 过滤 | TUN | 业务关心的是 IP 报文，拿二层帧反而是负担 |
| 需要做桥接 | TAP | TUN 无法直接加 bridge |
| 需要支持广播/组播协议 | TAP | TUN 无链路层广播语义 |
| 追求更低开销 | TUN | 省去链路层处理与广播干扰 |
这套表不能解决所有问题，但可以应付绝大多数组网设计。如果你还在犹豫，一个朴素的办法是：先在目标环境里把两种设备都创建出来，然后用 tcpdump 各抓一轮流量，看到真实数据形态后决策通常就清晰了。
6.2 结合场景谈权衡
使用 TUN 时，你享受了简单和干净，但要自己负责路由逻辑。因为 TUN 是三层设备，对方能不能收到你的包，取决于路由表、转发规则、以及用户态程序是否接管并正确转发。对团队来说，当一个方案涉及大量跨网段寻址时，TUN 的架构反而更可控，逻辑都在 IP 层，排查工具链也很成熟（traceroute、ping、路由表）。现实中不少云环境的 overlay 数据面会借用 TUN 模型，正是看中它和 IP 生态无缝融合。
使用 TAP 时，你获得了最完整的二层体验，但也要忍受二层协议带来的噪声。你没做任何广播处理，TAP 设备也会把 ARP、DHCP 广播这些包一股脑交给你。如果不希望用户态程序被这些非业务报文刷屏，得自己在用户态做过滤，或者在内核侧用 ebtables/nftables 提前筛掉一部分。另一个值得注意的点是，TAP 设备加进 bridge 后，它的链路行为完全由 bridge 接管，此时你在 TAP 上配置 IP 并没有实际意义，因为二层转发不会看这个 IP。
6.3 我在实践中的偏好
如果让我给一个保守的实践倾向，我会说：大部分从零开始设计的网络接管程序，优先考虑 TUN。原因是它的语义更窄、更明确，你只需要处理 IP 报文，调试复杂度低一大截；而 TAP 适合当你明确依赖二层特性时使用，比如虚拟机桥接、二层协议实验、以及必须见以太网帧的抓包审计场景。虚拟网络设备的核心价值不在 TUN/TAP 二者谁更强，而在于它们把“网卡”从物理硬件中释放了出来，把网络转交到软件手里。只有亲手在/dev/net/tun上读过几个包，你才能真正理解虚拟网络这盘棋为什么是这么下的。
