TUN/TAP虚拟网络设备为用户空间程序提供了网络数据包的发送和接收能力。他既可以当做点对点设备(TUN),也可以当做以太网设备(TAP)。

TUN/TAP虚拟网络设备的原理:

在Linux内核中添加了一个TUN/TAP虚拟网络设备的驱动程序和一个与之相关连的字符设备/dev/net/tun,字符设备tun作为用户空间和内核空间交换数据的接口。当内核将数据包发送到虚拟网络设备时,数据包被保存在设备相关的一个队列中,直到用户空间程序通过打开的字符设备tun的描述符读取时,它才会被拷贝到用户空间的缓冲区中,其效果就相当于,数据包直接发送到了用户空间。通过系统调用write发送数据包时其原理与此类似。

1、tun设备

TUN 设备是一种虚拟网络设备,通过此设备,程序可以方便地模拟网络行为。

TUN 模拟的是一个三层设备,也就是说,通过它可以处理来自网络层的数据,更通俗一点的说,通过它,我们可以处理 IP 数据包。

先来看看物理设备是如何工作的:

图中的 eth0 是主机已有的真实的网卡接口 (interface)。

网卡接口 eth0 所代表的真实网卡通过网线(wire)和外部网络相连,该物理网卡收到的数据包会经由接口 eth0 传递给内核的网络协议栈(Network Stack)。然后协议栈对这些数据包进行进一步的处理。

对于一些错误的数据包,协议栈可以选择丢弃;

对于不属于本机的数据包,协议栈可以选择转发;

而对于确实是传递给本机的数据包,而且该数据包确实被上层的应用所需要,协议栈会通过 Socket 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比对

 

posted on 2018-07-10 01:07  苦咖啡~~  阅读(3468)  评论(1编辑  收藏  举报