在 亚马逊云科技 上部署微软永远在线 VPN

作者：迈克尔·斯彭斯 | 2023 日

在这篇博客文章中，我将详细介绍如何在 亚马逊云科技 上创建经济高效、安全且具有弹性的 VPN 远程访问架构。随着全职远程员工和移动工作人员人数的增加，对远程访问的要求已从一项不错的功能转变为在停机时可能产生重大财务影响的功能。传统上，在数据中心运行的设备提供远程访问，这使得提高远程访问服务的弹性变得昂贵，有时甚至在技术上不可行。由于已经在 亚马逊云科技 中部署了其他任务关键型工作负载，企业现在希望将其远程访问工作负载迁移到 亚马逊云科技 云中，以利用 亚马逊云科技 提供的灵活性。

远程访问服务的基本组件包括安装在最终用户设备上的 VPN 服务器和一个 VPN 客户端应用程序。需要记住何时以及如何启动 VPN 连接可能会对最终用户的工作效率产生负面影响。在建立 VPN 连接之前，设备处于断开连接状态，这会影响企业 IT 监控和管理移动终端用户设备的能力。

为了解决这些问题，微软提供了一种技术解决方案，即Always O n VPN 。顾名思义，使用这项技术，VPN 连接始终处于开启状态，无需用户交互。在亚马逊弹性计算云（ 亚马逊 EC2 ）实例上运行的微软 Windows 服务器提供 Always On VPN 服务器后端。使用原生 Microsoft 堆栈，企业可以避免通常与传统 VPN 架构相关的额外的 VPN 许可成本。亚马逊云科技 服务提供了弹性的 VPN 服务器架构，可以承受单个 Amazon EC2 实例、整个可用区 (AZ) 或整个 亚马逊云科技 区域的故障。

解决方案概述

为了便于部署，目标是为所有客户端提供一个 VPN 配置。使用亚马逊云科技和微软技术的组合，我们可以实现这一目标。图 1 说明了在 亚马逊云科技 中运行的由此产生的 Always On VPN 架构。

  1. 亚马逊虚拟私有云 (VPC) V irtual Pri vate Cloud，其公有子网和私有子网分布在两个不同的区域。
  2. 运行具有路由和远程访问 ( RRA S )、网络策略服务器 ( NPS )、证书和域控制器角色的 Windows Server 2016 或更高版本的 Ama@@ zon EC2 实例。 RRAS 和 NPS 服务器使用 亚马逊云科技 网络负载均衡器 (NLB) 进行负载平衡。
  3. 连接到远程访问架构的客户端位于 VPC 外部，并通过公共互联网建立 VPN 连接。
Microsoft Always On VPN on AWS

图 1 — 永不停机的 VPN 架构

理查德·希克斯的 著作 《使用微软 Windows 10 和 Windows Server 2022 实现永不停机的 VPN：现代移动性 》完整解释了 Always On VPN。本书详细介绍了实施 Always On VPN 所需的 Microsoft 组件的确切配置细节。

解决方案演练

完成以下步骤，在 亚马逊云科技 上创建 Always On VPN 架构：

  • 配置微软 Windows 服务器角色。
  • 配置微软 Windows 客户端。
  • 创建 亚马逊云科技 配置。

配置微软 Windows 服务器角色

步骤 1：准备活动目录和 PKI 环境

Microsoft Active Directory 安全组为证书模板提供安全控制，并管理哪些用户和设备可以建立 VPN 连接。至少需要为 VPN 用户、VPN 设备和 NPS 服务器设置安全组。对于此解决方案，没有将 RRAS 服务器加入到 Active Directory 的技术要求，但根据组织政策，可能需要这样做。如果是，请为他们创建额外的安全组。

该解决方案严重依赖安全证书。微软指南《Alw ays On VPN 部署 》解释了如何创建所需的证书模板。这些模板包括 VPN (RRAS) 服务器、NPS 服务器、用户和设备的证书。由于安全套接字隧道协议 (SSTP) 使用 HTTPS 进行传输，因此公共或内部证书颁发机构 (CA) 应颁发相应的证书。如果内部 CA 颁发证书，则证书吊销列表 (CRL) 必须可供公众访问。该解决方案中的证书全部由在 亚马逊云科技 上的 2 级 Microsoft PKI 部署内部生成。亚马逊云科技 上的 Qu ickStart 微软公钥基础设施 提供了有关在 亚马逊云科技 上 运行微软 PKI 的更多详细信息。

查看此解决方案时，一些常见问题可能是 “我需要多少台 RRAS (VPN) 服务器？”以及 “我应该选择多少 EC2 实例大小？”。目前，尚未发布 RRAS 容量规划指南。有些组织通过 VPN 隧道的网络流量可能微乎其微，而其他组织可能要求所有远程访问流量通过 VPN 隧道。了解预期的网络流量将有助于确定容量需求。 Amazon EC2 实例网络带宽 文档解释了 Amazon EC2 实例系列的网络吞吐容量。

另一个考虑因素是环境中需要支持的连接总数。请注意，每个部署的客户端总共有 2 个连接，一个用于用户，一个用于设备。确定连接总数后，决定要分配的整个 VPC 客户端 IP 地址范围。每台 RRAS 服务器必须具有唯一的 DHCP CIDR IP 地址范围，才能分发给通过 VPN 连接的客户端，这些地址稍后将输入到 VPC 路由表中。将整个 VPC 客户端 CIDR 范围除以 RRAS 服务器的数量。有关分配给每台 RRAS 服务器的 VPC 客户端 CIDR 范围的示例，请参阅图 2。

步骤 2：创建 VPN (RRAS) 服务器配置

VPN (RRAS) Architecture

图 2 — 虚拟专用网络 (RRAS) 架构

在此示例中，要支持的客户机总数为 200。每个托管 RRAS 的亚马逊 EC2 实例可以处理多达 100 个连接。那么，为什么有 4 台服务器而不是只有 2 台呢？因为我们需要考虑解决方案的灵活性。如果我们遇到可用区完全故障，我们需要辅助可用区中的容量来处理所有客户端流量。此架构是使用可用区实现静态稳定性的一个示例。

我们使用以下配置将基于 Amazon EC2 的 RRAS 服务器放置到跨可用区和区域的公有子网中。

  1. 启动亚马逊 EC2 Windows Server 2022 实例并启用 RRAS 服务器角色（仅限 VPN）。
  2. 将 Amazon EC2 网络适配器 (ENI) 配置为禁用源/目标检查。
  3. 创建包含 TCP/443（ SSTP 连接 ）和 UDP 500/4500（ IKEv2 连接 ）的亚马逊 EC2 安全组，并将其分配给每个亚马逊 EC2 实例。
  4. 分配与外部 DNS 名称（例如 vpn.example.com）匹配的服务器证书，用于 SSTP 和 IKEv2 连接，并将它们放在本地计算机证书存储库中。在此示例中，RRAS 服务器未加入域，这需要将内部根目录和颁发机构 CA 导入到本地计算机存储中。使用 PowerShell 命令 Set-vpnAuthProtoco l 仅接受 来自内部 PKI 的证书。

除了分配给每台 RRAS 服务器的 DHCP 地址范围外，它们的配置是相同的。身份验证由 NPS 服务器使用 RADIUS 身份验证提供。RADIUS 服务器名称的值将是面向内部 AW S N LB 的 DN S 名称 。唯一允许的身份验证方法是可扩展身份验证协议 ( EAP )，并允许对IKE v2进行计算机认证身份验证。为 SSTP 连接生成的 SSL 证书在 SSL 证书绑定部分中指定。其他 VPN 优化和 PowerShell 脚本可以在 理查德·希克斯的 GitH ub 上找到。

步骤 3：创建 NPS 服务器配置

NP Architecture

图 3 — NPS 架构

NPS 服务器为通过 RRAS 服务连接的 VPN 客户端提供身份验证。图 3 说明了放置在私有子网中的 NPS 服务器。这些 NPS 服务器具有相同的配置，包括以下元素：

  1. 启动亚马逊 EC2 Windows Server 2022 实例并启用 NPS 服务器角色。
  2. 创建允许 RADIUS 流量使用 UDP 1812/1813 的 Amazon EC2 安全组，并将其分配给每个亚马逊 EC2 实例。
  3. 创建与面向内部 亚马逊云科技 NLB 的 DNS 名称相匹配的服务器证书。
  4. 在 NPS 服务器上，将每台 RRAS 服务器注册为 NPS 客户端。尽管 VPN EC2 实例将其的 RADIUS 流量定向到 亚马逊云科技 NLB，但 NPS 服务器仍会看到 VPN (RRAS) 服务器的 IPv4 主机地址。
  5. 将 NPS 服务器配置为仅允许使用 Microsoft Protected (PEAP) 的 VPN 用户的安全组。在一台 NPS 服务器上完成配置后，可以将配置 导出并导入 到其余 NPS 服务器中。
  6. 我们每个区域都有一个 亚马逊云科技 NLB，但只有一个自定义 DNS 名称。 微软 DNS 查询策略 记录用于指向每个地区的 亚马逊云科技 NLB。

微软 Windows 客户端配置

一旦工作站启动并建立网络连接，设备隧道就会建立。用户隧道是在用户登录工作站后建立的。这些配置文件可以使用微软端点管理器进行部署，也可以通过PowerShell进行部署，该配置文件由SCCM、Active Directory GPO或其他客户端部署管理工具部署。在客户端上执行以下步骤：

  1. 证书验证 -验证客户端工作站是否安装了用户和设备证书。设备证书将在本地计算机存储中找到，用户证书将在用户存储中找到。
  2. 用户隧道 — 使用提供 VPN 服务器 亚马逊云科技 NLB 的公有 DNS 名称的 Windows 内置 VPN 客户端创建 VPN 配置文件。类型为 SSTP，登录信息为微软保护版 EAP (PEAP)。已指定 NPS 自定义 DNS 名称和内部根 CA 证书。身份验证方法将是基于用户的证书，而不是用户名/密码组合。测试连接以确保连接成功。稍后将 导出该配置文件以部署 到所有设备。
  3. 设备隧道 — 设备隧道的设置与之类似，只是 VPN 类型为 IKEv2，并且可以选择使用计算机证书。

如果 VPN 连接成功，Windows 客户端将显示连接状态，如图 4 所示。

Client VPN Connection Status

图 4 — 客户端 VPN 连接状态

创建 亚马逊云科技 配置

该解决方案使用多种 亚马逊云科技 服务，包括 亚马逊 CloudFront、亚马逊 EC2 、网络负载均衡器 (NLB)、亚马逊 Route 53 、 Amazon S imple Storage Service ( Amazon S3) 和 VP C 路由 表。

第 1 步：使用亚马逊 CloudFront 和亚马逊 S3 配置微软 CRL

解决方案的所有元素都应该具有弹性。证书撤销列表 (CRL) 包含在已颁发证书的属性中。在通过 HTTP 建立 VPN 连接时，此 CRL 需要可供客户端使用。在本示例中，使用内部 Microsoft CA 来颁发证书。亚马逊CloudFront和亚马逊简单存储服务（Amazon S3）将为CRL的公开可用性提供弹性架构。

每当从 CA 发布新的 CRL 时，都会将新版本的 CRL 复制到主 Amazon S3 存储桶中。跨区域复制将对象复制到另一个区域的辅助 Amazon S3 存储桶。CloudFront 分配使用原始访问身份策略将 Amazon S3 存储桶置于前端。为确保仅返回最新的 CRL，已在 CloudFront 发行版上禁用缓存。Amazon S3 源设置在源组中，以在 CRL 分布层提供弹性。然后，亚马逊 Route 53 的 DNS 别名记录将指向 CloudFront 发行版。图 5 说明了 CloudFront 架构的设计：

CloudFront and S3 Architecture

图 5 — CloudFront 和 S3 架构

步骤 2：网络负载均衡器 (NLB) 配置

此架构使用 2 个 NLB。一个在 VPN (RRAS) 服务器外部，另一个用于 NPS 服务器内部。面向互联网的 NLB 监听端口 TCP/443 和 UDP 500/4500，这两个端口将流量定向到 RRAS 服务器。面向内部的 NLB 在 UDP 端口 1812/1813 上监听 RADIUS 流量。

步骤 3：VPC 路由表

客户端连接后，将从 RRAS 服务器上定义的静态池中获得一个 IPv4 地址。对于每个 VPN 客户端 CIDR 范围，VPC 路由表将包含一个指向分发这些地址的 RRAS 服务器的 ENI 的条目。然后，目标主机将知道如何将流量路由回 VPN 客户端。

第 4 步：亚马逊 Route 53 DNS 记录

为了防范区域故障，您需要在 Amazon Route 53 中创建主要 DNS 记录和故障转移记录集。创建 Route 53 DNS 别名记录是为了指向主要和次要区域中面向互联网的 NLB。有关更多信息，请参阅 Amazon Route 53 文档 中的 故障转移路由 。

Amazon Route 53 是弹性架构的关键组件，它将在区域完全中断时对客户端进行故障转移。亚马逊 Route 53 运行状况检查是使用亚马逊 Route 53 数据平面创建的。要了解更多信息，请参阅 使用 Amazon Route 53 创建灾难恢复机制 。

故障转移测试

该架构必须能够抵御单个 Amazon EC2 实例、可用区或整个区域的故障。通过有选择地关闭整个环境中的单个 Amazon EC2 服务器，可以测试这些故障转移场景。作为 Always On VPN 的一项功能，在这些故障转移场景中，VPN 客户端无需任何用户交互即可恢复并继续与 VPN 架构保持连接。

按照配置，该架构代表主动/被动配置。有可能使用其他 Amazon Route 53 路由策略（例如地理位置、延迟或加权）来创建主动/主动配置，同时仍能实现完整的区域故障转移。对整个区域进行故障转移所花费的时间要比在区域内进行故障转移花费的时间长得多。Amazon Route 53 别名记录的 TTL 为 60 秒，还有任何 DNS 缓存都在客户端。

结论

虽然我们无法控制系统何时会出现故障，但我们可以尽最大努力开发能够抵御整个系统的单个组件故障的架构。斯蒂芬·奥尔班在他的《 云端 前进》一书中 提到 “无动于衷 ” 的架构。这是思考云架构的好方法，其目标是从灾难恢复转向无动于衷的灾难。

随着远程工作人员数量的增加，提供远程访问是一项核心业务需求。对于安装了大量微软 Windows 10+ 客户端的组织来说，Windows 10+ 客户端使用 Always On VPN 的能力极大地提高了工作效率。使用 Always On VPN，每当设备脱离公司网络时，客户端将自动通过 VPN 连接进行隧道传输，无需用户交互或其他客户端 VPN 软件。

结合 亚马逊云科技 服务，可以为 亚马逊云科技 上的 Windows 10+ 客户端创建强大而有弹性的远程访问 Always On VPN 架构。在这篇博客文章中，我们探讨了这款 Always On VPN 架构的配置和要求。

准备好开始了吗？ 在 亚马逊云科技 云企业战略博客 和 亚马逊云科技 架构博客上阅读有关 A WS 上的 Microsoft 工作负载 和其他与迁移相关的博 客 文章的 更多信息。

想了解更多架构内容？ 亚马逊云科技 架构中心 提供参考架构图、经过审查的架构解决方案、 架构完善 的最佳实践、模式、图标等！

亚马逊云科技 可以帮助您评估贵公司如何充分利用云计算。加入数百万信任我们在云端迁移和现代化他们最重要的应用程序的 亚马逊云科技 客户的行列。要了解有关对 Windows 服务器或 SQL Server 进行现代化的更多信息，请访问 亚马逊云科技 上的 Windows 。 立即联系我们 ，开始您的现代化之旅。