实现 Office 365 的 VPN 拆分隧道

多年来，企业一直在使用 VPN 来支持用户的远程体验。 虽然核心工作负载保持在本地，但通过公司网络上的数据中心路由的远程客户端的 VPN 是供远程用户访问公司资源的主要方法。 为保证这些连接的安全性，企业将沿 VPN 路径构建网络安全解决方案层。 这样做是为了保护内部基础结构和保护外部网站的移动浏览，方法是将流量重新路由到 VPN，然后通过本地 Internet 外围设备路由出去。 VPN、网络外围和相关的安全基础结构通常是针对特定的流量构建和扩展的，通常大多数连接都是从公司网络内部发起的，并且大多数连接都位于内部网络边界内。

在相当长的一段时间内，只要远程用户的并发规模适中且遍历 VPN 的流量较低，那么所有来自远程用户设备的连接都被路由回本地网络的 VPN 模型（这称为强制隧道）基本上是可持续的。 一些客户甚至在他们的应用从企业外围转移到公共 SaaS 云之后，仍继续将 VPN 强制隧道用作现状， Office 365 就是一个很好的例子。

将强制隧道 VPN 用于连接分布式和性能敏感云应用程序是非常不理想的，但是这种负面影响可能已经被一些企业所接受，从而从安全的角度维持现状。 下面是此场景的一个示例图：

这个问题多年来一直在加剧，许多客户报告了网络流量模式的重大转变。 过去停留在本地的流量现在连接到外部云终结点。 许多 Microsoft 客户报告，以前大约 80% 的网络流量都来自内部（上图中用虚线表示）。 到 2020 年，随着他们将主要的工作负载转移到云上，这一数字现在约为 20% 或更低，这些趋势在其他企业中并不罕见。 随着时间的推移和云历程的发展，上述模型变得愈加累赘且不可持续，这使得组织在迁移到以云为中心的世界时的敏捷度受到影响。

全球 COVID-19 危机升级了此问题，需要立即修正。 确保员工安全的需要对企业 IT 部门提出了前所未有的要求，要求他们支持大规模在家办公的工作效率。 Microsoft Office 365 非常适合帮助客户满足这一要求，但在家办公的用户的高并发性会产生大量的 Office 365 流量，如果通过强制隧道 VPN 和本地网络外围进行路由，就会导致流量迅速饱和，且运行的 VPN 基础结构会出现容量不足的情况。 在此新情况中，使用 VPN 来访问 Office 365 不再只是性能障碍，而是一堵不仅会影响 Office 365 还会影响关键业务操作的硬墙，这些业务操作仍需依赖于 VPN 才能进行。

多年来，Microsoft 一直与客户和更广泛的行业紧密协作，从我们自己的服务中为这些问题提供有效的新式解决方案，并与行业最佳做法保持一致。 Office 365 服务的连接原则旨在高效地为远程用户工作，同时仍允许组织保持安全性并控制其连接。 还可以通过有限的工作非常快速地实现这些解决方案，但对上述问题有着重大的积极影响。

Microsoft 建议的优化远程工作者连接策略主要是通过几个简单的步骤快速缓解传统方法的问题，并提供高性能。 以下步骤针对少数跳过瓶颈 VPN 服务器的已定义终结点调整旧 VPN 方法。 可在不同的层应用等效的或甚至是更高级的安全模型，而无需在公司网络出口保护所有流量。 在大多数情况下，可以在数小时内有效实现此功能，然后可根据需要以及时间允许的情况下扩展到其他工作负载。

常见 VPN 方案

在下面的列表中，你将看到企业环境中最常见的 VPN 方案。 大多数客户通常运行模型 1（VPN 强制隧道）。 本节将帮助你快速安全地过渡到模型 2，该模型可以相对轻松地实现，并且在网络性能和用户体验方面有着巨大优势。

1. VPN 强制隧道

这是大多数企业客户最常用的入门方案。 使用强制 VPN 意味着无论终结点是否位于公司网络内，100% 的流量都将定向到公司网络。 然后，任何外部 (Internet) 限制流量（如 Office 365 或 Internet 浏览）都会从本地安全设备（如代理）中回流。 在目前近 100% 的用户都在远程工作的情况下，这种模式会因此给 VPN 基础结构带来极高的负载，很可能会显著降低所有公司流量的性能，从而在危机时刻影响企业的高效运营。

2. VPN 强制隧道（有几个受信任的异常）

对于企业运营来说，该模型的运行效率要高得多，因为它允许少量高负载和高延迟敏感的受控和定义终结点绕过 VPN 隧道，直接进入本例中的 Office 365 服务。 这极大地提高了卸载服务的性能，还减少了 VPN 基础结构的负载，从而允许仍然需要它的元素以更低的资源争用进行操作。 本文将针对这个模型重点介绍如何帮助实现过渡，因为它允许快速采取简单的已定义操作，同时生成大量积极的成果。

3. VPN 强制隧道（有多个例外）

第三种模型拓宽了模型 2 的范围，它不是直接发送一小组已定义的终结点，而是将所有流量发送到受信任的服务（如 Office 365、SalesForce 等）。 这可进一步减少公司 VPN 基础结构的负载，并提高已定义服务的性能。 由于此模型很可能需要更多时间来评估实现的可行性，因此，一旦模型 2 成功就位，就可以在不久后迭代执行这一步骤。

4. VPN 选择性隧道

此模型与第三个模型相反，因为只有标识为具有公司 IP 地址的流量才通过 VPN 隧道发送，因此 Internet 路径是其他所有流量的默认路由。 此模型要求组织能够很好地适应零信任路径，以便能够安全地实现此模型。 应注意的是，此模型或某些变体可能随着时间的推移而成为必要的默认模型，因为越来越多的服务将从公司网络移动到云中。 Microsoft 在内部使用此模型；有关 Microsoft 实现 VPN 拆分隧道的更多信息，请参阅运行 VPN：Microsoft 如何让远程工作人员互联。

5. 无 VPN

第 2 种模型的更高级版本，其中任何内部服务都是通过新式安全方法或 SDWAN 解决方案发布的，如 Azure AD 代理、MCAS、Zscaler ZPA 等。

实现 VPN 拆分隧道

在本节中，你将在常见 VPN 方案部分找到将 VPN 客户端体系结构从 _VPN 强制隧道_迁移到 VPN 强制隧道（有几个受信任的异常）、VPN 拆分隧道模型 #2 所需的简单步骤。

下图显示了建议的 VPN 拆分隧道解决方案的工作原理：

1. 标识要优化的终结点

在 Office 365 URL 和 IP 地址范围主题中，Microsoft 明确标识需优化的关键终结点，并将其分类为“优化”****。 目前只有 4 个需要优化的 URL 和 20 个 IP 子网。 这一小组的终结点约占 Office 365 服务流量的 70% – 80%，包括延迟敏感终结点（如 Teams 媒体终结点）。 实际上，这就是我们需要特别关注的流量，该流量还会对传统网络路径和 VPN 基础结构施加难以置信的压力。

此类别中的 URL 具有以下特征：

• 为 Microsoft 拥有和托管的终结点，托管在 Microsoft 基础结构上
• 提供了 IP
• 低更改率，预计仍保持较小数量（目前有 20 个 IP 子网）
• 带宽和/或延迟敏感
• 可在服务中提供所需的安全元素，而不是在网络上内联
• 约占 Office 365 服务流量的 70-80%

有关 Office 365 终结点及其分类和管理方式的详细信息，请参阅管理 Office 365 终结点一文。

优化 URL

可在下表找到当前的优化 URL。 在大多数情况下，只需在浏览器 PAC 文件中使用 URL 终结点，其中终结点被配置为直接发送，而不是发送到代理。

在上面的示例中，应将租户替换为 Office 365 租户名称。 例如，contoso.onmicrosoft.com 将使用 contoso.sharepoint.com 和 constoso-my.sharepoint.com。

优化 IP 地址范围

在编写这些终结点对应的 IP 范围时，如下所示。 强烈建议使用如本例所示的脚本，Office 365 IP 和 URL Web 服务或 URL/IP 页，以便在应用配置时检查是否有任何更新，并定期制定相应的策略。

104.146.128.0/17
13.107.128.0/22
13.107.136.0/22
13.107.18.10/31
13.107.6.152/31
13.107.64.0/18
131.253.33.215/32
132.245.0.0/16
150.171.32.0/22
150.171.40.0/22
191.234.140.0/22
204.79.197.215/32
23.103.160.0/20
40.104.0.0/15
40.108.128.0/17
40.96.0.0/13
52.104.0.0/14
52.112.0.0/14
52.96.0.0/14
52.120.0.0/14

2. 通过 VPN 优化对这些终结点的访问

我们已确定这些关键终结点，现在需要将其从 VPN 隧道移出，并允许它们使用用户的本地 Internet 连接直接连接到服务。 完成此操作的方式将因使用的 VPN 产品和计算机平台而异，但大多数 VPN 解决方案将允许简单配置策略来应用此逻辑。 有关 VPN 平台特定的拆分隧道指南，请参阅常见 VPN 平台的操作指南。

如果要手动测试解决方案，可执行以下 PowerShell 示例，以在路由表级别模拟解决方案。 本例将每个 Teams 媒体 IP 子网的路由添加到路由表中。 可以在之前和之后测试 Teams 媒体性能，并观察指定终结点路由的差异。

示例：将 Teams 媒体 IP 子网添加到路由表

$intIndex = "" # index of the interface connected to the internet
$gateway = "" # default gateway of that interface
$destPrefix = "52.120.0.0/14", "52.112.0.0/14", "13.107.64.0/18" # Teams Media endpoints
# Add routes to the route table
foreach ($prefix in $destPrefix) {New-NetRoute -DestinationPrefix $prefix -InterfaceIndex $intIndex -NextHop $gateway}

在上面的脚本中，$intIndex 是连接到 Internet 的接口索引（可通过在 PowerShell 中运行 get-netadapter 找到；查找 ifIndex 的值），$gateway 是该接口的默认网关（可通过在命令提示符中运行 ipconfig 或在 PowerShell 中运行 (Get-NetIPConfiguration | Foreach IPv4DefaultGateway).NextHop 找到）。

添加路由后，可通过在命令提示符或 PowerShell 中运行 route print 来确认路由表是否正确。 输出应包含添加的路由，显示接口索引（本例为 22）和该接口的网关（本例为 192.168.1.1）：

若要在“优化”类别中添加所有当前 IP 地址范围的路由，可使用以下脚本变体查询 Office 365 IP 和 URL Web 服务，以获取当前优化 IP 子网集合并将其添加到路由表。

示例：将所有优化子网添加到路由表

$intIndex = "" # index of the interface connected to the internet
$gateway = "" # default gateway of that interface
# Query the web service for IPs in the Optimize category
$ep = Invoke-RestMethod ("https://endpoints.office.com/endpoints/worldwide?clientrequestid=" + ([GUID]::NewGuid()).Guid)
# Output only IPv4 Optimize IPs to $optimizeIps
$destPrefix = $ep | where {$_.category -eq "Optimize"} | Select-Object -ExpandProperty ips | Where-Object { $_ -like '*.*' }
# Add routes to the route table
foreach ($prefix in $destPrefix) {New-NetRoute -DestinationPrefix $prefix -InterfaceIndex $intIndex -NextHop $gateway}

如果无意中添加了错误参数的路由，或者只是希望还原所做的更改，则可以使用以下命令删除刚添加的路由：

foreach ($prefix in $destPrefix) {Remove-NetRoute -DestinationPrefix $prefix -InterfaceIndex $intIndex -NextHop $gateway}

应配置 VPN 客户端，以便优化 IP 的流量以此方式路由。 这样，流量就可以利用本地 Microsoft 资源（如 Office 365 Service Front Door (例如 Azure Front Door)），这些资源将以尽可能接近用户的方式提供 Office 365 服务和连接终结点。 这使我们能够向全球各地的用户提供极高的性能级别，并充分利用 Microsoft 的世界级全球网络，这种情况极可能在用户直接出口的几毫秒内发生。

配置和保护 Teams 媒体流量

一些管理员可能需要更详细的信息，了解如何在使用拆分隧道模型的 Teams 中进行呼叫流操作，以及如何保护连接。

配置

对于通话和会议，只要所需的针对 Teams 媒体的优化 IP 子网在路由表中，那么当 Teams 调用 GetBestRoute 方法来确定应将哪个接口用于特定目标时，将为上面列出的 Microsoft IP 块中的 Microsoft 目标返回本地接口。

某些 VPN 客户端软件允许基于 URL 进行路由操作。 但是，Teams 媒体流量没有与之关联的 URL，因此必须使用 IP 子网来控制此流量路由。

在某些情况下（通常与 Teams 客户端配置无关），即使有正确的路由，媒体流量仍会遍历 VPN 隧道。 如果遇到这种情况，只需使用防火墙规则来阻止 Teams IP 子网或端口使用 VPN。

信令流量是通过 HTTPS 执行的，它不像媒体流量那样对延迟敏感，并在 URL/IP 数据中标记为允许，因此如果需要，可以安全地通过 VPN 客户端进行路由。

安全性

避免拆分隧道的一个常见理由是这样做不太安全，也就是说， 任何不通过 VPN 隧道的流量都将无法从应用到 VPN 隧道的任何加密方案中受益，因此安全性较低。

对此的主要反对意见是，媒体流量已经通过_安全实时传输协议 (SRTP)_ 进行了加密，该协议是实时传输协议 (RTP) 的一个配置文件，它为 RTP 流量提供保密性、身份验证和重播攻击保护。 SRTP 本身依赖于随机生成的会话密钥，该密钥通过 TLS 安全信令通道进行交换。 本安全指南中详细介绍了这一点，但主要部分是媒体加密。

媒体流量是使用 SRTP 加密的，SRTP 使用安全随机数生成器生成的会话密钥，并使用信令 TLS 通道进行交换。 此外，在中介服务器和其内部下一个跃点之间的双向媒体也使用 SRTP 进行加密。

Skype for Business Online 生成用户名/密码，可用于通过_围绕 NAT 使用中继遍历 (TURN)_ 来安全访问媒体中继。 媒体中继通过 TLS 安全 SIP 信道交换用户名/密码。 值得注意的是，即使可使用 VPN 隧道将客户端连接到公司网络，但当流量离开公司网络以访问服务时，仍需以其 SRTP 形式流动。

有关 Teams 如何减少常见安全问题（如语音或 NAT 的会话遍历实用工具 (STUN) 放大攻击）的信息，可参阅本文。

还可以阅读有关远程工作场景中的新式安全控制：安全专业人员和 IT 人员在当前独特的远程工作场景中实现新式安全控制的替代方法（Microsoft 安全团队博客）

测试

策略准备就绪后，应确认其是否按预期工作。 可通过多种方法来测试路径是否已正确设置为使用本地 Internet 连接：

• 运行 Microsoft 365 连接测试，这将为你运行连接测试，包括上面所述的跟踪路由。 此外，我们还将 VPN 测试添加到此工具中，这也将提供一些额外的见解。
• 对于拆分隧道范围内的终结点的简单 tracert，应显示所采用的路径，例如：
  PowerShell复制

  tracert worldaz.tr.teams.microsoft.com
  

  然后，你将看到一个通过本地 ISP 到此终结点的路径，该路径应解析为我们为拆分隧道配置的 Teams 范围内的 IP。

• 以使用 Wireshark 之类的工具进行网络捕获为例。 在呼叫期间筛选 UDP，应看到流量流向 Teams 优化范围中的 IP。 如果 VPN 隧道正用于此流量，则跟踪中将不会显示媒体流量。

其他支持日志

如果需要更多数据来排除故障，或正在请求 Microsoft 支持部门的协助，获取以下信息可帮助你加快查找解决方案。 Microsoft 支持的基于 TSS Windows CMD 的通用故障排除脚本工具集可帮助你以简单的方式收集相关日志。 可在以下网址找到所使用的工具和说明：https://aka.ms/TssTools.

适用于常见 VPN 平台的操作指南

本节提供了一些链接，这些链接提供了实现 Office 365 流量（来自该领域中最常见的合作伙伴）的拆分隧道的详细指南。 我们将在其他指南推出时添加这些指南。

• Windows 10 VPN 客户端：使用本机 Windows 10 VPN 客户端优化面向远程工作者的 Office 365 流量
• Cisco Anyconnect：优化 Office365 的 Anyconnect 拆分隧道
• Palo Alto GlobalProtect：通过 VPN 拆分隧道排除访问路由优化 Office 365 流量
• F5 Networks BIG-IP APM：使用 BIG-IP APM 通过 VPN 优化远程访问 Office 365 流量
• Citrix 网关：优化 Office365 Citrix 网关 VPN 拆分隧道
• Pulse Secure：VPN 隧道：如何配置拆分隧道以排除 Office365 应用程序

常见问题

Microsoft 安全团队发布了一篇文章，概述了安全专业人员和 IT 人员可在当前独特的远程工作场景中实现新式安全控制的关键方法。 此外，下面是有关此主题的一些常见客户问题和解答。

我如何阻止用户访问我不信任的其他租户（他们可能会泄漏数据）？

答案是称为租户限制的功能。 身份验证流量不大，对延迟也不是特别敏感，因此可通过 VPN 解决方案发送到应用此功能的本地代理。 此处保留了受信任租户的允许列表，如果客户端尝试获取不受信任的租户的令牌，代理将拒绝该请求。 如果租户受信任，则在用户具有正确的凭据和权限的情况下，令牌可供访问。

因此，即使用户可以通过 TCP/UDP 连接到上述标记为“优化”的终结点，但若没有有效的令牌来访问所涉及的租户，他们也无法登录和访问/移动任何数据。

此模型是否允许访问诸如个人 OneDrive 帐户之类的使用者服务？

否，Office 365 终结点不同于使用者服务（以 Onedrive.live.com 为例），因此拆分隧道将不允许用户直接访问使用者服务。 流向使用方终结点的流量将继续使用 VPN 隧道，并且现有策略将继续生效。

如果流量不再流经本地解决方案，我该如何应用 DLP 并保护我的敏感数据？

为帮助防止意外泄露敏感信息，Office 365 提供了一组丰富的内置工具。 可使用 Teams 和 SharePoint 的内置 DLP 功能来检测未恰当存储或共享的敏感信息。 如果一部分远程工作策略涉及到自带设备办公 (BYOD) 策略，则可以使用条件访问应用控制来防止将敏感数据下载到用户的个人设备

如何在用户直接连接时评估和保留用户身份验证的控制权？

除了问题 1 中提到的租户限制功能之外，还可以应用条件访问策略来动态评估身份验证请求的风险并做出相应的反应。 Microsoft 建议在一段时间内实现零信任模型，我们可以使用 Azure AD 条件访问策略在移动和以云为中心的世界保持控制。 可使用条件访问策略对身份验证请求是否成功作出实时决策，具体取决于以下诸多因素：

• 设备，设备是否已知/受信任/已加入域？
• IP – 身份验证请求是否来自已知公司 IP 地址？ 或者来自不信任的国家/地区？
• 应用程序 – 用户是否有权使用此应用程序？

然后，我们可以根据这些策略触发批准、触发 MFA 或阻止身份验证等策略。

如何防范病毒和恶意软件？

同样，Office 365 为服务自身各层中标记为“优化”的终结点提供了保护，本文档对此进行了概述。 如上所述，在服务本身中提供这些安全元素要比在可能不完全理解协议/流量的设备上尝试执行此操作要有效得多。默认情况下，SharePoint Online 会自动扫描已知恶意软件的文件上传

对于上面列出的 Exchange 终结点，Exchange Online Protection 和 Office 365 高级威胁防护在为访问服务的流量提供安全方面做得很好。

除了优化流量外，我是否可以直接发送更多流量？

应优先考虑标记为优化的终结点，因为这些终结点将为低级别的工作提供最大好处。 但是，如果需要，需要提供标记为“允许”的终结点服务才能工作，并为终结点提供 IP，以便在需要时使用。

此外，还有许多供应商提供了名为安全 Web 网关的基于云的代理/安全解决方案，它们为常规 Web 浏览提供了中心安全、控制和企业策略应用程序。 如果这些解决方案高度可用、具备高性能，且预配为接近用户（通过允许从接近用户的基于云的位置提供安全 Internet 访问），则它们可以在以云为中心的世界很好地工作。 这将消除通过 VPN/公司网络执行回流以便正常浏览流量的需要，同时仍允许中央安全控制。

然而，即使就地使用这些解决方案，Microsoft 仍强烈建议将标记为“优化”的 Office 365 流量直接发送到服务。

有关允许直接访问 Azure 虚拟网络的指南，请参阅使用 Azure VPN 网关点到站点进行远程工作一文。

为什么需要端口 80？ 流量是否明文发送？

端口 80 仅用于重定向到端口 443 会话之类的操作，不会通过端口 80 发送或访问任何客户数据。 此文概述了 Office 365 中传输和静止数据的加密，这篇文章则概述了如何使用 SRTP 来保护 Teams 媒体流量。

此建议是否适用于使用 Office 365 全球实例的中国用户？

否，不适用。 在上述建议中，要注意连接到 Office 365 全球实例的中国用户。 由于该区域会经常出现跨境网络拥挤现象，因此直接 Internet 出口性能可能会有变化。 该区域中的大多数客户都使用 VPN 将流量引入公司网络，并利用其经授权的 MPLS 专线或类似于通过优化路径的国家/地区之外的出口。 面向中国用户的 Office 365 性能优化一文对此进行了进一步的概述。

相关主题

概述：Office 365 的 VPN 拆分隧道

面向中国用户的 Office 365 性能优化

安全专业人员和 IT 人员在当前独特的远程工作场景中实现新式安全控制的替代方法（Microsoft 安全团队博客）

增强 Microsoft 的 VPN 性能：使用 Windows 10 VPN 配置文件以允许自动打开连接

运行 VPN：Microsoft 如何让远程工作人员互联

Office 365 网络连接原则

评估 Office 365 网络连接

Office 365 网络和性能优化