前言

我认为了解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值是否一致，一致则通过认证。

摘要

本篇文章采用蜕变测试(metamorphic testing)的原理来寻找可能影响DeepFake检测模型鲁棒性的潜在因素，并缓解其中的Oracle问题。作者对MesoInception-4和TwoStreamNet两种检测模型进行了评估。通过蜕变测试发现化妆应用程序是一种对抗性攻击，可以欺骗deepfake检测器。实验结果表明，MesoInception-4和TwoStreamNet模型在输入数据被施加化妆扰动时，其性能下降高达30%。

Oracle问题：程序的执行结果不能预知的现象在测试理论中称为“Oracle问题”，即无法知道输入的预期结果，导致测试人员只能选择一些可以预知结果的特殊测试用例进行测试，而不能完整有效地进行测试。例如测试sin函数时，并不知道sin(153°)的预期结果。从而无法验证输入为153°时程序的正确性。
蜕变测试：蜕变测试是软件测试中的概念，是一种特殊的黑盒测试方法。蜕变测试依据被测软件的领域知识和软件的实现方法建立蜕变关系(Metamorphic Relation, MR)，利用蜕变关系来生成新的测试用例，通过验证蜕变关系是否被保持来决定测试是否通过。同样以sin函数为例，虽然不知道sin(153°)的预期结果，但是根据数学知识可以得知sin(27°)=sin(153°),这是一种蜕变关系。我们利用程序验证这种关系，如果这个关系不成立可以说明源程序存在问题。
蜕变关系(Metamorphic Relation, MR) ：指多次执行目标程序时，输入与输出之间期望遵循的关系。

实验设置

数据集：数据集选择的是FaceForensics++，其中包括四种Deepfake方式形成的图片:Deepfakes (DF),Face2face (F2F), Face Swap (FS),Neural Textures (NT)
受害者模型：MesoInception-4和TwoStreamNet

蜕变测试的应用

本文关于蜕变测试的具体应用如下图。具体来说，首先将数据集中的图片进行Metamorphic Transformation，得到两部分数据集(未扰动与扰动后)。将这两部分数据集分别输入检测器中，通过比较两次的检测结果来判断Metamorphic Transformation这种变化是否是影响模型鲁棒性的潜在因素。

个人感觉就是在对抗样本检测模型鲁棒性的基础上套了一个蜕变测试的壳子

因为输入的扰动数据集是在原始数据集上通过扰动得到，如果模型具有较好的鲁棒性，那么两次测试结果应该一致。这就是蜕变测试中的蜕变关系(MR)。

关于如何衡量MR是否满足，即比较两次测试结果的方式，论文提到的方法是比较两次测试结果的Accuracy,Recall,Specificity。

关于选择这三个指标的原因：选择Accuracy是因为它是用于DeepFake检测器的常见评估度量。它展示了模型的正确性和一致性。但是Accuracy受到准确性悖论(accuracy paradox)的影响，高准确性模型可能无法捕获分类任务中的基本信息。

因此作者还考虑了Recall和Specificity，因为FN和FP对于了解模型性能同样重要。高召回率表明模型在识别TP方面做得很好，而低召回率表明高FN。因此，Recall非常适合输出敏感的环境，例如预测deepfake或预测癌症(也就是说宁愿误判，也要找全)。同时，Specificity显示了模型在避免误报方面的表现。Specificity非常适合关注TP和FP的领域，例如推荐引擎(也就是说要减少误报)。