前言
我认为了解VPN的基本工作原理并实现一个TLS VPN需要以下前置知识：
-
虚拟专用网络(VPN)。既然要做一个VPN，那么首先需要了解VPN的基本概念，确认需要实现的VPN类型(IPSec VPN或TLS VPN)，并大致了解VPN的组成框架；
-
TUN/TAP与隧道。基于TCP隧道实现TLS VPN，那么隧道的概念与分类(基于UDP/TCP)需要有一定了解；另外VPN还使用到了虚拟网卡TUN，所以还需要了解TUN/TAP的工作原理以及使用；
-
安全套接字层(SSL)。为了保证数据传输的安全性，我们还需要使用同样用在HTTPS上的SSL，SSL介于应用层和运输层(仅限于TCP协议)之间，通过这个我们可以实现对数据的加密；
-
PKI 和 X.509证书。这部分承接SSL，因为SSL握手认证时需要对服务器(客户端)进行身份认证，需要用到证书。既然涉及到证书还需要了解证书的签发者(CA)；
-
身份认证。VPN的身份认证同样是一个重点部分，当然我们既然使用了SSL，说明已经对服务器进行身份认证，接下来只需要对客户端进行身份认证即可。我们这里简单使用Linux下的账户进行登录验证，需要了解影子文件(shadow)相关知识；
接下来将从以上几个部分展开介绍。
虚拟专用网络(VPN)
虚拟专用网络（VPN）用于创建计算机通信的专用通信域，或为专用网络到不安全的网络（如Internet）的安全扩展。VPN 是一种被广泛使用的安全技术。在IPSec或TLS/SSL（传输层安全性/安全套接字层）上构建VPN是两种根本不同的方法。本实验中，我们重点关注基于 TLS/SSL的VPN。
TLS VPN共有三种实现方式：基于Web代理、基于端口转发、基 于 隧 道。我们选用跟IPSecVPN类似的隧道实现，这要求客户需要在本地安装客户端软件，并启动虚拟网卡。
基于隧道的TLS VPN工作流程(客户端->内网服务器)大概如下：到内网服务器的IP报文（虚拟网卡IP->内网服务器IP）会被客户端软件进行 SSL协议封装（真实网卡IP->TLS VPN网关IP），通过隧道传送到对端的TLS VPN网关设备再解密解封装，还原为原始IP报文，交给内网服务器。
TUN/TAP
TLS VPN中使用了TUN/TAP技术。TUN和TAP是虚拟网络内核驱动程序；它们可以实现完全由软件支持的网络设备。TAP 模拟以太网设备，处理的是以太网帧等二层数据包；TUN 模拟网络层设备，处理的是 IP 等三层数据包。我们可以用 TAP/TUN 创建虚拟网络接口(使用TUN创建虚拟网卡)。
个人理解虚拟网卡的read/write函数，我们完全可以将虚拟网络接口看成一张实际的网卡，当我们调用read函数时，就是读取从这张网卡转发出来的报文（即目的IP为虚拟网卡IP或报文根据路由转发到虚拟网卡），将其交给上层应用；当我们调用write函数时，相当于报文从计算机外部进入虚拟网卡，这个时候报文究竟发到哪里取决于它的目的IP，如果目的IP不同于虚拟网卡的网段，那么这个时候报文会根据路由表路由到对应网段的物理网卡，通过该物理网卡送出(相当于计算机是一个路由器，报文从虚拟网卡入，从相应的物理网卡出)；如果目的IP就是虚拟网卡IP，那么该报文直接上交给应用程序；TLS VPN做远程接入功能时，不存在报文的目的IP和虚拟网卡IP不同但却在同一网段的情况。
VPN隧道
VPN隧道技术就是基于虚拟网卡(TUN/TAP)的技术，具体流程如下：假设VPN客户端10.0.2.7和VPN服务器10.0.2.8都开启虚拟网卡tun0,其中服务器的虚拟IP地址为192.168.53.1，客户端的虚拟IP地址为192.168.53.5。服务器连通192.168.60.0/24内网，我们希望VPN客户端可以访问内网的资源。
对于VPN客户端，我们首先设定目的IP为内网地址(以192.168.60.101为例)的报文统一转发到tun0虚拟网卡(设置路由)；正如我们在1.2中所说，这个时候经过tun0转发的报文源IP为192.168.53.5，目的IP为192.168.60.101，此时由于tun0是虚拟网卡，所以该报文并不会直接进入局域网中；VPN客户端程序通过read函数从tun0网卡读出报文，在此处可以对报文进行加密等操作，接下来将报文通过socket连接发送给VPN服务器，socket连接的源IP是物理网卡IP：10.0.2.7，目的IP为VPN服务器的10.0.2.8。
这个过程我们可以理解为，客户端发给内网主机的报文，首先通过tun0虚拟网卡进行封装，添加了IP头部；随后VPN客户端程序从tun0读出该报文，经过加密等操作后通过socket连接发送给VPN服务器(即再次经过物理网卡10.0.2.7封装)，此时报文外面的IP头部标识着两个物理网卡的IP，里面的IP头部信息为客户端tun0的IP：192.168.53.5 到 内网IP：192.168.60.101。
VPN服务器通过socket连接收到了客户端发出的报文，物理网卡10.0.2.8接收并交给VPN服务器程序，此时的报文已经被网卡去掉了外面的IP头部，那么这个时候报文的源/目的IP正如上一段所述。这时服务器程序将报文写入服务器的tun0网卡中，那么从tun0网卡192.168.53.1的角度来说：我接收到了一个源IP为192.168.53.5的报文，它的目的地是192.168.60.101，我应该查路由表寻找192.168.60.0/24网络对应的转发端口，并转发出去，从而到达内网主机。
至此客户端发给内网主机的报文已经成功到达了内网。
客户端接收报文与上述情况正好相反，内网主机首先发出回应报文(这里需要设置内网主机到VPN服务器docker2的路由，一般来说是默认路由，因为VPN服务器充当着默认网关的角色)。这个时候由于报文目的IP是192.168.53.5，属于192.168.53.0/24网络，自然会转发到tun0端口(192.168.53.1)。这个时候VPN服务器程序从tun0中取出该报文，可能做加密等操作，便通过socket连接发送给客户端。
客户端的物理网卡10.0.2.7收到报文后，褪去IP首部交给VPN客户端程序(因为socket连接就是VPN客户端和服务器之间建立的)。客户端收到该报文后，写入tun0虚拟网卡，由于tun0的IP地址就是报文的目的IP地址，因此客户端计算机不会再路由报文，而是直接上交给应用程序。
至此应用程序就可以正常与内网主机通信，VPN隧道介绍完毕，个人认为这是最重要的一部分。
安全套接字层(SSL)
在1.3中提到的socket连接可以是UDP或TCP，但是这两种方式都没有对隧道中的报文进行加密和完整性检验，我们可以选择在TCP的基础上搭建安全套接字层(SSL/TLS)。
TLS通常建立在TCP之上，SSL连接的建立同样需要握手。一般来说，由客户端发起连接”client hello”，附带SSL版本、加密套件列表等信息；服务器收到hello报文后回复”server hello”报文，附带服务器证书和生成的密钥信息；客户端验证完毕后生成密钥信息并将其发送给服务器；至此两方都有对方的密钥信息，接下来可以使用生成的密钥进行通信。
在上述过程中，客户端验证了服务器的证书；实际上服务器也可以验证客户端的证书，实现客户端身份认证。
PKI 和X.509证书
在PKI系统中,由证书认证机构(Certification Authority, CA)签发数字证书、绑定 PKI 用户的身份信息和公钥。PKI依赖方(Relying Party)预先存储有自己所信任的根CA自签名证书,用来验证与之通信的PKI用户的证书链,，从而可信地获得该用户的公钥、用于各种安全服务。
X.509是PKI的标准格式，它是由公钥和私钥组成的密钥对而构建的。公钥和私钥能够用于加密和解密信息，基于X.509的PKI最常见的用例是使用SSL证书让网站与用户之间实现HTTPS安全浏览。
身份认证
证书本身是一种身份认证，但是在正常场景中，用户更多还是习惯基于口令认证。因此可以基于远程登录的思想，当VPN客户端连接VPN服务器时，需要输入VPN服务器下的账户和密码。建立SSL连接后，VPN服务器程序查看shadow文件，检查账户与对应密码的MD5值是否一致，一致则通过认证。
