写在前面：开源项目VTun短小精悍，涉及到了Linux下网络编程的几乎所有的东西，包括守护程序、信号的处理、服务创建子进程等，实现了虚拟LAN的功能。个人感觉VTun唯一的缺憾是在认证方面，没有基于X509证书，而是简陋的在配置文件进行了密钥的设置。虽然在舍弃CA方面，做到了“轻型化”，但留下来极大的安全隐患，这也限制了它的应用，使得其只适合进行一些实验和测试。
我参考了VTun源代码和麻利辉在ibm的developerworks文章，把自己对VTun工作原理做了一个简要的叙述。限于水平，文章难免谬误，仅供参考。欢迎指正！
这一个阶段主要是服务器和客户端的为下一阶段的通信做各种初始化和准备工作，依次包括建立连接、挑战/握手认证、设置TAP/TUN设备等。
初始化阶段
如图可以看出，这一阶段还没有用到虚拟网卡TAP/TUN设备，服务器和客户端所有通信均通过物理网卡eth0进行，双方会开启socket网络套接字进行挑战/握手认证双方合法性。注意：挑战/握手所需要的密钥在配置文件vtund.conf给出（字段是pass XXXX），还有我们会注意到在源代码中的认证还需要host（在auth.c中）
if( !(h =find_host(host)) )
break;
此处的host就是在vtund.conf中的服务器端给客户定义的名字（服务器端可以任意取）。
接下来，服务器和客户会根据各自的配置文件设置虚拟网卡的特征，比如是TUN还是TAP，或者PIPE、TTY，配置虚拟网卡的网络地址和内核的路由等。
好了，我们假设以上一切顺利了。现在，万事俱备、只欠东风。下面就是重头戏，主角虚拟网卡出场了。
这一阶段基本进入了正题，服务器端和客户端的应用程序可以使用虚拟网卡进行加密通信了。
虚拟隧道通信
下面就上图的做一个说明。这里我们假设：
VTun服务器：IP：eth0 192.168.1.11 tun0 10.0.1.1
VTun客户端：IP：eth0 192.168.2.22 tun0 10.0.1.2
（关于VTun的配置可以参见关于VTun建立IP隧道的配置文件中的网络配置）
1. VTun客户端的应用程序要和VTun服务器的应用程序进行通信，发往服务器的数据报的出口为tun0设备。数据包的源IP 10.0.1.2，目的IP 192.168.1.11（目的地址也可能为10.0.1.1，这要看应用程序说提供服务的IP。如果是IP 192.168.1.11，那么还要有网关gw10.0.1.1帮忙转发，才可以滴）；
2. 虚线表示VTun进程read读取tun0设备的数据，不走TCP/IP协议栈。而读取的数据为IP包（另，在TAP的是以太网帧）；
3. 隧道封装。VTun进程对读到的数据进行对称加密，然后write写到socket套接字描述符，通过物理网卡，发送到通信对端。（数据包的源IP 192.168.2.22，目的IP 192.168.1.11）。这样一来，就形成了加密隧道包裹的情形了。TUN的是IP-in-IP，TAP的是ETH-in-IP；
4. 数据包正常路由；
5. 隧道解封装。在VTun服务器，VTun进程read读取socket套接字描述符，然后进行对称解密；
6. 虚线表示VTun进程将解密后的数据write写到tun0设备；
7. tun0设备将数据包交给TCP/IP协议栈处理。或者转发，或者递交到上层应用，比如VTun客户端的应用程序收到数据。
总结：
VTun的一个优点就是在用户区，即使崩溃了也不会影响系统内核。注意：由于封装隧道的缘故，数据包在整个过程中，IP报头和TCP或UDP头都没有被修改，因此不惧NAT和源路由过滤。因为只是添加了一条到tun0设备路由而已，可以说是以最小的代价完成了数据报的“乾坤大挪移”。
联系客服
