第一章：OpenVPN简介

虚拟专用网络——Virtual Private Networks(VPNs)的创建是出于对跨不受保护的基础设施进行安全通信的最大需求。

什么是VPN?

简而言之，VPN允许管理员在不同网段上的多台计算机之间创建"local"网络。

VPN的P来自额外的保护，使虚拟网络私有。

与隧道外的所有其他流量相比，流经VPN的网络流量通常被称为(VPN)隧道内。

普通情况下，互联网上的数据会跨越多个网段和一般互联网，流量相对开放，可以进行检查和分析。尽管HTTPS和SSH等受保护的协议不那么容易受到攻击，但它们仍然是可识别的；如果攻击者正在窥探网络流量，他们仍然可以看到从哪台计算机到哪台服务器建立了什么类型的连接。

当使用VPN时，隧道内的流量是不可识别的(对于隧道外的窥探者而言)。

VPN内的流量可以是你通过局域网或广域网发送的任何内容：网络流量、电子邮件、文本、图形等。一些应用程序的示例包括以下内容：

自动提款机——Automated Teller Machines(ATMs)可以使用VPN更安全地连接到银行系统。
开放/免费 Wi-Fi——日常用户可以在使用开放/免费WiFi时利用VPN来保护他们的整个互联网浏览。
企业网络——企业和其他组织可以使用VPN连接多个办公地点甚至整个数据中心。
GeoIP/ 基于位置的服务——一些网站通过使用GeoIP数据库和其他记录基于地理位置提供服务。VPN可以让你在离你真正想要的内容更近的位置“跳出”另一台机器。(大概类似一种“位置欺骗”)。
绕过审查

虽然VPN本身在互联上路由，但网络路径上的设备只能看到VPN流量，但完全不知道私人隧道内正在传输什么。受保护的协议(如HTTPS和SSH)在隧道内仍然受到保护，不受其他VPN用户的影响，但在隧道外将无法识别。VPN不仅加密隧道内的流量，还隐藏和保护隧道外的单个数据流。

VPN技术最大的威胁之一是，VPN隧道时通过两侧的路由器和防火墙挖掘的。因此，除非采取特殊措施来监管VPN流量，否则通过VPN隧道流动的所有网络流量都会绕过常规网络防御。

大多数VPN实现都利用某种形式的加密，此外还有身份验证。VPN的加密确保了可能监控系统间流量的其他方无法解码和进一步分析其他敏感数据。身份验证有两个组件，每个组件都处于不同的上下文中。

首先，有用户或系统身份验证，可确保连接到服务的人获得授权。这类型的身份验证可以是每用户证书的形式，也可以是用户名/密码组合的形式。此外，可以协商特定于给定用户的规则，如特定路由器、防火墙规则或其他脚本和实用程序。通常，这些是单个实例独有的，尽管即使是这样也可以配置。

身份验证的第二个组成部分是为通信流添加保护。在这种情况下，建立了对每个发送的数据包进行签名的方法。每个系统在解密有效载荷之前，都会验证它接收到的VPN数据包是否已经正确签名。通过已经加密的数据包进行身份验证，系统甚至可以不解密不符合身份验证规则的数据包，从而节省处理时间。最后，这可以防止非常真实的潜在拒绝服务(Denial of Service——DoS)攻击，并挫败中间人攻击(Man in the Middle——MITM)，前提是签名密钥保持安全。

VPNs的类型

市场上有许多VPN产品，包括商业和开源产品。几乎所有这些VPN产品都可以分为以下四类：

基于PPTP协议的VPN
基于IPSec协议的VPN
基于SSL的VPN
OpenVPN

有些人认为OpenVPN也是一种基于SSL的VPN，因为它使用类似SSL或TLS的协议来建立安全连接。但是，我们为OpenVPN创建了一个单独的类别，因为它与几乎所有其他基于SSL的VPN解决方案都不同。

我们现在将详细介绍四种类型的VPN：

PPTP

Point-to-Point Tunneling Protocol(PPTP)，点对点隧道协议，是最古老的VPN协议之一，由微软和Ascend于1999年开发。它被正式注册为RFC2637。

PPTP客户端自1995年以来一直包含在Windows中，并且仍然包含在大多数操作系统中。

如今，PPTP协议被认为从根本上是不安全的，因为连接的安全强度与所选的身份验证机制(如密码)的强度直接相关。因此，不安全的密码会导致不安全的VPN连接。大多数PPTP设置都是用MS-CHAPv2协议来加密密码，但是这个协议已经被破坏了。

也可以使用X.509证书来保护PPTP连接，这确实会提高安全性。然而，并非所有PPTP客户端都支持EAP-TLS，这是允许使用X.509证书所必须的。

PPTP使用两个通道，一个用于建立连接(称为控制通道)，另一个用于数据传输。控制通道通过TCP端口1723启动。数据通道使用通用路由封装(General Routing Encapsulation——GRE)协议，即IP协议47。为了进行比较，“常规”TCP/IP流量是使用IP协议6(TCP)和17(UDP)完成的。

PPTP客户端几乎可以在所有操作系统上使用，从Windows到Linux和Unix衍生品，再到iOS和Android设备。

IPSec

IPSec标准是IEEE/IETF的IP安全官方标准。它被注册为RFC2411。IPSec也内置于IPv6标准中。

IPSec在网络栈的OSI模型的第二层和第三层运行。它引入了安全策略的概念，这使得它非常灵活和强大，但也很难配置和维护。安全策略允许管理员根据许多参数加密两个端点之间的流量。

IPSec中有两种操作模式：隧道模式(tunneling mode)和传输模式(transport mode)。传输模式最常与2级隧道协议(Level 2 Tunneling Protocol——L2TP)结合使用。此L2TP协议执行如前一节所述的用户身份验证。大多数操作系统内置的IPSec客户端通常执行IPSec+L2TP，尽管也可以设置仅IPSec连接。默认情况下，MS Windows内置的IPSec VPN客户端使用IPSec+L2TP，但可以禁用或绕过它。但是，这涉及神秘的命令和更改安全策略。

与PPTP一样，IPSec也使用两个通道：一个用于建立连接的控制通道，和一个用于数据传输的通道。控制通道通过UDP端口500或4500启动。数据通道使用封装安全有效载荷(Encapsulated Security Payload——ESP)协议，即IP协议50。为了进行比较，“常规”TCP/IP流量是使用IP协议6(TCP)和17(UDP)完成的。使用基于哈希的消息验证码(Hash-based Message Authentication Code——HMAC)确保IPSec数据包的完整性，这与OpenVPN使用的方法相同。

IPSec的主要缺点之一是，许多供应商已经实现了对标准的扩展，这使得连接来自不同供应商的两个IPSec端点变得困难，甚至不可能。

IPSec软件几乎包含在所有操作系统中，以及防火墙、路由器和交换机固件中。

SSL-based VPNs

目前最常用的VPN是基于SSL的VPN，它基于SSL/TLS协议。基于SSL的VPN通常被称为无客户端VPN或基于网络的VPN，尽管也有一些供应商提供单独的客户端软件，如思科AnyConnect和微软SSTP。大多数基于SSL的VPN使用与安全网站相同的网络协议(HTTPS)，而OpenVPN使用自定义格式对数据流量进行加密和签名。

基于SSL的VPN没有明确的标准，但大多数使用SSL/TLS协议来设置和保护连接。在大多数情况下，使用X.509证书保护连接，并使用一次性密码或用户名/密码协议对连接进行身份验证。基于SSL的VPN与用于保护网站的连接（HTTPS）非常相似，并且通常使用相同的协议和通道（TCP和端口443）。

尽管基于SSL的VPN通常被称为基于网络或无客户端，但也有不少供应商使用浏览器插件或ActiveX控件来“增强”VPN连接。这使得VPN无法与不受支持的浏览器或操作系统进行交互。

OpenVPN

OpenVPN通常被认为是一种基于SSL的VPN，因为它也使用SSL/TLS协议来保护连接。然而，OpenVPN还使用HMAC结合摘要(或哈希)算法来确保所传递数据包的完整性。它可以配置为使用预共享密钥和X.509证书。其他基于SSL的VPN通常不提供这些功能。

此外，OpenVPN使用虚拟网络适配器(tun或tap设备)作为用户级OpenVPN软件和操作系统之间的接口。一般来说，任何支持tun/tap设备的操作系统都以运行OpenVPN。目前包括Linux、Free/Open/NeBSD、Solaris、AIX、Windows和Mac OS，以及iOS/Android设备。对于所有这些平台，都需要安装客户端软件，这将OpenVPN与无客户端或基于网络的VPN区分开来。

OpenVPN协议在RFC标准中没有定义，但该协议是公开可用的，因为OpenVPN是一款开源软件。事实上，它是开源的，这使得OpenVPN比闭源VPN更安全，因为代码会不断被不同的人检查。此外，OpenVPN中内置秘密后门的可能性很小。

OpenVPN具有控制通道和数据通道的概念，两者的加密和安全性不同。但是，所有流量都通过单个UDP或TCP连接传递。控制通道使用SSL/TLS进行加密和保护，数据通道使用自定义加密协议进行加密。

OpenVPN的默认协议和端口是UDP和端口1194。在IANA授予OpenVPN官方端口分配之前，较旧的客户端（2.0-beta16及以上）默认为端口5000。

VPNs比较

每种不同的VPN技术都有自己的特点、优点和缺点。尽管这本书是关于OpenVPN的，但根据用户的要求，在某些用例中，基于IPSec的VPN更合适。

PPTP优缺点

最主要的优点是普及，几乎所有操作系统都有PPTP客户端软件。

此外，配置和初始化PPTP VPN连接的启动时间非常短。

主要缺点是缺乏安全性，并且在客户端和服务器端都缺乏配置选项。

此外，仅在Microsoft Windows上完全支持启用X.509证书的EAP-TLS扩展，尽管开源pppd包存在启用EAP-TLS支持的补丁。pppd包几乎包含在每个Linux发行版中。此外，如果必须使用EAP-TLS，那么设置PPTP VPN的建议度就会大大降低(Also, if one must resort to using EAP-TLS, then the ease of setting up a PPTP VPN is greatly diminished. )。这是因为EAP-TLS需要设置公钥基础设施，就像IPSec和OpenVPN一样。

PPTP的另一个主要缺点是使用GRE协议，该协议不能很好地与NAT设备集成。

IPSec优缺点

IPSec协议的优点是其强大的安全性、来自不同供应商和平台（包括xDSL和Wi-Fi路由器）的良好支持，以及使用细粒度安全策略控制流量的能力。

IPSec的缺点是，众所周知，配置和故障排除都很困难，不同供应商的不同IPSec实现不能很好地结合在一起，IPSec也不能与NAT网络很好地集成。最值得注意的是，不建议，有时甚至不可能在NAT网络上运行IPSec服务器。

SSL-based VPNs优缺点

基于SSL的VPN或基于网络的VPN的优点是不需要或只需要很少的客户端软件。这使得客户端的安装和初始化非常容易。

基于网络的VPN的缺点是，它通常不是一个成熟的VPN，允许访问单个服务器或一组服务器。此外，与远程站点或服务器共享本地数据也更难。

OpenVPN优缺点

OpenVPN的优点是其易于部署、可配置性以及在受限网络（包括NAT网络）中部署OpenVPN的能力。此外，OpenVPN包括与基于IPSec的解决方案一样强大的安全功能，包括硬件令牌安全和对不同用户身份验证机制的支持。

OpenVPN的缺点是它目前缺乏可扩展性，并且依赖于客户端软件的安装。另一个缺点是缺乏用于配置和管理的GUI。值得注意的是，当发布新版本的Windows时，Microsoft Windows的点击界面驱动程序经常会导致部署问题。

OpenVPN的历史

最初由James Yonan编写，初代版本为0.90，于2001年根据GPL发布。最初的版本允许用户使用Blowfish密码和SHA1 HMAC签名(可选)在UDP上创建简单的点对点VPN。在1.0版本中，添加了基于TLS的身份验证和密钥交换以及手册页(man page)。

OpenVPN 1.x的改进包括更好的TLS支持、重放保护(replay protection)和移植到其他操作系统。一些ports，包括OpenBSD、Mac OS和更好的RedHat封装。在1.1.1版本之前，tun设备必须在OpenVPN之外手动配置。此版本添加了 --ifconfig 选项，该选项可以自动配置tun设备，大大简化了整体配置。

与当前的OpenVPN 2.3.8相比，1.x系列相对粗糙，这是新项目的预期。一个主要障碍是OpenSSL的集成。由于OpenSSL因其糟糕或完全缺失的文档而臭名昭著，开发人员不得不直接访问源代码，将项目与OpenVPN集成。早期还需要更改许可证，以允许更具体地GNU公共许可代码链接到非GPL OpenSSL库。这些问题已经解决，在整个1.x系列地更改日志中，功能添加都很突出。

1.x系列中的一些值得注意的更新包括：

2001.05.13 (0.90): 首次发布
2002.03.23 (1.0): 允许TLS身份验证和密钥交换
2002.04.09 (1.1.0): 它有一个OpenBSD端口和OpenSSL链接
2002.04.22 (1.1.1): 添加了 --ifconfig 选项
2002.05.22 (1.2.0): 开始使用配置文件，而不仅仅是命令行选项、pthread支持、Solaris 端口
2002.07.10 (1.3.0): 更好的FreeBSD支持和日志改进
2002.10.23 (1.3.2): 开始支持IPv6，并对FreeBSD进行了更多改进
2003.05.07 (1.4.0): 包含了MTU功能
2003.07.24 (1.5-beta1): 提供TCP支持
2003.11.03 (1.5-beta13): 支持配置参数 --http-proxy、--redirect-gateway、--crl-verify
2004.02.01 (1.6-beta5): 在FreeBSD上提供SOCKS5 代理和 IPv6
2004.05.09 (1.6.0): 1.x 发行版的最后一版

OpenVPN 2.0比1.x版本有了更大的进步。在2.0版中，我们努力提供了客户端服务器实例、改进的线路和更好的Windows tun/tap适配器。2.0的开发与1.x重叠了一年多，2.0的初始测试版本可以追溯到2003年11月，最终的1.x版本直到2004年5月9日才发布。当它最终发布时，2.0在一年半的时间里发布了29个test版本、20个beta版版、21个release candidate(候选)版本。

与1.6.0版本相比，2.0版有以下关键特性：

允许服务器实例接受来自多个客户端的连接
启用服务器端的config选项push到客户端 (--push/--pull)
允许用户名/密码验证
允许 chroot 以及降低守护进程权限 (--user/--group/--chroot)
支持客户端连接脚本
有一个管理界面
诞生了 Easy-RSA

从2.0到2.0.9的开发主要包括对一些安全漏洞的错误修复和更正。除了少数人的零星贡献外，OpenVPN主要由James开发，直到2.1版。从2006年10月到2009年12月的2.1.0版，2.0.9一直处于停滞状态。

OpenVPN2.1是第一个由James Yonan以外的人编写了大量代码的主要版本。Alon Bar-Lev自2.1-beta3以来做出了许多重大贡献，并提供了许多密码支持和更正补丁。作为第一个真正的社区版本，2.1在核心代码库中进行了大量工作吗，涉及管理接口和网络寻址。一些值得注意的发行说明包括以下内容：

2005.11.12 (2.1-beta7): 可以在配置文件中内联(inline)指定 ca, cert, key, 和 dh 文件.
2006.01.03 (2.1-beta8): 添加 --topology 子网.
2006.02.16 (2.1-beta9): 允许端口共享，以便OpenVPN和HTTPS可以共享一个端口.
2008.09.10 (2.1_rc10): 如果使用通用192.168.0.0/24或192.168.1.0/24子网，则发出警告--server-bridge 以支持DHCP代理.
2010.08.09 (2.1.2): 它有一个基于Python的Windows构建系统，改进了管理界面对AUTH_FAIL的处理.
2010.11.09 (2.1.4): 2.1版的最后一个版本.

2008年8月，自2.0.9以来没有正式发布。此外，除了邮件列表之外，几乎没有社区支持。人们有兴趣建立一个社区，Krzee King和Eric Crist推动围绕该项目建立一个。最初，所有的努力都是为了支持用户。

随着支持OpenVPN的人群的增长，它吸引了能够编写好代码的人。与OpenVPN Inc. 取得了联系，目的不仅是为OpenVPN提供更好的支持，还包括构建和扩展James编写的软件，但合作的努力遭到了拒绝。

讨论开始于互联网中继聊天（Internet Relay Chat——IRC），这是许多开发人员首选的通信工具，用于移植项目，以便取得进展。开发开始；一些成员管理IRC并在邮件列表上提供帮助。其他人则建立了一个源代码库、维基和一个网络论坛。论坛上的平均使用量约为每天2个帖子，IRC上约有8个用户。

2009年初，OpenVPN技术聘请Samuli Seppänen帮助构建开源社区并与之互动。Samuli在建立公司与爱好者和志愿者之间的牢固关系方面发挥了重要作用。围绕该项目建立了一个强大的社区。如今，该论坛平均每天发布16条帖子（总共超过35000条消息），IRC在任何一天都在150到250名用户之间波动。

OpenVPN 2.2是切换到更面向社区的开发模式后的第一个版本。在明确了开发模型和方向后，社区希望继续推进该项目，并立即开始工作。

最初，对于OpenVPN 2.2，James仍然完全控制着合并到主源代码树中的内容，因为该树仍然使用OpenVPN Technologies的subversion进行管理。后来，源代码树被迁移到GIT，角色互换，James的更改被接受并合并到开源项目树中。

OpenVPN 2.2的显著变化是：

SOCKS plaintext authentication(明文认证)
改进了对 --topology 子网的平台支持
Solaris上的tap模式
编译的Windows版本启用了 ENABLE_PASSWORD_SAVE
Windows IPv6 tun 支持
客户端证书可以省略，其行为类似于web浏览器 (--client-cert-not-required)
客户端证书现在可以指示单独的用户名，而不是使用证书通用名 (--x509-username-field)
删除对Windows 2000及更早版本的支持
2011.04.26 发布 2.2.0版本
2011.07.06 发布 2.2.1版本，略有更改，主要与构建/安装相关
2011.12.22 发布 2.2.2版本，包含 Windows tap 驱动更改

OpenVPN 2.3是OpenVPN内部构建结构重大转变的开始。简而言之，最终目标是创建一个更具可扩展性和插件友好性的源代码。由于Android和iOS等移动平台的构建已经需要彻底重写，James和其他开发人员清理了旧代码，转而使用更紧凑和规范化的功能。这些重写是用C++完成的，而不是目前使用的C语言。

虽然在过去版本的更改日志中列出，但IPv6支持，无论是作为有效载荷还是在OpenVPN中传输，直到2.3版本才真正成熟。IPv6的绝大多数贡献都是Gert Döring辛勤工作的结果。

2.3版本的另一个重要特性是增加了对PolarSSL的支持。PolarSSL是OpenSSL的替代加密库，OpenVPN现在可以针对这两个库构建。本章稍后将更详细地讨论这个主题。

2.3版的改进和添加列表很大，亮点如下：

跨平台IPv6支持（传输和有效载荷）
新插件API
支持针对PolarSSL的构建，以及其他潜在替代方案的基础工作
客户端现在可以通知服务器支持LZO，服务器可以自动为该客户端禁用LZO
解决本地路由冲突的方法 (--client-nat)
新的 --crl-verify 目录模式, 名为通用名称的文件会禁用证书，就像它们被吊销一样
证书字段支持UTF-8
各子项目的项目划分：
- OpenVPN核心项目
- tap-windows
- Easy-RSA
- OpenVPN构建系统
从管理界面终止客户端连接

2.3.8版目前是最新的(本书撰写时)。

OpenVPN 包

互联网上有几个OpenVPN包：

OpenVPN的开源或社区版本
OpenVPN接入服务器，由OpenVPN Inc. 提供的闭源商业服务
适用于Android和iOS的OpenVPN移动平台版本（部分代码是闭源代码，这是苹果的要求）

开源 (社区——community) 版本

OpenVPN的开源版本在每个版本发布时都会提供。该社区拥有为多个平台构建二进制包的资源，包括32位和64位Windows客户端。当前可用的下载选项可在http://openvpn.net/index.php/download/community-downloads.html.

一些操作系统包维护人员跟踪开发并提供快照版本。例如，FreeBSD有一个security/openvpn-devel端口，可以跟踪openvpn开发中的每周tarball快照。如果你想运行最新、最先进的OpenVPN版本，请先查看你的软件包维护者。否则，您始终可以直接从源代码构建。

OpenVPN的社区版本既可以作为VPN服务器，也可以作为VPN客户端。没有单独的客户端版本。

闭源 (商业——commercial) 访问服务器

OpenVPN Technologies，股份有限公司提供名为访问服务器的商业版OpenVPN。与开源项目相比，Access Server提供了许多可能吸引某些组织的功能和部署选项。Access Server是一款付费产品，但网站上提供了启用两个许可证密钥的试用版。

软件包、虚拟设备和云服务均可从股份有限公司的OpenVPN Technologies获得，网址为https://openvpn.net/index.php/access-server/overview.html.

OpenVPN接入服务器包括自己的OpenVPN客户端OpenVPN Connect，适用于Windows和Mac OS。此客户端软件通常仅适用于OpenVPN接入服务器。也可以将OpenVPN的社区版本用作OpenVPN访问服务器的客户端。

移动平台 (混合——mixed) OpenVPN/OpenVPN 连接

对于移动设备，如iPhones/iPad和Android设备，OpenVPN Technologies，股份有限公司提供特殊的OpenVPN连接客户端。OpenVPN Technologies，股份有限公司和James专门与谷歌和苹果等公司进行了大量努力和法律纠纷，以在每个平台上访问可用的VPN API。

由于苹果保密协议的性质，目前OpenVPN Connect的来源不可用，也不能公开共享。iOS OpenVPN连接客户端可以从苹果应用商店下载，网址为https://itunes.apple.com/us/app/openvpn-connect/id590379981?mt=8.

有一些由少数开发人员编写的Android客户端，但官方支持的版本是由Arne Schwabe编写的Android版OpenVPN，可以在https://play.google.com/store/apps/details?id=de.blinkt.openvpn&hl=en.

由OpenVPN Technologies，股份有限公司编写的OpenVPN Connect也可用。您可以在以下网址下载Android OpenVPN Connect客户端https://play.google.com/store/apps/details?id=net.openvpn.openvpn&hl=en.

OpenVPN Connect的一个重要优势是它支持社区版本的OpenVPN以及闭源OpenVPN访问服务器。如果您需要访问这两种类型的服务器，建议使用OpenVPN Connect。

其他平台

有一些硬件供应商试图在他们的设备中集成对OpenVPN的支持。有些为VoIP电话提供固件版本，其中包括旧版本的OpenVPN。其他固件项目，如Linksys路由器的DD-WRT，以及FreeNAS、pfSense等其他项目，也集成了OpenVPN。

OpenVPN 内构件(internals)

OpenVPN的设计没有广泛的文档记录，但通过查看源代码可以发现OpenVPN的大部内构件。

tun/tap 驱动器

OpenVPN的基本构建块之一是tun/tap驱动程序。tun/tap驱动程序的概念来自Unix/Linux世界，在那里它通常是操作系统的一部分。这是一个虚拟网络适配器，操作系统将其视为仅用于IP流量的点对点适配器（tun型）或用于所有类型流量的完整虚拟以太网适配器（tap型）。此适配器的后端是一个应用程序，如OpenVPN，用于处理传入和传出的流量。Linux、Free/Open/NebSD、Solaris和Mac OS都包含一个tun内核驱动程序，它既能进行tun风格的操作，也能进行tap风格的运行。最近，一个类似的驱动程序被添加到AIX中，AIX是IBM的Unix衍生产品。

对于Microsoft Windows，James Yonan编写了一个特殊的NDIS驱动程序，称为TAP-WIN32适配器。目前，NDIS5和NDIS6版本的驱动程序可用，通过Windows 8.1支持Windows XP。该适配器的开发现在正式与OpenVPN的主要开发分开，但OpenVPN仍然严重依赖它。

用户应用程序通过OpenVPN的流量如上图(图略)所示。在图中，应用程序正在向可通过OpenVPN隧道访问的地址发送流量。步骤如下：

应该程序将数据包移交给操作系统。
操作系统使用正常的路由规则决定数据包需要通过VPN路由。
然后，数据包被转发到内核tun设备。
内核tun设备将数据包转发到（用户空间）OpenVPN进程。
OpenVPN进程对数据包进行加密和签名，必要时对其进行分段，然后再次将其交给内核，将其发送到远程VPN端点的地址。
内核接收加密的数据包并将其转发到远程VPN端点，在那里，相同的过程被逆转。

从图中还可以看出，OpenVPN的性能始终低于常规网络连接的性能。对于大多数应用程序，性能损失最小和/或可接受。然而，对于大于1GBps的速度，在带宽和延迟方面都存在性能瓶颈。

应该指出的是，Windows驱动程序的性能远低于其他操作系统中的本机tun/tap适配器的性能。即使在TAP-Win32驱动程序的最新NDIS6实现中也是如此。对于单个OpenVPN客户端，影响相当小。对于服务于许多客户端的大型OpenVPN服务器，这很容易导致性能问题。这是开源社区通常建议使用基于Unix或Linux的主机作为OpenVPN服务器的主要原因之一。

UDP 和TCP 模式

OpenVPN目前支持两种端点之间的通信方式：使用UDP数据包或使用TCP数据包。

UDP是一种无连接或有损协议：如果数据包在传输过程中丢失，则网络堆栈不会透明地(transparently)纠正这一点。

TCP数据包是一种面向连接的协议：数据包使用握手协议发送和传递，确保每个数据包都传递到另一端。

这两种沟通方式各有利弊。它实际上取决于通过VPN隧道发送的流量类型，以确定哪种通信模式最好。在基于TCP的VPN上使用基于TCP的应用程序可能会导致双重性能损失，特别是在底层网络连接不好的情况下。在这种情况下，对隧道内外丢失的数据包进行重新传输，从而导致双重性能损失。《Why TCP over TCP is a Bad Idea》一文中很好地解释了这个问题。

同样的，通过UDP发送UDP也不是一个好主意。如果使用UDP作为流量的应用程序容易受到消息删除(message deletion)或数据包重新排列(packet reordering attacks)攻击，那么底层加密TCP连接将比底层基于UDP的VPN更能增强此类应用程序的安全性。如果VPN上的大部分流量是基于UDP的，那么最好在VPN端点之间使用TCP连接。

在UDP或TCP传输之间进行选择时，一般经验法则如下：如果UDP（mode udp）适合您，则使用它；如果不是，则尝试TCP（mode tcp-server和mode tcp-client）。一些交换机和路由器不能正确转发UDP流量，这可能是一个问题，特别是在多个OpenVPN客户端连接到同一交换机或路由器的情况下。同样，OpenVPN over TCP的性能可能会受到互联网服务提供商（ISP）选择的严重影响：一些ISP使用奇怪的MTU大小或数据包分段规则，导致OpenVPN over TCP/IP的性能与未加密的TCP流量相比极差。

以上论述似乎是说：如果OpenVPN的两端使用samba传输数据，那么OpenVPN最好使用UDP模式，因为samba是走TCP协议的。这一点可能需要后续验证。

加密协议

据说，OpenVPN在UDP上实现了TLS。这可能是正确的，但OpenVPN使用TLS的方式与web浏览器使用它的方式不同。因此OpenVPN在TCP上运行时(使用端口443时躲避防火墙的常见方法)，流量与正常的TLS流量是不同的。使用深度数据包探测(Deep Packet Inspection——DPI)的防火墙可以轻松过滤OpenVPN流量。

OpenVPN TLS和浏览器TLS之间的主要区别在于数据包的签名方式。OpenVPN通过使用特殊的静态密钥(--tls-auth ta.key 1|1)对控制通道数据包进行签名，提供了防止DoS攻击的功能。通过同一UDP或TCP连接发送的数据通道数据包的签名完全不同，很容易与HTTPS流量区分开。OpenVPN官网描述了如何为UDP传输加密数据包。TCP传输也使用相同的机制。

【此处有图，略】

这也是为什么端口共享（OpenVPN和安全的web服务器共享相同的IP地址和端口号）实际上可以工作的主要原因。

控制和数据通道

OpenVPN使用两个虚拟通道在客户端和服务器之间进行通信：

TLS控制通道——用于在客户端和服务器之间交换配置信息和密码材料。此通道主要用于启动VPN连接时，以及交换新的加密密钥材料。此密钥材料在一定时间后更新(基于 --reneg-sec、--reneg-bytes 或 --reneg-pkts选项)。
数据通道——交换加密有效载荷。

这种情况的例外是较旧的预共享密钥点对点模式，其中只使用数据通道。

控制信道和数据信道的加密和认证(签名)被不同地确定。控制通道是使用TLS风格的协议启动的，类似于安全网站连接的启动方式。在控制信道初始化期间，加密密码和散列算法在客户端和服务器之间协商。

数据通道的加密和身份验证算法是不可协商的，但它们在OpenVPN的客户端和服务器配置文件中都有设置。当前的默认设置是Blowfish作为加密密码，SHA1作为哈希算法。为数据通道协商密码和散列算法的能力在开发团队的愿望清单上很高，但这需要对代码进行大量更改。

密码和散列算法

OpenVPN支持各种加密密码和哈希算法。密码用于加密有效载荷(payload)，而HMAC函数使用摘要或哈希算法来验证传入的数据包。由于OpenVPN使用控制通道和数据通道，因此可以配置两组密码和哈希算法。

控制信道密码和散列算法通常在启动时协商。可以使用以下命令显示密码和哈希算法的可用组合列表：


xxxxxxxxxx
$ openvpn --show-tls
Available TLS Ciphers, listed in order of preference:
For TLS 1.3 and newer (--tls-ciphersuites):
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
For TLS 1.2 and older (--tls-cipher):
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256
TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256
TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-AES-128-CBC-SHA
Be aware that that whether a cipher suite in this list can actually work
depends on the specific setup of both peers. See the man page entries of
--tls-cipher and --show-tls for more details.

以上输出是在FreeBSD14.1上得出的。使用OpenSSL3.0.13。

可用的组合在很大程度上取决于所使用的SSL库的确切版本。你可以在OpenVPN配置文件中指定tls密码列表，其方式与配置Apache mod_ssl模块非常相似：


xxxxxxxxxx
tls-cipher  TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-       
            WITH-AES-256-CBC-SHA384
:TLS-ECDH-RSA-WITH-AES-256-GCM-
            SHA384

在一行中列出所有密码；为了可读性，对前面的输出进行了修改。

对于数据通道，使用 --cipher 和 --auth 选项控制加密密码和哈希算法。如果未指定密码和身份验证算法，则分别使用 bf-cbc 和 sha1 的默认值。

要检索可用加密密码的列表，可使用以下命令：


xxxxxxxxxx
$ openvpn  --show-ciphers
The following ciphers and cipher modes are available for use
with OpenVPN.  Each cipher shown below may be used as a
parameter to the --data-ciphers (or --cipher) option. In static
key mode only CBC mode is allowed.
See also openssl list -cipher-algorithms
AES-128-CBC  (128 bit key, 128 bit block)
AES-128-CFB  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-CFB1  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-CFB8  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-GCM  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-OFB  (128 bit key, 128 bit block, TLS client/server mode only)
AES-192-CBC  (192 bit key, 128 bit block)
AES-192-CFB  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-CFB1  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-CFB8  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-GCM  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-OFB  (192 bit key, 128 bit block, TLS client/server mode only)
AES-256-CBC  (256 bit key, 128 bit block)
AES-256-CFB  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-CFB1  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-CFB8  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-GCM  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-OFB  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-CBC  (128 bit key, 128 bit block)
CAMELLIA-128-CFB  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-CFB1  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-CFB8  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-OFB  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-CBC  (192 bit key, 128 bit block)
CAMELLIA-192-CFB  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-CFB1  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-CFB8  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-OFB  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-CBC  (256 bit key, 128 bit block)
CAMELLIA-256-CFB  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-CFB1  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-CFB8  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-OFB  (256 bit key, 128 bit block, TLS client/server mode only)
CHACHA20-POLY1305  (256 bit key, stream cipher, TLS client/server mode only)
The following ciphers have a block size of less than 128 bits,
and are therefore deprecated.  Do not use unless you have to.
DES-EDE-CBC  (128 bit key, 64 bit block)
DES-EDE-CFB  (128 bit key, 64 bit block, TLS client/server mode only)
DES-EDE-OFB  (128 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-CBC  (192 bit key, 64 bit block)
DES-EDE3-CFB  (192 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-CFB1  (192 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-CFB8  (192 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-OFB  (192 bit key, 64 bit block, TLS client/server mode only)

这里显示的每个密码都可以用作 --cipher选项的参数。无论是否可以使用 --keysize 指令更改，都会显示默认密钥大小。建议使用CBC模式。在静态密钥模式下，只允许CBC模式。

在以上输出中，只显示了最常用的密码。可用密码列表再次取决于底层加密库的确切版本。然而，在大多数情况下，Blowfish（BF-*）和AES（AES-*）密码应该可用。

同样，对于身份验证（HMAC签名）算法，我们使用以下命令列出所有可用选项：


xxxxxxxxxx
$ openvpn --show-digests
The following message digests are available for use with
OpenVPN.  A message digest is used in conjunction with
the HMAC function, to authenticate received packets.
You can specify a message digest as parameter to
the --auth option.
See also openssl list -digest-algorithms
SHA512 512 bit digest size
SHA384 384 bit digest size
SHA512-224 224 bit digest size
SHA3-256 256 bit digest size
SHAKE256 256 bit digest size
SHA3-224 224 bit digest size
SHA256 256 bit digest size
SHA1 160 bit digest size
SHA3-384 384 bit digest size
SHAKE128 128 bit digest size
MD5-SHA1 288 bit digest size
RIPEMD160 160 bit digest size
SHA3-512 512 bit digest size
MD5 128 bit digest size
SHA224 224 bit digest size
BLAKE2b512 512 bit digest size
SHA512-256 256 bit digest size
BLAKE2s256 256 bit digest size
KECCAK-KMAC-128 256 bit digest size
KECCAK-KMAC-256 512 bit digest size
NULL 0 bit digest size

以上消息摘要可用于OpenVPN。消息摘要与HMAC函数结合使用，以对接收到的数据包进行身份验证。您可以将消息摘要指定为--auth选项的参数：


xxxxxxxxxx
[…]
SHA 160 bit digest size
SHA1 160 bit digest size
[…]
ecdsa-with-SHA1 160 bit digest size
[…]
SHA256 256 bit digest size
SHA384 384 bit digest size
SHA512 512 bit digest size
SHA224 224 bit digest size

在这个输出中，只显示了最常用的摘要或哈希算法。可用摘要列表取决于底层加密库的确切版本。在大多数情况下，SHA-1和SHA-2系列哈希算法应该是可用的。

OpenSSL 对比 PolarSSL

从OpenVPN 2.3开始，添加了对新SSL库的支持。PolarSSL库(http://polarssl.org)可以编译，而不是默认的OpenSSL库。添加第二个库的主要原因是确保底层加密库的独立性，并确保不会出现版权问题，因为OpenSSL版权许可证与OpenVPN使用的许可证不同。

总结

在本章中，我们首先解释了什么是VPN。然后我们讨论了不同类型的VPN协议的一些示例，包括PPTP、IPSec和OpenVPN。在简要概述了OpenVPN的历史之后，我们继续深入研究OpenVPN中使用的技术。这些技术包括tun/tap适配器以及使用的加密和数据包签名算法。

在介绍了VPN和OpenVPN本身之后，现在是时候了解更多关于OpenVPN的信息了。在下一章中，我们将从使用OpenVPN的最基本方法开始，即使用预共享密钥的点对点模式。随着我们在本书中的学习，您将更深入地了解如何在各种配置中使用OpenVPN。