虚拟专用网络 (VPN) 是实用且方便的东西。经常出差的人员使用它们在旅行时安全地连接到他们的家庭网络；地理位置分散的组织使用它们来加密使用公共带宽的 WAN 链路；无线 LAN 用户使用它们为他们的 WLAN 连接增加一层安全保护。

许多 VPN 软件包可用于 Linux：FreeS/WAN、OpenS/WAN、PoPToP、OpenVPN 和 tinc，仅举几例。但是，您如何为给定的工作选择合适的软件包？在本月的专栏中，我将向您展示如何选择。

VPN 通常解决两个不同的需求。第一个需求是允许用户通过某些不受信任的媒介（例如 Internet 或无线 LAN (WLAN)）以加密连接连接到专用网络。图 1 说明了远程访问场景。

图 1. 远程访问 VPN 允许一个远程系统连接到网络。

在图 1 中，虚线蓝色数据流表示可以访问整个公司 LAN。实际上，远程访问 VPN 隧道可以通过访问控制列表 (ACL) 或防火墙规则来限制该访问。甚至在 SSL-VPN 的情况下，访问也可以限制为单个主机上的单个应用程序（我稍后将解释 SSL-VPN）。

为了简单起见，图 1 显示了一个客户端；但是，此场景几乎总是涉及多个客户端。换句话说，远程访问场景需要客户端-服务器架构，其中单个 VPN 服务器或集中器可以与数百甚至数千个远程用户建立隧道。（在本文中，我以非常广泛的意义使用术语客户端-服务器，而不是在特定的软件开发意义上。）

虽然图 1 显示 VPN 服务器充当公司 LAN 的 VPN 端点，但防火墙也可以用于此目的——商业防火墙和免费防火墙，包括 Linux iptables/Netfilter，都支持 VPN 协议。

重要提示：在本文中，当我说隧道时，我指的是加密隧道。是的，从技术上讲，术语隧道仅表示将一个数据流封装到另一个数据流中。但 VPN 的重点是加密，因此在这种上下文中，隧道等于加密。

第二个 VPN 需求是在两个不同的网络之间通过一些不受信任的媒介创建加密的点对点连接。远程访问 VPN 使用客户端-服务器模型，而点对点隧道使用对等模型。图 2 显示了点对点 VPN 架构。

图 2. 点对点 VPN 连接两个网络。

路由器通常用于点对点 VPN 场景。例如，Cisco 的 IOS 路由器操作系统支持多种不同的 VPN 协议。但是，防火墙和专用 VPN 集中器/服务器也可以用作 VPN 端点。

这些是 VPN 架构解决的两个问题。还有两个架构注意事项值得一提：网络地址转换 (NAT) 和性能。

对于大多数 VPN 协议，NAT 可能会有问题。也就是说，您的 VPN 服务器通常不能具有转换后的地址。这就是为什么在图 1 和图 2 中，除了图 1 中的远程客户端外，所有 VPN 端点都不在公司 LAN 中——远程访问客户端是此规则的例外。

将防火墙用作 VPN 服务器是解决 NAT 问题的一种方法，但这将我们引向第二个考虑因素：VPN 隧道可能占用大量 CPU 资源。除非您的防火墙具有加密加速卡或不需要支持许多并发 VPN 隧道，否则您最好使用专用 VPN 服务器，而不是将防火墙用于 VPN。

既然我们已经介绍了基础知识，那么让我们看一下用于 Linux 的特定 VPN 软件。

IPSec 协议，它实际上是 Internet 协议 (IP) v6 中的一组安全标头，反向移植到 IPv4，是最开放、强大和安全的 VPN 协议。它也是最普遍存在的。IPSec 支持现在是几乎所有重要的计算机和网络设备操作系统的一部分。在 Linux 上，它由 FreeS/WAN 和 OpenS/WAN 提供。

我在“FreeS/WAN 简介”的第 I 部分和第 II 部分 [分别在 2003 年 1 月和 2 月的 LJ 期刊中] 中深入介绍了 FreeS/WAN。简而言之，FreeS/WAN 为您的 Linux 系统添加了几个内核模块和用户空间命令。由于 IP 协议是内核的一部分，因此对 IP 协议的扩展也必须合并到内核中。

Linux 2.6 内核包含这些 IPSec 模块，称为 26sec 模块。Red Hat Enterprise Linux 随附的 Linux 2.4 内核也包含这些模块——它们包含 26sec 模块的反向移植版本。如果您已经有 IPSec 内核模块，则只需要安装 FreeS/WAN 的用户空间命令。

FreeS/WAN 可能包含在您选择的 Linux 发行版中（SuSE，这是我的选择，包含它）。但是，FreeS/WAN 项目最近已解散，因此如果您的发行版不包含 FreeS/WAN 并且您需要从源代码编译它，则最好使用 OpenS/WAN。

OpenS/WAN 由一群对 FreeS/WAN 项目的进展方式不满意的 FreeS/WAN 开发人员启动。因此，当 FreeS/WAN 结束时，OpenS/WAN 继承了它。最终，我们可以期望主要的 Linux 发行商用 OpenS/WAN 软件包替换他们的 FreeS/WAN 软件包。同时，您可以从 OpenS/WAN 网站（请参阅在线资源）获取最新的 OpenS/WAN 源代码。

FreeS/WAN 和 OpenS/WAN 的优势包括

缺点包括

话虽如此，如果在阅读完本文后，您仍然不清楚哪种 VPN 解决方案最适合您，我建议您默认选择 FreeS/WAN 或 OpenS/WAN。IPSec 是迄今为止 Linux 最成熟和最安全的 VPN 技术。在我看来，这些优势超过了复杂性的缺点。有关配置和使用这些软件包的更多信息，请参阅 FreeS/WAN 和 OpenS/WAN 网站。

很容易将 OpenSSH 纯粹视为远程 shell 工具。但是，SSH 协议支持安全隧道传输 任何 单个 TCP 端口服务，而不仅仅是 shell，通过使用 -L 和 -R 选项。

例如，假设我在防火墙保护但可公开访问的 DMZ 网络中有一个安全 shell 服务器，在我的内部网络中有一个 Microsoft SQL 服务器。如果我创建了一个防火墙规则，允许从 SSH 服务器到 MS-SQL 服务器的 MS-SQL 事务，并且如果我的 SSH 服务器允许端口转发，我可以创建一个远程主机和我的 SSH 服务器之间的 SSH 隧道，该隧道允许远程数据库客户端向远程主机发送查询，这些查询被隧道传输到 SSH 服务器并转发到 MS-SQL 服务器。我的远程主机上的 SSH 命令如下所示

bash-#> ssh -L 11433:ms-sql.server.name:1433 myaccount@remote.ssh-server.name

其中ms-sql.server.name是 MS-SQL 服务器的名称或 IP 地址，以及remote.ssh-server.name是 DMZ SSH 服务器的名称或 IP 地址。

甚至可以通过 SSH 隧道传输 PPP，这从技术上讲与 IPSec 实现了相同的目标——也就是说，隧道传输 所有 两个网络之间流量的能力。但是，这是实现此目的效率最低的方法之一；与本文中描述的其他工具和方法相比，它涉及更多的管理开销。

总而言之，OpenSSH 是隧道传输来自特定主机上运行的特定应用程序的流量的良好工具；它可以以这种方式用于远程访问和点对点 VPN 场景。但是，对于隧道传输远程网络或用户之间的所有流量，它的用处较小。

有关使用 OpenSSH 进行端口转发的更多信息，请参阅 ssh(1) 和 sshd_config(5) 手册页。

从概念上讲，Stunnel（一种 SSL 包装器）提供与 SSH 端口转发等效的功能。Stunnel 是当今大多数 Linux 发行版上的标准软件包。

Stunnel 和 SSH 之间的主要区别在于 Stunnel 的功能要有限得多； 它所做的 就是加密端口转发。此外，由于 Stunnel 实际上是 OpenSSL 的一种前端，因此 Stunnel 要求您配置和安装数字证书，这可能会抵消其某些简单性。否则，Stunnel 与 OpenSSH 共享作为 VPN 工具的局限性。

有关配置和使用 Stunnel 的信息，请参阅 stunnel(8) 手册页、Stunnel 网站以及我的文章“使用 Stunnel 修复明文网络应用程序”（LJ，2004 年 9 月）。

OpenVPN 是一种基于 SSL/TLS 的用户空间 VPN 工具，它将 VPN 端点之间的所有流量封装在普通的 UDP 或 TCP 数据包中（普通是指它们不需要对内核的 IP 堆栈进行任何修改）。创建 OpenVPN 是因为其作者 James Yonan 认为，世界需要一种比 IPSec 更简单的替代方案。

由于不需要特殊的内核模块或修改，OpenVPN 完全在用户空间中运行，这使得它比 IPSec 实现更容易跨操作系统移植。并且，通过使用标准的 OpenSSL 库，OpenVPN 像 Stunnel 一样，最大限度地减少了重复发明轮子。与 CIPE 和 tinc VPN 软件包（见下文）中使用的自制加密系统不同，OpenVPN 的所有关键操作都由 OpenSSL 处理。OpenSSL 本身当然不是完美无缺的，但它一直在接受安全漏洞的严格审查，并由一些开源社区最优秀的加密程序员维护。

OpenVPN 非常适合点对点 VPN，但在 2.0 版本（在撰写本文时，2004 年 11 月仍处于 beta 测试阶段）之前，OpenVPN 只能在给定的侦听端口上容纳单个隧道。如果您想使用 OpenVPN 为十个不同的用户提供远程访问 VPN 隧道，则需要运行十个不同的 OpenVPN 侦听器，每个侦听器都使用自己的 UDP 端口，例如 UDP 10201、UDP 10202 和 UDP 10203 以及另外七个。因此，如果您想将 OpenVPN 用于远程访问 VPN，除非您只有少数用户，否则您会更喜欢 OpenVPN 2.0（即使处于 beta 状态）。

SuSE Linux 9.1 以及可能的其他发行版都包含 OpenVPN。有关配置信息和最新的 OpenVPN 软件，请参阅 OpenVPN 网站。

IPSec 不是 Internet 上使用的唯一低级 VPN 协议。Microsoft 的点对点隧道协议 (PPTP) 也有其追随者，主要是因为它自 Windows NT 4.0 以来一直是 Microsoft 服务器操作系统的标准组件，并且与只能隧道传输 IP 数据包的 IPSec 不同，PPTP 不仅可以用于隧道传输 IP，还可以用于隧道传输其他协议，例如 NETBEUI 和 IPX/SPX。

Linux 对 PPTP 的支持有两种形式，服务器端的 PoPToP 和客户端的 Linux PPTP 客户端。

尽管隧道传输非 IP 协议非常方便，并且 Windows 服务器非常普及，但 PPTP 存在一个大问题。当 Bruce Schneier 和 Dr Mudge 在 1998 年分析 Windows NT 4.0 的 PPTP 实现时，他们发现了严重的安全漏洞，这些漏洞仅在不久之后发布的 MSCHAPv2 中得到部分缓解。MSCHAP 是 PPTP 依赖的身份验证协议；它是 Schneier 和 Mudge 发现的最严重漏洞的来源。Schneier 有一个专门介绍他们分析的网页（请参阅资源）。

Schneier 和 Mudge 分析了 Windows NT 4.0；那么 Linux PoPToP 服务器呢？根据 PoPToP 网站（在“PoPToP 问答”中）：“PoPToP 遭受与 NT 服务器相同的安全漏洞（这是因为它与 Windows 客户端一起运行）。”

我不建议使用 PPTP，除非您可以将 PPTP 服务器和所有 PPTP 客户端配置为使用 MSCHAPv2（并非所有 Windows 版本都支持 MSCHAPv2），并且您正在尝试做一些 IPSec 根本无法完成的事情。IPSec 的设计要好得多，并且已被证明更安全。此外，非 IP 网络协议不像以前那么重要了；Windows 和 Novell Netware 都可以通过 IP 完成所有操作。

我不会说“您不能使用 PPTP，因为它很糟糕”。正如我上个月所论证的那样，安全是关于风险管理，而不是寻求某种纯粹安全的乌托邦状态。在您阅读了 Schneier 和 Mudge 的争议、Microsoft 的回应和 MSCHAPv2 之后，并在您仔细检查了您特定组织的需求和能力之后，您可能会认为对于您来说，PPTP 代表了安全性和功能之间的合理折衷——只是不要告诉任何人 我 说您应该使用它！

此处值得一提的其他三个 Linux VPN 工具，因为您偶尔会看到对它们的引用。其中两个我不建议使用，第三个我不确定。

CIPE 和 vtun 在概念上与 OpenVPN 相似。它们将流量封装到加密的 UDP 或 TCP 数据包中。但是，与 OpenVPN 不同，它们使用自制加密系统而不是 OpenSSL。也就是说，它们确实使用了标准的加密算法，例如 Blowfish 和 MD5，但在自定义实现中（会话密钥生成、用户身份验证等）。由于实现是密码编程中最困难的部分之一，因此这样做很危险，并且密码学家 Peter Gutmann 确实在 CIPE 和 vtun 中都发现了严重缺陷。

据我所知，在任何一种情况下，Gutmann 识别出的缺陷都没有得到修复。而且 CIPE 和 vtun 似乎都不再处于积极开发中（CIPE 肯定不是），这足以避免任何安全应用程序，除非该应用程序是 Linux 发行版的一部分，并且其打包者自己提供补丁。因此，我不建议使用 CIPE 或 vtun。

tinc，像 CIPE 和 vtun 一样，使用自定义加密实现将 VPN 流量封装在加密的 UDP 数据包中。并且像这些软件包一样，Gutmann 在 tinc 中发现了缺陷，与我之前提到的分析相同。但是，与 CIPE 和 vtun 不同，tinc 的开发人员以可信的方式回应了 Gutmann 的发现；至少从我的角度来看（IANAC——也就是说，“我不是密码学家”），他们似乎对他们在做什么有所了解。

我让您自己查看 tinc 网站，阅读 Gutmann 的页面（该页面远非一份严肃的研究报告），在 Google 上搜索 Gutmann 声明的后果，并自行决定 tinc 看起来是否正是您一直在寻找的东西，或者更像是一种不合理的风险，因为 OpenS/WAN 和 OpenVPN 的可用性和质量都很高。

最后，简要介绍一下许多商业 VPN 产品支持的一种流行的新的方法 SSL-VPN。SSL-VPN 的工作方式实际上与 Stunnel 和 SSH 端口转发相同。它在每个服务、每个服务器的基础上而不是在电路级别隧道传输网络事务。但是，与其他方法不同，SSL-VPN 产品为最终用户提供了一个集中的 Web 界面，其中 VPN 服务器托管的所有可用服务器/服务都列为超链接。当用户单击链接时，通常会下载一个 Java 小程序，该小程序充当应用程序客户端软件。

我见过的 SSL-VPN 服务器产品都是专有的，但由于客户端通常是跨平台的，用 Java 编写，因此 Linux 系统可以充当 SSL-VPN 客户端。

FreeS/WAN 和 OpenS/WAN（最好是后者）以及 IPSec 可能是 Linux 工具箱中最安全和最强大的 VPN 工具。OpenVPN 似乎是一种更简单，但未经充分审查的替代方案。当封装少量特定应用程序显得过分时，OpenSSH 和 Stunnel 提供了方便的单点解决方案。还有其他 Linux VPN 工具可用，但有些已被证明是危险的，而对于其他工具，目前尚无定论。哪种 VPN 工具最适合您？显然，在不了解您的特定需求和资源的情况下，我无法告诉您。但是，我希望这篇简短的概述至少为您提供了一个有用的起点。

本文资源： www.linuxjournal.com/article/7923。