ターン：オリジナル：https://www.cnblogs.com/wyzhou/p/9286864.html
-------------------------------------------------- -----
TUN / TAP仮想ネットワークデバイスは、ユーザ空間プログラムにネットワークパケットを送受信する機能を提供します。彼がポイント機器（TUN）として、イーサネット（登録商標）デバイス（TAP）としても使用することができるいずれか。
TUN / TAP仮想ネットワークデバイスの動作：
TUN / TAPドライバ、さらにはキャラクターデバイス/ dev /ネット/ TUNに関連付けられた仮想ネットワークデバイス、Linuxカーネル内の文字デバイスユーザー空間とカーネル空間データ交換インターフェースとしてTUNを追加します。カーネルが仮想ネットワークデバイスにパケットを送信すると、ユーザプログラムは、オープンスペースのキャラクタデバイスTUNの記述を読んするまで、パケットは、装置に関連付けられたキューに格納され、それがユーザ空間にコピーされます効果に相当するバッファは、パケットをユーザ空間へ直接送られます。システムコールを介してパケットを送信するときの原則は、書き込みに似ています。
1、tunデバイス
TUNデバイスは、仮想ネットワークデバイスで、このデバイスは、プログラムが簡単にネットワークの挙動をシミュレートすることができます。
TUNのシミュレーションでは、我々はIPパケットを処理することができ、それを通して、ネットワーク層、言うために、より人気のものからのデータを処理することができ、それを通して、ある3層デバイスです。
物理デバイスがどのように機能するかで見てみましょう：
図eth0が既存の実際のネットワークインタフェース（インタフェース）のホストです。
ネットワークケーブル（ワイヤ）と外部ネットワークを介して接続された実際のカード、ネットワークインターフェースeth0を表し、物理的なNICは、パケット・ネットワーク・プロトコル・スタックは、カーネル（ネットワークスタック）にインターフェースeth0を介して転送され受信します。その後、さらなる処理のためのプロトコルスタックにこれらのパケット。
いくつかの誤ったデータパケットを、プロトコルスタックは、廃棄されるように選択することができます。
マシンが現在のデータパケットの一部ではない、プロトコルスタックは、転送を選択してもよいです。
データパケットの送信に関しては確かに機械であり、パケットが実際に上位アプリケーションに要求される、プロトコルスタックは、上位アプリケーションは、ソケットAPIを介して待ってお知らせいたします。
見てみましょうのTUNの作品：
我们知道，普通的网卡是通过网线来收发数据包的话，而 TUN 设备比较特殊，它通过一个设备文件（/dev/tunX）收发数据包。
如上图所示，tunX 和上面的 eth0 在逻辑上面是等价的， tunX 也代表了一个网络接口，虽然这个接口是系统通过软件所模拟出来的。
网卡接口 tunX 所代表的虚拟网卡通过文件 /dev/tunX 与我们的应用程序(App) 相连，应用程序每次使用 write 之类的系统调用将数据写入该文件，这些数据会以网络层数据包的形式，通过该虚拟网卡，经由网络接口 tunX 传递给网络协议栈。
同时该应用程序也可以通过 read 之类的系统调用，经由文件 /dev/tunX 读取到协议栈向 tunX 传递的所有数据包。
协议栈可以像操纵普通网卡一样来操纵 tunX 所代表的虚拟网卡：
比如，给 tunX 设定 IP 地址，设置路由，总之，在协议栈看来，tunX 所代表的网卡和其他普通的网卡区别不大，当然，硬要说区别，那还是有的，那就是 tunX 设备不存在 MAC 地址，这个很好理解，tunX 只模拟到了网络层，要 MAC地址没有任何意义。
如果是 tapX 的话，在协议栈的眼中，tapX 和真是网卡没有任何区别！！！！
示例：
Tun/Tap都是虚拟网卡，没有直接映射到物理网卡，是一种纯软件的实现。Tun是三层虚拟设备，能够处理三层即IP包，Tap是二层设备，能处理链路层网络包如以太网包。使用虚拟网络设备，可以实现隧道，如OpenVPN的实现。
上面的图中，左右两边分别为两台机器。一台有一块物理网卡配置了IP：172.16.1.11，这台机器的系统里有一个Tun(以Tun为例，不讲Tap了)设备，配置了IP：192.168.1.11; 另一台的一块物理网卡配置了IP：172.16.1.12，系统里有一个Tun设备并配置了IP：192.168.1.12。
左边Linux系统里有一个Application，绑定到端口地址为： 192.168.1.11:5000，右边Linux也有一个Application，绑定到端口地址为：192.168.1.12:5000，显然它们绑定的都是Tun设备的IP，接着它们就通过这两个地址通信了。
假设左边的Application要给右边的Application发送一个数据包，流程是这样的：
左边的Application并不知道什么虚拟网络设备，它只知道往"192.168.1.12:5000"这个地址发送，左边主机系统首先按正常的发包过程处理，比如判断目的主机是不是位于同一网段等等，然后数据包就在Linux的网络协议栈中穿行。Tun设备并不是真实的物理网卡，它不知道把数据包往哪里送，但是这些经过了Linux网络协议栈的数据可以从Tun设备的文件描述符中读取到，图中的“User Program”就是监听这个描述符等待读取数据的。这个“User Program”程序绑定的端口地址是：172.16.1.11:6000，每当它从Tun设备读到数据的时候，就把这些数据从物理网卡发送出去，目标地址是右边的：172.168.1.12:6000。
数据到达右边的系统，经过网络协议栈之后到达“User Program”应用进程，“User Program”将接收到的数据往Tun设备对应的文件描述符写入。对于Tun设备来说，“写入”就像是物理网卡接受到数据包一样，因此这些接收到的数据又进入了Linux的网络协议栈，最终到达右边的Application。
这里的Application是指各种各样的用户程序，如ping工具。“User Program”是用来辅助Tun设备来实现隧道功能的，可以想象成是OpenVPN进程，没有它隧道就废了！！！！
2、TAP设备
如图所示，当备一个 TAP 设被创建时，在 Linux 设备文件目录下将会生成一个对应 char 设备，用户程序可以像打开普通文件一样打开这个文件进行读写。
当执行write()操作时，数据进入 TAP 设备，此时对于 Linux 网络层来说，相当于 TAP 设备收到了一包数据，请求内核接受它，如同普通的物理网卡从外界收到一包数据一样，不同的是其实数据来自 Linux 上的一个用户程序。Linux 收到此数据后将根据网络配置进行后续处理，从而完成了用户程序向 Linux 内核网络层注入数据的功能。
当用户程序执行read()请求时，相当于向内核查询 TAP 设备上是否有需要被发送出去的数据，有的话取出到用户程序里，完成 TAP 设备的发送数据功能。
针对 TAP 设备的一个形象的比喻是：
使用 TAP 设备的应用程序相当于另外一台计算机，TAP 设备是本机的一个网卡，他们之间相互连接。应用程序通过 read()/write()操作，和本机网络核心进行通讯。
TAP 设备与 TUN 设备工作方式完全相同，区别在于：
1）TUN 设备是点对点的三层设备，处理IP分组，它只模拟到了 IP 层，即网络层 我们可以通过 /dev/tunX 文件收发 IP 层数据包，它无法与物理网卡做 bridge，但是可以通过三层交换（如 ip_forward）与物理网卡连通。可以使用ifconfig等命令给该设备设定 IP 地址。
2）TAP 设备是一个二层虚拟以太网设备，处理以太网帧，它比 TUN 更加深入，通过 /dev/tapX 文件可以收发 MAC 层数据包，即数据链路层，拥有 MAC 层功能，可以与物理网卡做 bridge，支持 MAC 层广播。同样的，我们也可以通过ifconfig等命令给该设备设定 IP 地址，还可以给它设定 MAC 地址。
3）
TAP：子网掩码是/24，255.255.255.0，对应以太网设备
TUN：子网掩码是/30，255.255.255.252，点对点设备。
4）设备节点号不同：
2.4的核：TUN 设备号是36 16+，文件节点：/dev/tun0
2.6的核：TUN 设备号是10 200，文件节点：/dev/net/tun
OSI模型中的七层：
第一层是物理层
第二层是数据链路层（tap设备）
第三层是网络层（tun设备）
第四层是传输层
第五层是会话层
第六层是表示层
第七层是应用层
3、VETH
VETH 设备出现较早，它的作用是反转通讯数据的方向，需要发送的数据会被转换成需要收到的数据，重新送入内核网络层进行处理，从而间接的完成数据的注入。
VETH 设备总是成对出现，送到一端请求发送的数据总是从另一端以请求接受的形式出现。
该设备不能被用户程序直接操作，但使用起来比较简单。创建并配置正确后，向其一端输入数据，VETH 会改变数据的方向并将其送入内核网络核心，完成数据的注入。在另一端能读到此数据
veth、tun、tap比对
