Linux tun/tap设备

简介

TUN/TAP设备是一种让用户态程序向内核协议栈注入数据的设备，一个工作在三层，一个工作在二层，使用较多的是TAP设备。VETH设备出现较早，它的作用是反转通讯数据的方向，需要发送的数据会被转换成需要收到的数据重新送入内核网络层进行处理，从而间接的完成数据的注入。

如图所示，当一个TAP设备被创建时，在Linux设备文件目录下将会生成一个对应CHAR设备，用户程序可用像打开普通文件一样打开这个文件进行读写。当执行write()操作时，数据进入TAP设备，此时对于Linux网络层来说，相当于TAP设备收到了一包数据，请求内核接受它，如同普通的物理网卡从外界收到一包数据一样，不同的是其实数据来自Linux上的一个用户程序。

Linux收到此数据后将根据网络配置进行后续处理，从而完成用户程序向内核网络层注入数据的功能。当用户程序执行read请求时，相当于向内核查询TAP设备上是否有需要被发送出去的数据，有的话取出到用户程序里，完成TAP设备的发送数据功能。针对TAP设备的一个形象的比喻是：使用TAP设备的应用程序相当于另外一台计算机，TAP设备是本机的一个网卡，他们之间互相连接。应用程序通过read()/write()操作，和本机网络核心进行通信。

ETH 设备总是成对出现，送到一端请求发送的数据总是从另一端以请求接收的形式出现。该设备不能被用户程序直接操作，但使用起来比较简单。创建并配置正确后，向其一端输入数据，VETH 会改变数据的方向并将其送入内核网络核心，完成数据的注入。在另一端能读到此数据。

这是比较标准的网络流程图，报文从网卡被接收上来，当然这里的网卡是被内核给托管了。 也就是说网卡接收的报文都交给内核进行了处理。

内核收到报文后依次走preRoute，LocalIn将报文进行转发或者发到LocalIn。再到用户态被应用程序进行处理。当然，如果是发送报文的话，那就是将报文走LocalOut，然后如果目的地址是本机就转发到本机，否则走路由，然后postRoute.再进入网卡。

TUN/TAP与物理网卡对比

1. 物理网卡是设备侧与外界系统交互的接口，从物理网卡接收到的数据肯定是来自外部系统的，物理网卡发送的数据肯定是到达外部系统的。
2. TAP/TUN网卡接收到的数据是通过物理网口接收后，又转发到TAP/TUN网卡，此时TAP/TUN网卡相当于一个socket，写入到TAP/TUN网卡的数据由应用程序处理，应用程序处理完成后的数据，继续走网络协议栈，再通过物理网口发送出去。
3. 使用过程中，我们一般会将需要特殊处理的数据流通过理由表项转发到tun/tap口，应用程序处理完后，再重走网络协议栈处理。

数据转发

tun0是一个Tun/Tap虚拟设备，从上图中可以看出它和物理设备eth0的差别，它们的一端虽然都连着协议栈，但另一端不一样，eth0的另一端是物理网络，这个物理网络可能就是一个交换机，而tun0的另一端是一个用户层的程序，协议栈发给tun0的数据包能被这个应用程序读取到，并且应用程序能直接向tun0写数据。

这里假设eth0配置的IP是10.32.0.11 (外网地址)，而tun0配置的IP是192.168.3.11 (内网地址).
下面来看看数据包的流程：

1. 应用程序A是一个普通的程序（比如是一个浏览器想通过vpn访问内网），通过socket A发送了一个数据包，假设这个数据包的目的IP地址是192.168.3.1 （内网地址）
2. socket将这个数据包丢给协议栈
3. 协议栈根据数据包的目的IP地址，匹配本地路由规则，知道这个数据包应该由tun0出去，于是将数据包交给tun0
4. tun0收到数据包之后，发现另一端被进程B打开了，于是将数据包丢给了进程B，实际上是进程B一直在监听tun0对应的socket

5. 进程B收到数据包之后，做一些跟业务相关的处理，然后构造一个新的数据包，将原来的数据包嵌入在新的数据包中，最后通过socket B将数据包转发出去，这时候新数据包的源地址变成了eth0的地址，而目的IP地址变成了一个其它的地址，比如是10.33.0.1.

6. socket B将数据包丢给协议栈

7. 协议栈根据本地路由，发现这个数据包应该要通过eth0发送出去，于是将数据包交给eth0
8. eth0通过物理网络将数据包发送出去。