实现适用于 Microsoft 365 的 ExpressRoute
本文适用于Microsoft 365 企业版。
适用于 Microsoft 365 的 ExpressRoute 为许多面向 Internet 的 Microsoft 365 服务提供了备用路由路径。 适用于 Microsoft 365 的 ExpressRoute 体系结构基于将已通过 Internet 访问的 Microsoft 365 服务的公共 IP 前缀播发到预配的 ExpressRoute 线路中，以便将这些 IP 前缀后续重新分发到网络中。 借助 ExpressRoute，你可以有效地为许多 Microsoft 365 服务启用通过 Internet 和 ExpressRoute 的多个不同路由路径。 网络上的这种路由状态可能会对内部网络拓扑的设计方式产生重大变化。
注意
我们不建议将 ExpressRoute 用于 Microsoft 365，因为它在大多数情况下不会为服务提供最佳连接模型。 因此，需要 Microsoft 授权才能使用此连接模型。 我们审查每个客户请求，并仅在极少数情况下授权适用于 Microsoft 365 的 ExpressRoute。 有关详细信息，请阅读 适用于 Microsoft 365 的 ExpressRoute 指南 ，并与你的工作效率、网络和安全团队一起对文档进行全面审查后，根据需要与 Microsoft 帐户团队协作提交异常。 尝试为 Microsoft 365 创建路由筛选器的未经授权的订阅将收到 错误消息。
必须仔细规划适用于 Microsoft 365 的 ExpressRoute 实现，以适应通过专用线路提供路由的网络复杂性，并将路由注入核心网络和 Internet。 如果你和你的团队未执行本指南中的详细规划和测试，则启用 ExpressRoute 线路时，你将遇到间歇性或完全断开与 Microsoft 365 服务的连接的风险。
若要成功实现，需要分析基础结构要求，完成详细的网络评估和设计，以分阶段且受控的方式仔细规划推出，并构建详细的验证和测试计划。 对于大型分布式环境，实现跨越几个月的情况并不少见。 本指南旨在帮助你提前规划。
大型成功的部署可能需要 6 个月的规划时间，并且通常包括组织中许多领域的团队成员，包括网络、防火墙和代理服务器管理员、Microsoft 365 管理员、安全性、最终用户支持、项目管理和执行人员赞助。 你在规划过程中的投资将降低遇到部署失败导致停机或复杂且昂贵的故障排除的可能性。
我们预计在开始本实施指南之前，将完成以下先决条件。
你已完成网络评估，以确定是否建议并批准 ExpressRoute。
你已选择 ExpressRoute 网络服务提供商。 查找有关 ExpressRoute 合作伙伴和对等互连位置的详细信息。
你已阅读并了解 ExpressRoute 文档 ，并且内部网络能够端到端满足 ExpressRoute 先决条件。
你的团队已阅读 、 上的所有公共指南和文档，并观看了第 9 频道上适用于 Microsoft 365 的 Azure ExpressRoute 培训系列，以了解关键技术详细信息，包括： https://aka.ms/erthttps://aka.ms/expressrouteoffice365
SaaS 服务的 Internet 依赖项。
如何避免非对称路由并处理复杂的路由。
如何合并外围安全性、可用性和应用程序级控制。
首先收集要求
首先确定计划在组织内采用哪些功能和服务。 你需要确定将使用不同 Microsoft 365 服务的哪些功能，以及网络上的哪些位置将托管使用这些功能的人员。 使用方案目录时，需要添加每个方案所需的网络属性;例如入站和出站网络流量流以及 Microsoft 365 终结点是否通过 ExpressRoute 提供。
若要收集组织的要求，请执行以下操作：
为组织正在使用的 Microsoft 365 服务编录入站和出站网络流量。 有关不同 Microsoft 365 方案所需的流的说明，请参阅 Microsoft 365 URL 和 IP 地址范围页面。
收集现有网络拓扑的文档，其中显示了内部 WAN 主干和拓扑、卫星站点连接、最后一英里用户连接、路由到网络外围出口点和代理服务的详细信息。
确定 Microsoft 365 和其他 Microsoft 服务将连接到的网络关系图上的入站服务终结点，其中显示了 Internet 和建议的 ExpressRoute 连接路径。
确定位置之间的所有地理用户位置和 WAN 连接，以及哪些位置当前具有 Internet 出口，以及建议哪些位置具有 ExpressRoute 对等互连位置的出口。
标识所有边缘设备（如代理、防火墙等），并编录其与通过 Internet 和 ExpressRoute 的流的关系。
记录最终用户是通过直接路由还是针对 Internet 和 ExpressRoute 流的间接应用程序代理访问 Microsoft 365 服务。
将租户的位置和满足位置添加到网络图。
估计从主要用户位置到 Microsoft 365 的预期和观察到的网络性能和延迟特征。 请记住，Microsoft 365 是一组全局分布式服务，用户将连接到可能与其租户位置不同的位置。 因此，建议通过 ExpressRoute 和 Internet 连接测量用户与 Microsoft 全球网络最近的边缘之间的延迟并对其进行优化。 可以使用网络评估中的发现结果来帮助完成此任务。
列出新的 ExpressRoute 连接需要满足的公司网络安全和高可用性要求。 例如，在发生 Internet 出口或 ExpressRoute 线路故障时，用户如何继续访问 Microsoft 365。
记录哪些入站和出站 Microsoft 365 网络流将使用 Internet 路径，哪些将使用 ExpressRoute。 用户地理位置的详细信息和本地网络拓扑的详细信息可能要求计划从一个用户位置到另一个用户位置不同。
编录出站和入站网络流量
为了最大程度地降低路由和其他网络复杂性，我们建议你仅将 ExpressRoute for Microsoft 365 用于网络流量流，这些流量流因法规要求或网络评估而需要通过专用连接。 此外，建议将 ExpressRoute 路由的范围暂存，并将出站和入站网络流量流作为实现项目的不同阶段。 仅为用户启动的出站网络流量部署适用于 Microsoft 365 的 ExpressRoute，并让入站网络流量流通过 Internet 离开，有助于控制拓扑复杂性的增加和引入更多非对称路由可能性的风险。
网络流量目录应包含本地网络与 Microsoft 之间将拥有的所有入站和出站网络连接的列表。
出站网络流量流是从本地环境（例如从内部客户端或服务器）启动连接的任何方案，其目标为 Microsoft 服务。 这些连接可以直接连接到 Microsoft 365 或间接连接，例如当连接通过代理服务器、防火墙或 Microsoft 365 路径上的其他网络设备时。
入站网络流量流是启动从 Microsoft 云到本地主机的连接的任何方案。 这些连接通常需要通过防火墙和其他安全基础结构，客户安全策略需要针对外部发起的流。
阅读确保路由对称部分，确定哪些服务将发送入站流量，并在 Microsoft 365 终结点参考文章中查找标记为适用于 Microsoft 365的 ExpressRoute 的列，以确定其余的连接信息。
对于需要出站连接的每个服务，需要描述该服务的计划连接，包括网络路由、代理配置、数据包检查和带宽需求。
对于需要入站连接的每个服务，需要一些其他信息。 Microsoft 云中的服务器将与本地网络建立连接。 为确保正确建立连接，需要描述此连接的所有方面，包括：将接受这些入站连接的服务的公共 DNS 条目、CIDR 格式的 IPv4 IP 地址、涉及哪些 ISP 设备以及如何处理这些连接的入站 NAT 或源 NAT。
无论入站连接是通过 Internet 还是 ExpressRoute 进行连接，都应查看这些连接，以确保未引入非对称路由。 在某些情况下，Microsoft 365 服务启动的入站连接的本地终结点可能还需要由其他 Microsoft 和非 Microsoft 服务访问。 为 Microsoft 365 目的启用到这些服务的 ExpressRoute 路由不会中断其他方案，这一点至关重要。 在许多情况下，客户可能需要对其内部网络（例如基于源的 NAT）实施特定更改，以确保来自 Microsoft 的入站流在启用 ExpressRoute 后保持对称。
下面是所需的详细级别示例。 在这种情况下，Exchange Hybrid 会通过 ExpressRoute 路由到本地系统。
| Connection 属性 | 值 |
|---|---|
| 网络流量方向 |
入境 |
| 服务 |
Exchange 混合 |
| 公共 Microsoft 365 终结点 (源) |
Exchange Online (IP 地址) |
| 公共本地终结点 (目标) |
5.5.5.5 |
| 公共 (Internet) DNS 条目 |
Autodiscover.contoso.com |
| 此本地终结点是否会由其他 (非 Microsoft 365) Microsoft 服务使用 |
否 |
| Internet 上的用户/系统是否会使用此本地终结点 |
是 |
| 通过公共终结点发布的内部系统 |
Exchange Server客户端访问角色 (本地) 192.168.101、192.168.102、192.168.103 |
| 公共终结点的 IP 播发 |
到 Internet：5.5.0.0/16 到 ExpressRoute：5.5.5.0/24 |
| 安全性/外围控制 |
Internet 路径：DeviceID_002 ExpressRoute 路径：DeviceID_003 |
| 高可用性 |
跨 2 条异地冗余/ExpressRoute 线路的主动/主动 - 芝加哥和达拉斯 |
| 路径对称控件 |
方法：源 NAT Internet 路径：源 NAT 入站连接到 192.168.5.5 ExpressRoute 路径：源 NAT 连接到 192.168.1.0 (芝加哥) 和 192.168.2.0 (达拉斯) |
下面是仅出站服务的示例：
| Connection 属性 | 值 |
|---|---|
| 网络流量方向 |
出站 |
| 服务 |
SharePoint |
| 本地终结点 (源) |
用户工作站 |
| 公共 Microsoft 365 终结点 (目标) |
SharePoint (IP 地址) |
| 公共 (Internet) DNS 条目 |
*.sharepoint.com (和更多 FQDN) |
| CDN 引荐 |
cdn.sharepointonline.com (和更多 FQDN) - 由 CDN 提供程序维护的 IP 地址) |
| IP 播发和 NAT 正在使用中 |
Internet 路径/源 NAT：1.1.1.0/24 ExpressRoute 路径/源 NAT：1.1.2.0/24 (芝加哥) 和 1.1.3.0/24 (达拉斯) |
| 连接方法 |
Internet：通过第 7 层代理 (.pac 文件) ExpressRoute：直接路由 (无代理) |
| 安全性/外围控制 |
Internet 路径：DeviceID_002 ExpressRoute 路径：DeviceID_003 |
| 高可用性 |
Internet 路径：冗余的 Internet 出口 ExpressRoute 路径：跨 2 条异地冗余 ExpressRoute 线路的主动/主动“热土豆”路由 - 芝加哥和达拉斯 |
| 路径对称控件 |
方法：所有连接的源 NAT |
具有区域连接的网络拓扑设计
了解服务及其关联的网络流量流后，可以创建一个网络关系图，其中包含这些新的连接要求，并说明使用适用于 Microsoft 365 的 ExpressRoute 的更改。 关系图应包括：
将从中访问 Microsoft 365 和其他服务的所有用户位置。
所有 Internet 和 ExpressRoute 出口点。
管理进出网络连接的所有出站和入站设备，包括路由器、防火墙、应用程序代理服务器和入侵检测/防护。
所有入站流量的内部目标，例如接受来自 ADFS Web 应用程序代理服务器的连接的内部 ADFS 服务器。
将播发的所有 IP 子网的目录
确定用户将从中访问 Microsoft 365 的每个位置，并列出将用于 ExpressRoute 的 meet-me 位置。
内部网络拓扑的位置和部分，从 ExpressRoute 中学到的 Microsoft IP 前缀将被接受、筛选并传播到其中。
网络拓扑应说明每个网段的地理位置，以及它如何通过 ExpressRoute 和/或 Internet 连接到 Microsoft 网络。
下图显示了用户将使用 Microsoft 365 的每个位置，以及到 Microsoft 365 的入站和出站路由播发。
对于出站流量，用户可通过以下三种方式之一访问 Microsoft 365：
通过加州人民的北美见面地点。
通过香港特别行政区为香港特别行政区人民提供会面地点。
通过互联网在孟加拉国，那里的人较少，没有提供 ExpressRoute 线路。
同样，来自 Microsoft 365 的入站网络流量以以下三种方式之一返回：
通过加州人民的北美见面地点。
通过香港特别行政区为香港特别行政区人民提供会面地点。
通过互联网在孟加拉国，那里的人较少，没有提供 ExpressRoute 线路。
确定适当的“满足我”位置
“满足我”位置的选择（ExpressRoute 线路将网络连接到 Microsoft 网络的物理位置）受用户从中访问 Microsoft 365 的位置的影响。 作为 SaaS 产品/服务，Microsoft 365 在 IaaS 或 PaaS 区域模型下运行的方式与 Azure 不同。 相反，Microsoft 365 是一组分布式协作服务，用户可能需要连接到跨多个数据中心和区域的终结点，这些终结点可能不一定位于托管用户租户的同一位置或区域中。
这意味着，在为 Microsoft 365 的 ExpressRoute 选择满足我位置时，你需要做出的最重要考虑是组织中的人员将从那里进行连接。 最佳 Microsoft 365 连接的一般建议是实现路由，以便用户对 Microsoft 365 服务的请求通过最短的网络路径传递到 Microsoft 网络，这通常也称为“热土豆”路由。 例如，如果大多数 Microsoft 365 用户位于一个或两个位置，则选择最靠近这些用户的位置的 meet-me 位置将创建最佳设计。 如果你的公司在许多不同的区域拥有大量用户，则可能需要考虑使用多个 ExpressRoute 线路和满足我的位置。 对于某些用户位置，Microsoft 网络和 Microsoft 365 的最短/最佳路径可能不是通过内部 WAN 和 ExpressRoute meet-me 点，而是通过 Internet。
通常，可以在一个区域中选择多个与用户相对邻近的会面地点。 填写下表以指导你的决策。
计划在加州和纽约的 ExpressRoute 会面地点
| 位置 |
人数 |
通过 Internet 流出到 Microsoft 网络的预期延迟 |
通过 ExpressRoute 到 Microsoft 网络的预期延迟 |
|---|---|---|---|
| Los Angeles |
10,000 |
~15 毫秒 |
大约 10 毫秒 (通过硅谷) |
| 华盛顿 |
15,000 |
~20 毫秒 |
大约 10 毫秒 (通过纽约) |
| 达拉斯 |
5,000 |
~15 毫秒 |
大约 40 毫秒 (通过纽约) |
一旦全球网络体系结构显示 Microsoft 365 区域、ExpressRoute 网络服务提供商满足我的位置，以及按位置列出的人员数量，就可用于确定是否可以进行任何优化。 它还可能显示全球发夹网络连接，其中流量路由到遥远的位置，以获取“我见面”位置。 如果发现全球网络上的发夹，则应在继续之前对其进行修正。 要么找到另一个满足我的位置，要么使用选择性的 Internet 突破流出点来避免发夹。
第一个关系图显示客户在北美中具有两个物理位置的示例。 可以查看有关 Office 位置、Microsoft 365 租户位置的信息，以及 ExpressRoute 满足我位置的多个选项。 在此示例中，客户已根据两个原则按顺序选择了 meet-me 位置：
最接近其组织中的人员。
最靠近托管 Microsoft 365 的 Microsoft 数据中心。
进一步扩展此概念，第二张图显示了一个示例，即面对类似信息和决策的跨国客户。 该客户在孟加拉国有一个小型办事处，只有一个10人的小型团队专注于在该地区扩大他们的足迹。 钦奈有一个见面地点和一个 Microsoft 数据中心，Microsoft 365 托管在金奈，所以见面地点是有意义的：然而，对于10人来说，额外的线路费用是沉重的。 查看网络时，需要确定跨网络发送网络流量所涉及的延迟是否比花费资金购买另一条 ExpressRoute 线路更有效。
或者，孟加拉国的 10 个人通过 Internet 发送到 Microsoft 网络的网络流量可能比在内部网络上路由的性能更好，如介绍图中所示，并在下面转载。
Create ExpressRoute for Microsoft 365 实施计划
实施计划应包含配置 ExpressRoute 的技术详细信息和在网络上配置所有其他基础结构的详细信息，如下所示。
规划在 ExpressRoute 和 Internet 之间拆分的服务。
规划带宽、安全性、高可用性和故障转移。
设计入站和出站路由，包括针对不同位置的正确路由路径优化
确定 ExpressRoute 路由将播发到网络中的距离，以及客户端选择 Internet 或 ExpressRoute 路径的机制是什么;例如，直接路由或应用程序代理。
规划 DNS 记录更改，包括 发件人策略框架 条目。
规划 NAT 策略，包括出站和入站源 NAT。
使用 Internet 和 ExpressRoute 网络路径规划路由
对于初始部署，建议使用 Internet 的所有入站服务（例如入站电子邮件或混合连接）。
规划最终用户客户端 LAN 路由，例如 配置 PAC/WPAD 文件、默认路由、代理服务器和 BGP 路由播发。
规划外围路由，包括代理服务器、防火墙和云代理。
规划带宽、安全性、高可用性和故障转移
Create每个主要 Microsoft 365 工作负载所需的带宽计划。 单独估计Exchange Online、SharePoint 和 Skype for Business Online 带宽要求。 可以使用我们为Exchange Online和Skype for Business提供的估算计算器作为起点;但是，需要具有代表性的用户配置文件和位置示例的试点测试才能充分了解组织的带宽需求。
将每个 Internet 和 ExpressRoute 出口位置的安全性处理方式添加到你的计划中，请记住，与 Microsoft 365 的所有 ExpressRoute 连接都使用公共对等互连，并且仍必须按照公司连接到外部网络的安全策略进行保护。
向计划添加详细信息，了解哪些人员将受到哪种类型的服务中断的影响，以及这些人如何能够以最简单的方式以满负荷完成工作。
规划带宽要求，包括抖动、延迟、拥塞和余量方面的Skype for Business要求
Skype for Business Online 还具有特定的额外网络要求，详见 Skype for Business Online 中的媒体质量和网络连接性能一文。
阅读 Azure ExpressRoute 的带宽规划部分。 与试点用户一起执行带宽评估时，可以使用我们的 Microsoft 365 性能优化指南（使用基线和性能历史记录）。
规划高可用性要求
Create高可用性计划来满足你的需求，并将其合并到更新的网络拓扑图中。 请阅读 使用 Azure ExpressRoute 实现高可用性和故障转移部分。
规划网络安全要求
Create满足网络安全要求的计划，并将其合并到更新的网络拓扑图中。 阅读 将安全控制应用于适用于 Microsoft 365 方案的 Azure ExpressRoute 部分。
设计出站服务连接
适用于 Microsoft 365 的 ExpressRoute 具有可能不熟悉的 出站 网络要求。 具体而言，表示用户和 Microsoft 365 网络并充当与 Microsoft 的出站网络连接的源终结点的 IP 地址必须遵循下面概述的特定要求。
终结点必须是注册到公司或运营商提供 ExpressRoute 连接的公共 IP 地址。
终结点必须播发到 Microsoft 并由 ExpressRoute 验证/接受。
终结点不得播发到具有相同或更多首选路由指标的 Internet。
终结点不得用于连接到未通过 ExpressRoute 配置的 Microsoft 服务。
如果网络设计不符合这些要求，则用户可能会遇到与 Microsoft 365 和其他 Microsoft 服务的连接失败的风险，因为路由黑色 holing 或非对称路由。 如果通过 ExpressRoute 路由到 Microsoft 服务的请求，但响应通过 Internet 路由回，反之亦然，并且响应由有状态网络设备（如防火墙）删除，则会出现这种情况。
可用于满足上述要求的最常见方法是使用源 NAT，该 NAT 要么作为网络的一部分实现，要么由 ExpressRoute 运营商提供。 源 NAT 允许从 ExpressRoute 和 提取 Internet 网络的详细信息和专用 IP 寻址;结合适当的 IP 路由播发，提供一种简单的机制来确保路径对称性。 如果使用特定于 ExpressRoute 对等互连位置的有状态网络设备，则必须为每个 ExpressRoute 对等互连实现单独的 NAT 池，以确保路径对称性。
详细了解 ExpressRoute NAT 要求。
将出站连接的更改添加到网络拓扑图。
设计入站服务连接
大多数企业 Microsoft 365 部署采用某种形式的从 Microsoft 365 到本地服务的入站连接，例如 Exchange、SharePoint 和 Skype for Business 混合方案、邮箱迁移和使用 ADFS 基础结构进行身份验证。 当 ExpressRoute 在本地网络和 Microsoft 之间启用额外的路由路径进行出站连接时，这些入站连接可能会无意中受到非对称路由的影响，即使你打算让这些流继续使用 Internet 也是如此。 建议采取下面所述的一些预防措施，以确保从 Microsoft 365 到本地系统的基于 Internet 的入站流不会受到影响。
为了最大程度地降低入站网络流量流非对称路由的风险，所有入站连接都应使用源 NAT，然后再将其路由到网络段，这些段具有 ExpressRoute 路由可见性。 如果允许传入连接进入没有源 NAT 的 ExpressRoute 的路由可见性的网段，则来自 Microsoft 365 的请求将从 Internet 输入，但返回 Microsoft 365 的响应将首选 ExpressRoute 网络路径返回到 Microsoft 网络，从而导致非对称路由。
可以考虑以下实现模式之一来满足此要求：
使用网络设备（例如防火墙或负载均衡器）在从 Internet 到本地系统的路径上将请求路由到内部网络之前执行源 NAT。
确保 ExpressRoute 路由不会传播到处理 Internet 连接的入站服务（如前端服务器或反向代理系统）所在的网段。
在网络中显式考虑这些方案，并保留所有通过 Internet 的入站网络流量流，有助于将非对称路由的部署和操作风险降到最低。
在某些情况下，可以选择通过 ExpressRoute 连接定向某些入站流。 对于这些方案，请考虑以下额外注意事项。
Microsoft 365 只能面向使用公共 IP 的本地终结点。 这意味着，即使本地入站终结点仅通过 ExpressRoute 向 Microsoft 365 公开，它仍需要具有关联的公共 IP。
Microsoft 365 服务为解析本地终结点而执行的所有 DNS 名称解析都使用公共 DNS 进行。 这意味着必须将入站服务终结点的 FQDN 注册到 Internet 上的 IP 映射。
为了通过 ExpressRoute 接收入站网络连接，必须通过 ExpressRoute 将这些终结点的公共 IP 子网播发给 Microsoft。
仔细评估这些入站网络流量流，以确保根据公司安全和网络策略对它们应用适当的安全性和网络控制。
通过 ExpressRoute 将本地入站终结点播发到 Microsoft 后，ExpressRoute 将有效地成为所有 Microsoft 服务（包括 Microsoft 365）这些终结点的首选路由路径。 这意味着，这些终结点子网只能用于与 Microsoft 365 服务通信，而不能用于 Microsoft 网络上的其他服务。 否则，你的设计将导致非对称路由，其中来自其他 Microsoft 服务的入站连接倾向于通过 ExpressRoute 路由入站，而返回路径将使用 Internet。
如果 ExpressRoute 线路或 meet-me 位置关闭，则需要确保本地入站终结点仍可用于通过单独的网络路径接受请求。 这可能意味着通过多个 ExpressRoute 线路播发这些终结点的子网。
建议对通过 ExpressRoute 进入网络的所有入站网络流量流应用源 NAT，尤其是在这些流量流穿过有状态网络设备（如防火墙）时。
某些本地服务（如 ADFS 代理或 Exchange 自动发现）可能会同时接收来自 Microsoft 365 服务和来自 Internet 的用户的入站请求。 对于这些请求，Microsoft 365 将针对与用户通过 Internet 发出的请求相同的 FQDN。 允许从 Internet 到这些本地终结点的入站用户连接，同时强制 Microsoft 365 连接使用 ExpressRoute，这表示路由复杂性很大。 由于操作注意事项，不建议绝大多数客户通过 ExpressRoute 实现此类复杂方案。 此额外开销包括管理非对称路由的风险，并且需要仔细管理跨多个维度的路由播发和策略。
更新网络拓扑计划，以显示如何避免非对称路由
你希望避免非对称路由，以确保组织中的人员可以无缝使用 Microsoft 365 以及 Internet 上的其他重要服务。 客户有两种常见配置会导致非对称路由。 现在是查看计划使用的网络配置的好时机，并检查是否存在这些非对称路由方案之一。
首先，我们将检查与以下网络关系图相关的一些不同情况。 在此图中，接收入站请求的所有服务器（如 ADFS 或本地混合服务器）都位于新泽西州数据中心，并播发到 Internet。
虽然外围网络是安全的，但没有可用于传入请求的源 NAT。
新泽西州数据中心的服务器能够看到 Internet 和 ExpressRoute 路由。
我们还提供了有关如何修复它们的建议。
问题 1：通过 Internet 建立云到本地连接
下图演示了当网络配置未通过 Internet 为来自 Microsoft 云的入站请求提供 NAT 时采用的非对称网络路径。
来自 Microsoft 365 的入站请求从公共 DNS 检索本地终结点的 IP 地址，并将请求发送到外围网络。
在此错误配置中，在发送流量的外围网络中，没有配置或可用的源 NAT，导致实际源 IP 地址用作返回目标。
网络上的服务器通过任何可用的 ExpressRoute 网络连接将返回流量路由到 Microsoft 365。
结果是该流到 Microsoft 365 的非对称路径，导致连接断开。
解决方案 1a：源 NAT
只需将源 NAT 添加到入站请求即可解决此配置错误的网络。 在此图中：
传入请求将继续通过新泽西州数据中心的外围网络进入。 这一次，源 NAT 可用。
来自服务器的响应路由回与源 NAT 关联的 IP，而不是原始 IP 地址，导致响应沿同一网络路径返回。
解决方案 1b：路由范围
或者，可以选择不允许播发 ExpressRoute BGP 前缀，从而删除这些计算机的备用网络路径。 在此图中：
传入请求将继续通过新泽西州数据中心的外围网络进入。 这一次，从 Microsoft 通过 ExpressRoute 线路播发的前缀不适用于新泽西州数据中心。
来自服务器的响应通过唯一可用的路由回到与原始 IP 地址关联的 IP，导致响应沿同一网络路径返回。
问题 2：通过 ExpressRoute 建立云到本地连接
下图演示了当网络配置未通过 ExpressRoute 为来自 Microsoft 云的入站请求提供 NAT 时采用的非对称网络路径。
来自 Microsoft 365 的入站请求从 DNS 检索 IP 地址，并将请求发送到外围网络。
在此错误配置中，在发送流量的外围网络中，没有配置或可用的源 NAT，导致实际源 IP 地址用作返回目标。
网络上的计算机通过任何可用的 ExpressRoute 网络连接将返回流量路由到 Microsoft 365。
结果是与 Microsoft 365 的非对称连接。
解决方案 2：源 NAT
只需将源 NAT 添加到入站请求即可解决此配置错误的网络。 在此图中：
传入请求继续通过纽约数据中心的外围网络进入。 这一次，源 NAT 可用。
来自服务器的响应路由回与源 NAT 关联的 IP，而不是原始 IP 地址，导致响应沿同一网络路径返回。
论文验证网络设计是否具有路径对称性
此时，你需要在纸上验证实施计划是否为将使用 Microsoft 365 的不同方案提供路由对称性。 你将确定当某人使用服务的不同功能时应采用的特定网络路由。 从本地网络和 WAN 路由到外围设备，到连接路径;ExpressRoute 或 Internet，并连接到联机终结点。
你需要为以前确定为组织将采用的服务的所有 Microsoft 365 网络服务执行此操作。
它有助于使用第二个人浏览路线。 向他们说明每个网络跃点应从何处获取其下一个路由，并确保熟悉路由路径。 请记住，ExpressRoute 将始终提供一个范围更广的 Microsoft 服务器 IP 地址路由，使其路由成本低于 Internet 默认路由。
设计客户端连接配置
如果使用代理服务器进行 Internet 绑定的流量，则需要调整任何 PAC 或客户端配置文件，以确保网络上的客户端计算机正确配置为将所需的 ExpressRoute 流量发送到 Microsoft 365，而无需传输代理服务器，并将剩余流量（包括部分 Microsoft 365 流量）发送到相关代理。 阅读有关 管理 Microsoft 365 终结点（例如 PAC 文件）的指南。
注意
终结点经常更改，每周更改一次。 应仅根据组织采用的服务和功能进行更改，以减少为保持最新而需要进行的更改数。 请密切关注 RSS 源中的 生效日期 ，其中已宣布更改并保留所有过去更改的记录，在到达生效日期之前，可能不会播发或从广告中删除已宣布的 IP 地址。
确保路由对称性
可在 Internet 和 ExpressRoute 上访问 Microsoft 365 前端服务器。 当两者都可用时，这些服务器更倾向于通过 ExpressRoute 线路路由回本地。 因此，如果来自网络的流量倾向于通过 Internet 线路路由，则可能存在路由不对称。 非对称路由是一个问题，因为执行有状态数据包检查的设备可能会阻止与所遵循的出站数据包不同的路径的返回流量。
无论是通过 Internet 还是 ExpressRoute 启动与 Microsoft 365 的连接，源都必须是可公开路由的地址。 由于许多客户直接与 Microsoft 对等互连，因此在客户之间可能存在重复的专用地址是不可行的。
以下是将启动从 Microsoft 365 到本地网络的通信的方案。 为了简化网络设计，我们建议通过 Internet 路径路由以下内容。
SMTP 服务，例如从Exchange Online租户到本地主机的邮件，或从 SharePoint 发送到本地主机的 SharePoint 邮件。 与通过 ExpressRoute 线路共享的路由前缀相比，在 Microsoft 网络中使用 SMTP 协议更广泛，通过 ExpressRoute 播发本地 SMTP 服务器将导致这些其他服务失败。
用于登录的密码验证期间的 ADFS。
对于这些双向流量流，Microsoft 要路由回你的网络，必须与 Microsoft 共享指向本地设备的 BGP 路由。 通过 ExpressRoute 将路由前缀播发到 Microsoft 时，应遵循以下最佳做法：
不要通过 ExpressRoute 将相同的公共 IP 地址路由前缀播发到公共 Internet 和 ExpressRoute。 建议通过 ExpressRoute 向 Microsoft 发送的 IP BGP 路由前缀播发来自根本不播发到 Internet 的范围。 如果由于可用的 IP 地址空间而无法实现这一目标，则必须确保通过 ExpressRoute 播发比任何 Internet 线路更具体的范围。
使用每个 ExpressRoute 线路的单独 NAT IP 池，并独立于 Internet 线路的 NAT IP 池。
播发到 Microsoft 的任何路由都会吸引来自 Microsoft 网络中的任何服务器的网络流量，而不仅仅是通过 ExpressRoute 将路由播发到网络的服务器。 仅将路由播发到团队已定义并充分理解路由方案的服务器。 在网络中的多个 ExpressRoute 线路上播发单独的 IP 地址路由前缀。
使用 Azure ExpressRoute 实现高可用性和故障转移
我们建议使用 ExpressRoute 将每个出口中的至少两条活动线路预配到 ExpressRoute 提供程序。 对于客户来说，这是最常见的故障位置，你可以通过预配一对主动/主动 ExpressRoute 线路来轻松避免故障。 我们还建议至少使用两条主动/主动 Internet 线路，因为许多 Microsoft 365 服务只能通过 Internet 使用。
在网络的出口点内，还有许多其他设备和线路在人们感知可用性方面起着关键作用。 ExpressRoute 或 Microsoft 365 SLA 未涵盖连接方案的这些部分，但它们在组织中人员所感知的端到端服务可用性中起着关键作用。
关注使用和操作 Microsoft 365 的人员，如果任何一个组件的故障会影响用户使用服务的体验，请寻找限制受影响人员总百分比的方法。 如果故障转移模式在操作上很复杂，请考虑用户长时间恢复的经验，并寻找操作上简单和自动化的故障转移模式。
在网络外部，Microsoft 365、ExpressRoute 和 ExpressRoute 提供程序都具有不同级别的可用性。
服务可用性
Microsoft 365 服务由明确定义的 服务级别协议涵盖，其中包括单个服务的运行时间和可用性指标。 Microsoft 365 可以保持如此高服务可用性级别的一个原因是，各个组件能够使用全球 Microsoft 网络在多个 Microsoft 数据中心之间无缝故障转移。 此故障转移从数据中心和网络扩展到多个 Internet 出口点，并且从使用服务的人员的角度实现无缝故障转移。
ExpressRoute 在 Microsoft 网络边缘与 ExpressRoute 提供商或合作伙伴基础结构之间的单个专用线路上 提供 99.9% 的可用性 SLA 。 这些服务级别应用于 ExpressRoute 线路级别，该线路级别由每个对等互连位置中的冗余 Microsoft 设备和网络提供商设备之间的 两个独立的互连 组成。
提供程序可用性
- Microsoft 的服务级别安排停止在你的 ExpressRoute 提供商或合作伙伴处。 这也是你可以做出影响可用性级别的选择的第一个位置。 应仔细评估 ExpressRoute 提供商在每个 Microsoft 对等互连位置的网络外围与提供商连接之间提供的体系结构、可用性和复原能力特征。 密切关注冗余、对等互连设备、运营商提供的 WAN 线路的逻辑和物理方面，以及 NAT 服务或托管防火墙等任何额外的增值服务。
设计可用性计划
强烈建议你在 Microsoft 365 的端到端连接方案中规划和设计高可用性和复原能力。 设计应包括：
没有单一故障点，包括 Internet 和 ExpressRoute 线路。
在大多数预期故障模式下，尽量减少受影响的人数和影响持续时间。
针对大多数预期故障模式的简单、可重复和自动恢复过程进行优化。
通过冗余路径支持网络流量和功能的全部需求，而不会大幅降低。
连接方案应包括针对 Microsoft 365 的多个独立和活动网络路径优化的网络拓扑。 与仅在单个设备或设备级别针对冗余进行优化的拓扑相比，这将产生更好的端到端可用性。
提示
如果用户分布在多个大陆或地理区域，并且每个位置都通过冗余 WAN 线路连接到单个 ExpressRoute 线路所在的单个本地位置，则与网络拓扑设计相比，端到端服务可用性将低于网络拓扑设计，该设计包含将不同区域连接到最近的对等互连位置的独立 ExpressRoute 线路。
我们建议预配至少两条 ExpressRoute 线路，每个线路连接到不同的地理对等互连位置。 应为用户将 ExpressRoute 连接用于 Microsoft 365 服务的每个区域预配此主动-主动线路对。 这允许每个区域在影响数据中心或对等位置等主要位置的灾难期间保持连接。 将它们配置为主动/主动允许最终用户流量分布在多个网络路径中。 这减少了在设备或网络设备中断期间受影响的人员的范围。
建议不要将单个 ExpressRoute 线路与 Internet 配合使用作为备份。
示例：故障转移和高可用性
Contoso 的多地理设计已经过路由、带宽、安全性的审查，现在必须经过高可用性评审。 Contoso 认为高可用性涵盖三个类别：复原能力、可靠性和冗余。
复原使 Contoso 能够快速从故障中恢复。 可靠性允许 Contoso 在系统中提供一致的结果。 冗余允许 Contoso 在基础结构的一个或多个镜像实例之间移动。
在每个边缘配置中，Contoso 都有冗余的防火墙、代理和 IDS。 对于北美，Contoso 在其达拉斯数据中心有一个边缘配置，在弗吉尼亚数据中心有另一个边缘配置。 每个位置的冗余设备提供该位置的复原能力。
Contoso 的网络配置基于几个关键原则构建：
在每个地理区域中，有多个 Azure ExpressRoute 线路。
区域中的每个线路都可以支持该区域中的所有网络流量。
路由显然会根据可用性、位置等选择一个或另一个路径。
Azure ExpressRoute 线路之间的故障转移会自动进行，无需 Contoso 进行其他配置或操作。
Internet 线路之间的故障转移会自动发生，无需 Contoso 进行其他配置或操作。
在此配置中，Contoso 在物理和虚拟级别具有冗余，因此能够以可靠的方式提供本地复原能力、区域复原能力和全局复原能力。 Contoso 在评估每个区域的单个 Azure ExpressRoute 线路以及故障转移到 Internet 的可能性后选择了此配置。
如果 Contoso 无法为每个区域拥有多个 Azure ExpressRoute 线路，则将源自 北美 的流量路由到亚太地区的 Azure ExpressRoute 线路将增加不可接受的延迟级别，而所需的 DNS 转发器配置会增加复杂性。
不建议使用 Internet 作为备份配置。 这违反了 Contoso 的可靠性原则，导致使用连接的体验不一致。 此外，需要手动配置才能进行故障转移，同时考虑已配置的 BGP 播发、NAT 配置、DNS 配置和代理配置。 这增加了故障转移的复杂性，增加了恢复时间，并降低了诊断和排查所涉及的步骤的能力。
仍对如何规划和实现流量管理或 Azure ExpressRoute 有疑问？ 阅读 网络和性能指南 的其余部分或 Azure ExpressRoute 常见问题解答。
将安全控制应用于 Microsoft 365 方案的 Azure ExpressRoute
保护 Azure ExpressRoute 连接与保护 Internet 连接的原则相同。 许多客户选择沿将本地网络连接到 Microsoft 365 和其他 Microsoft 云的 ExpressRoute 路径部署网络和外围控制。 这些控制可能包括防火墙、应用程序代理、数据泄漏防护、入侵检测、入侵防护系统等。 在许多情况下，客户对从本地到 Microsoft 发起的流量、从 Microsoft 启动到客户本地网络的流量、从本地发起的流量以及从本地到常规 Internet 目标的流量应用不同级别的控制。
下面是将安全性与你选择部署的 ExpressRoute 连接模型 集成的几个示例。
| ExpressRoute 集成选项 | 网络安全外围模型 |
|---|---|
| 在云交换中并置 |
在建立 ExpressRoute 连接的托管设施中安装新的或现有的安全/外围基础结构。 将归置设施仅用于路由/互连目的，并将连接从归置设施回拖到本地安全/外围基础结构。 |
| 点到点以太网 |
终止现有本地安全/外围基础结构位置中的点到点 ExpressRoute 连接。 安装特定于 ExpressRoute 路径的新安全/外围基础结构，并终止该路径的点到点连接。 |
| 任意到任意 IPVPN |
在流出到用于 Microsoft 365 连接的 ExpressRoute IPVPN 的所有位置使用现有的本地安全/外围基础结构。 将用于 Microsoft 365 ExpressRoute 的 IPVPN 固定到指定用作安全/外围的特定本地位置。 |
某些服务提供商还提供托管安全性/外围功能，作为其与 Azure ExpressRoute 集成解决方案的一部分。
考虑用于 Microsoft 365 连接的 ExpressRoute 的网络/安全外围选项的拓扑位置时，下面是其他注意事项
网络/安全控件的深度和类型可能会影响 Microsoft 365 用户体验的性能和可伸缩性。
出站 (本地> Microsoft) 和入站 (本地 Microsoft-ons>) [如果已启用]流可能具有不同的要求。 这些目标可能与出站到常规 Internet 目标不同。
无论是通过 Microsoft 365 的 ExpressRoute 还是通过 Internet 路由流量，Microsoft 365 对端口/协议和必要的 IP 子网的要求都是相同的。
客户网络/安全控制的拓扑位置决定了用户与 Microsoft 365 服务之间的最终端到端网络，并且可能会对网络延迟和拥塞产生重大影响。
建议客户根据冗余、高可用性和灾难恢复的最佳做法设计其安全/外围拓扑，以便与适用于 Microsoft 365 的 ExpressRoute 配合使用。
下面是 Contoso 的示例，该示例将不同的 Azure ExpressRoute 连接选项与上面讨论的外围安全模型进行比较。
示例：保护 Azure ExpressRoute
Contoso 正在考虑实现 Azure ExpressRoute，在为 Microsoft 365 规划 ExpressRoute 的最佳体系结构后，并在使用上述指南了解带宽要求后，他们正在确定保护其外围的最佳方法。
对于位于多个大洲的多国组织 Contoso，安全性必须跨越所有外围。 Contoso 的最佳连接选项是具有全球多个对等互连位置的多点连接，以满足各大洲员工的需求。 每个大洲都包含欧洲大陆内的冗余 Azure ExpressRoute 线路，安全性必须跨越所有这些线路。
Contoso 的现有基础结构是可靠的，可以处理额外的工作，因此，Contoso 能够使用该基础结构实现其 Azure ExpressRoute 和 Internet 外围安全性。 如果不是这种情况，Contoso 可以选择购买更多设备来补充其现有设备或处理不同类型的连接。
Azure ExpressRoute 的带宽规划
每个 Microsoft 365 客户都有独特的带宽需求，具体取决于每个位置的人员数量、每个 Microsoft 365 应用程序的活跃程度以及其他因素，例如使用本地或混合设备和网络安全配置。
带宽过少将导致拥塞、重新传输数据以及不可预知的延迟。 带宽过多会导致不必要的成本。 在现有网络上，带宽通常以百分比表示线路上的可用余量。 拥有 10% 的空余空间可能会导致拥堵，而拥有 80% 的空余空间通常意味着不必要的成本。 典型的空余量目标分配为 20% 到 50%。
若要找到适当的带宽级别，最佳机制是测试现有网络消耗。 这是获取真正衡量使用情况和需求的唯一方法，因为每个网络配置和应用程序在某些方面都是独一无二的。 测量时，需要密切关注总带宽消耗、延迟和 TCP 拥塞情况，以了解网络需求。
一旦有了包含所有网络应用程序的估计基线，请试用 Microsoft 365，其中包含组织中人员的不同配置文件，以确定实际使用情况，并使用这两个度量值来估计每个办公室位置所需的带宽量。 如果在测试中发现任何延迟或 TCP 拥塞问题，则可能需要将出口移近使用 Microsoft 365 的人员，或删除密集的网络扫描，例如 SSL 解密/检查。
有关建议的网络处理类型的所有建议都适用于 ExpressRoute 和 Internet 线路。 对于 性能优化站点上的其余指南，情况也是如此。
生成部署和测试过程
实施计划应包括测试和回滚计划。 如果实现未按预期运行，则计划应设计为在发现问题之前影响最少的人。 以下是计划应考虑的一些高级原则。
暂存网络段和用户服务载入，以最大程度地减少中断。
规划从单独的 Internet 连接主机通过跟踪路由和 TCP 连接测试路由。
最好是在具有测试 Microsoft 365 租户的隔离测试网络上执行入站和出站服务测试。
或者，如果客户尚未使用 Microsoft 365 或处于试点阶段，则可以在生产网络上执行测试。
或者，可以在生产中断期间执行测试，该中断仅用于测试和监视。
或者，可以通过检查每个第 3 层路由器节点上每个服务的路由来完成测试。 仅当无法进行其他测试时，才应使用此回退，因为缺少物理测试会带来风险。
生成部署过程
部署过程应分阶段向小组人员推出，以便在部署到较大的人员组之前进行测试。 以下是暂存 ExpressRoute 部署的几种方法。
使用 Microsoft 对等互连设置 ExpressRoute，并将路由播发转发到单个主机，仅用于暂存测试目的。
首先将到 ExpressRoute 网络的路由播发到单个网段，并按网段或区域展开路由播发。
如果首次部署 Microsoft 365，请使用 ExpressRoute 网络部署作为少数人的试点。
如果使用代理服务器，也可以配置测试 PAC 文件，以将几个人定向到 ExpressRoute，并提供测试和反馈，然后再添加更多内容。
实施计划应列出必须执行的每个部署过程或需要用于部署网络配置的命令。 网络中断时间到达时，所做的所有更改都应来自事先编写并经过对等评审的书面部署计划。 请参阅有关 ExpressRoute 技术配置的指南。
如果更改了将继续发送电子邮件的任何本地服务器的 IP 地址，则更新 SPF TXT 记录。
如果已更改 IP 地址以适应新的 NAT 配置，请更新本地服务器的任何 DNS 条目。
确保已订阅 Microsoft 365 终结点通知的 RSS 源，以维护任何路由或代理配置。
ExpressRoute 部署完成后，应执行测试计划中的过程。 应记录每个过程的结果。 如果测试计划结果指示实现不成功，则必须包括回滚到原始生产环境的过程。
生成测试过程
测试过程应包括对将使用 ExpressRoute 的 Microsoft 365 的每个出站和入站网络服务进行测试，以及不会使用 ExpressRoute 的测试。 过程应包括从每个唯一网络位置进行测试，包括企业 LAN 中不在本地的用户。
测试活动的一些示例包括以下内容。
从本地路由器 Ping 到网络运营商路由器。
验证本地路由器是否收到了 500 多个 Microsoft 365 和 CRM Online IP 地址播发。
验证入站和出站 NAT 是否在 ExpressRoute 和内部网络之间运行。
验证是否正在从路由器播发到 NAT 的路由。
验证 ExpressRoute 是否已接受播发的前缀。
- 使用以下 cmdlet 验证对等互连播发：
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering验证公共 NAT IP 范围是否未通过任何其他 ExpressRoute 或公共 Internet 网络线路向 Microsoft 播发，除非它是较大范围的特定子集，如上一示例中所示。
ExpressRoute 线路已配对，验证两个 BGP 会话是否正在运行。
在 NAT 内部设置单个主机，并使用 ping、tracert 和 tcpping 测试跨新线路与主机 outlook.office365.com 的连接。 或者，可以在 MSEE 的镜像端口上使用 Wireshark 或 Microsoft 网络监视器 3.4 等工具来验证是否能够连接到与 outlook.office365.com 关联的 IP 地址。
测试Exchange Online的应用程序级别功能。
测试 Outlook 是否能够连接到Exchange Online并发送/接收电子邮件。
测试 Outlook 是否能够使用联机模式。
测试智能手机连接和发送/接收功能。
- 测试 SharePoint 的应用程序级别功能
测试OneDrive for Business同步客户端。
测试 SharePoint Web 访问。
- 测试Skype for Business调用方案的应用程序级别功能：
以经过身份验证的用户身份加入电话会议 [最终用户发起的邀请]。
邀请用户参加电话会议 [从 MCU 发送的邀请]。
使用 Skype for Business Web 应用程序以匿名用户身份加入会议。
通过有线电脑连接、IP 电话和移动设备加入呼叫。
呼叫联合用户 o 呼叫 PSTN 验证：呼叫已完成，呼叫质量可接受，连接时间可接受。
验证租户成员和联合用户的联系人状态是否已更新。
常见问题
非对称路由是最常见的实现问题。 下面是要查找的一些常见来源：
使用没有源 NAT 的开放或平面网络路由拓扑。
不使用 SNAT 通过 Internet 和 ExpressRoute 连接路由到入站服务。
在广泛部署之前，不要在测试网络上测试 ExpressRoute 上的入站服务。
通过网络部署 ExpressRoute 连接
一次将部署暂存到一个网络段，逐步推出到网络不同部分的连接，并计划为每个新网段回滚。 如果你的部署与 Microsoft 365 部署一致，请先部署到 Microsoft 365 试点用户，并从那里扩展。
首先用于测试，然后用于生产：
运行部署步骤以启用 ExpressRoute。
测试网络路由是否与预期一样。
对每个入站和出站服务执行测试。
如果发现任何问题，请回滚。
使用测试网段设置与 ExpressRoute 的测试连接
现在，你已准备好纸上完整的计划，是时候进行小规模测试了。 在此测试中，你将与 Microsoft 对等互连建立到本地网络上的测试子网的单个 ExpressRoute 连接。 可以配置与测试子网的连接的 试用版 Microsoft 365 租户 ，并在测试子网中包含将在生产环境中使用的所有出站和入站服务。 为测试网段设置 DNS，并建立所有入站和出站服务。 执行测试计划，并确保熟悉每个服务的路由和路由传播。
执行部署和测试计划
完成上述项目时，检查已完成的区域，并确保你和你的团队在执行部署和测试计划之前已查看它们。
网络更改中涉及的出站和入站服务的列表。
显示 Internet 出口和 ExpressRoute 相遇位置的全局网络体系结构图。
网络路由图，其中演示了用于部署的每个服务的不同网络路径。
一个部署计划，其中包含实施更改和回滚（如果需要）的步骤。
测试每个 Microsoft 365 和网络服务的测试计划。
已完成入站和出站服务的生产路由的书面验证。
跨测试网络段完成的测试，包括可用性测试。
选择一个服务中断时段，该时段足够长，可以运行整个部署计划和测试计划，并有一些时间来进行故障排除，并在必要时有时间回滚。
警告
由于通过 Internet 和 ExpressRoute 进行路由的复杂性，建议在此窗口中添加额外的缓冲时间，以处理复杂路由的故障排除。
为 Skype for Business Online 配置 QoS
QoS 对于获取 Skype for Business Online 的语音和会议权益是必需的。 在确保 ExpressRoute 网络连接不会阻止任何其他 Microsoft 365 服务访问后，可以配置 QoS。 Skype for Business Online 中的 ExpressRoute 和 QoS 一文介绍了 QoS 的配置。
对实现进行故障排除
首先要了解此实施指南中的步骤，你的实施计划中是否遗漏了任何内容？ 如果可能，返回并运行进一步的小型网络测试，以复制错误并对其进行调试。
确定测试期间哪些入站或出站服务失败。 获取每个失败服务的 IP 地址和子网。 继续在纸上演练网络拓扑图并验证路由。 请专门验证 ExpressRoute 路由播发到的位置，在中断期间使用跟踪测试该路由（如果可能）。
通过对每个客户终结点的网络跟踪运行 PSPing，并评估源和目标 IP 地址，以验证它们是否符合预期。 在端口 25 上公开的任何邮件主机运行 telnet，并验证 SNAT 是否隐藏了原始源 IP 地址（如果预期）。
请记住，在使用 ExpressRoute 连接部署 Microsoft 365 时，需要确保 ExpressRoute 的网络配置设计最佳，并且还优化了网络上的其他组件，例如客户端计算机。 除了使用此规划指南排查你可能错过的步骤之外，我们还编写了 Microsoft 365 的性能故障排除计划 。
以下是可以用于返回的简短链接：https://aka.ms/implementexpressroute365
相关主题
适用于 Microsoft 365 的 Azure ExpressRoute
Skype for Business Online 中的媒体质量和网络连接性能
优化 Skype for Business Online 网络
Skype for Business Online 中的 ExpressRoute 和 QoS
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈