实现适用于 Office 365 的 ExpressRoute

重要:  本文是由机器翻译的,请参阅免责声明。请在 此处 中查找本文的英文版本以便参考。

适用于 Office 365 的 ExpressRoute 为面向 Office 365 服务的多个 Internet 提供备选路由路径。适用于 Office 365 的 ExpressRoute 的体系结构依赖于将 Office 365 服务(已可通过 Internet 进行访问)的公共 IP 前缀播发到预配置的 ExpressRoute 线路中,以便随后将这些 IP 前缀重新分发到你的网络中。使用 ExpressRoute,可通过 Internet 和 ExpressRoute 有效启用多个不同路由路径,以适应多种 Office 365服务。网络上的这种路由状态可能意味着内部网络拓扑的设计方式将发生巨大变化。

状态:完整的指南 v2

必须仔细规划适用于 Office 365 的 ExpressRoute 的实施,以适应网络复杂性,由此实现通过核心网络中插入了路由的专用线路以及 Internet 均可使用路由。如果你和你的团队未按照指南进行详细规划和测试,则在启用 ExpressRoute 线路后,Office 365 服务连接间断或完全丧失 的风险将极高。

要成功实施,需分析基础结构要求,详细审查网络评估和设计,以可控的方式分阶段仔细规划产品和服务的推出,并建立一个详细的验证和测试计划。对于大型的分布式环境,有可能会耗时数月来实施。本指南旨在帮助用户提前规划。

大型成功部署可能需耗时六个月来规划,通常涉及组织中多个领域的团队成员,其中包括网络、防火墙和代理服务器管理员、Office 365 管理员、安全性、最终用户支持、项目管理和执行资金。对规划过程的投资将减少遭遇部署失败的可能性,部署失败会导致停工或复杂且昂贵的故障排除操作。

开始使用本实施指南之前,需完成以下先决条件。

  1. 已完成用以确定是否建议使用并批准 ExpressRoute 的网络评估。

  2. 已选择 ExpressRoute 网络服务提供商。查找关于 ExpressRoute 合作伙伴和对等位置的详细信息。

  3. 您已读,并了解适用 ExpressRoute 文档 ,并且能够满足适用 ExpressRoute 必备端到端内部网络。

  4. 您的团队具有阅读所有公共指南和https://aka.ms/expressrouteoffice365https://aka.ms/ert,在文档和 Office 365 监视适用 Azure ExpressRoute培训系列通道 9 以了解关键技术详细信息,包括:

    • SaaS 服务的 Internet 依赖项。

    • 如何避免非对称路由和处理复杂路由。

    • 如何合并外围安全、 可用性和应用程序级别控件。

首先请收集要求

首先确定计划在组织内采用的功能和服务。需确定将使用不同的 Office 365 服务的哪些功能,以及网络上的哪些位置将托管使用这些功能的人员。对于方案目录,需添加每个方案所需的网络属性;如入站和出站网络通信流,以及 Office 365 端点在 ExpressRoute 上是否可用。

收集组织要求:

  • 为组织使用的 Office 365 服务的入站和出站网络通信编制目录。参阅 Office 365 URL 和 IP 地址范围页,以获得有关不同 Office 365 方案所需通信流的说明。

  • 收集现有网络拓扑的文档,其中显示有内部 WAN 主干网和拓扑、附属站点连接性、最后一英里用户连接性、到网络外围出口点的路由和代理服务的详细信息。

    • 在网络图上标识 Office 365 和其他 Microsoft 服务将连接到的入站服务终结点,同时显示 Internet 连接路径和建议的 ExpressRoute 连接路径。

    • 标识所有地理用户位置和位置之间的 WAN 连接,以及当前具有通向 Internet 的出口的位置和建议具有通向 ExpressRoute 对等位置的出口的位置。

    • 标识所有边缘设备,例如代理、防火墙等,并针对它们与流经 Internet 和 ExpressRoute 的流之间的关系编制目录。

    • 记录最终用户是否将通过同时适用于 Internet 和 ExpressRoute 流的直接路由和间接应用程序代理来访问 Office 365 服务。

  • 将租户位置和汇接位置添加到网络图。

  • 估计预期的和观察到的从主要用户位置到 Office 365 的网络性能及延迟特征。请记住,Office 365 是一种全局的、分布式的服务集,用户连接的位置可能与其租户的位置不同。因此,建议通过 ExpressRoute 和 Internet 连接,在用户和最近的 Microsoft 全局网络边缘之间测量和优化延迟。可使用网络评估所得的发现结果来协助完成此任务。

  • 列出使用新的 ExpressRoute 连接时需满足的公司网络安全及高可用性方面的要求。例如,用户如何在 Internet 出口或 ExpressRoute 线路故障时继续访问 Office 365。

  • Office 365 网络入站和出站排中的文档将使用 Internet 路径,这将使用适用 ExpressRoute。您的用户的地理位置和您的本地网络拓扑的详细信息的具体情况可能需要不同于用户的一个位置到另一个计划。

以最小化路由和其他网络复杂性,我们建议您仅使用适用 ExpressRoute 为 Office 365 需要复习专用连接由于法规要求或形式的网络评估结果网络通信流。此外,我们建议您为实施项目的不同的不同阶段阶段适用 ExpressRoute 路由和方法站和出站网络通信流的范围。为 Office 365 部署适用 ExpressRoute,只需用户启动的出站网络通信流和离开跨 Internet 的入站的网络通信流有助于在拓扑复杂程度和风险的简介的更多控制增加的不对称路由的可能性。

您的网络流量目录应包含您必须在本地网络和 Microsoft 之间的入站和出站网络连接的列表。

  • 出站网络通信流符合后述情况:从本地环境(例如从内部客户端或服务器)中启动连接,连接目标是 Microsoft 服务。这些连接有可能直接或间接(例如,通过代理服务器、防火墙或其他路径上的网络设备连接到 Office 365)通向 Office 365。

  • 入站网络通信流符合后述情况:从 Microsoft 云中启动到本地主机的连接。这些连接通常需要经过客户安全策略针对外部发起的流所要求设置的防火墙和其他安全性基础结构。

请参阅文章通过适用于 Office 365 的 ExpressRoute 实现路由中的确保路由对称部分,以确定哪些服务将发送入站流,并查找 Office 365 终结点参考文章中标记为适用于 Office 365 的 ExpressRoute 部分,以确定其余的连接信息。

对于每一个需要出站连接的服务,需描述针对该服务的计划连接,包括网络路由、代理配置、包检查和带宽需求。

对每一个需要入站连接的服务,需要一些额外信息。Microsoft 云中的服务器将建立通向本地网络的连接,为确保连接正确,需对此连接进行全面描述,包括将接受入站连接的服务的公用 DNS 条目,CIDR 格式的 IPv4 IP 地址(涉及 ISP 设备),以及如何为这些连接处理入站 NAT 或源 NAT。

无论通过 Internet 还是 ExpressRoute 进行连接,都应检查入站连接,以确保不引入非对称路由。在某些情况下,Office 365 服务对其启动入站连接的本地终结点也可能需要接受其他 Microsoft 或非 Microsoft 服务的访问。出于 Office 365 的目的启用到这些服务的 ExpressRoute 路由不会中断其它应用场景,这点至关重要。在许多情况下,客户可能需对其内部网络实施特定更改,例如基于源的 NAT,要确保启用 ExpressRoute 后,来自 Microsoft 的入站流仍保持对称。

下面是所需详细信息级别的一个示例。本例中,Exchange 混合将通过 ExpressRoute 路由至本地系统。

连接属性

网络通信方向

入站

服务

Exchange 混合

公共 Office 365 终结点(源)

Exchange Online(IP 地址)

公共本地终结点(目标)

5.5.5.5

公共 (Internet) DNS 条目

Autodiscover.contoso.com

此本地终结点是否将用于其他(非 Office 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 (达拉斯)

下面是一个仅出站的服务示例:

连接属性

网络通信方向

出站

服务

SharePoint Online

本地终结点(源)

用户工作站

公共 Office 365 终结点(目标)

SharePoint Online(IP 地址)

公共 (Internet) DNS 条目

*.sharepoint.com(和其他 FQDN)

CDN 引荐

cdn.sharepointonline.com(和其他 FQDN)- IP地址(由 CDN 提供商维护)

使用中的 IP 播发和 NAT

Internet 路径/源 NAT1.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 的所有连接

了解服务和与之关联的网络通信流后,就可以创建纳入了这些新连接要求的网络图,并显示为使用适用于 Office 365 的 ExpressRoute 将做出的更改。此图应包括:

  1. Office 365 和其他服务将从其访问的所有用户位置。

  2. 所有 Internet 和 ExpressRoute 出口点。

  3. 所有用于管理网络出入连接的出站和入站设备,包括路由器、防火墙、应用程序代理服务器和入侵检测/防护。

  4. 所有入站通信流的内部目标,例如从 ADFS Web 应用程序代理服务器接受连接的内部 ADFS 服务器。

  5. 将播发的所有 IP 子网的目录

  6. 标识每个将要从其访问 Office 365 的位置,并列出将用于 ExpressRoute 的汇接位置。

  7. 将接受和筛选从 ExpressRoute 中学习到的 Microsoft IP 前缀及这些前缀将被传播到的内部网络拓扑的位置和部分。

  8. 网络拓扑应清楚显示每个网络段的地理位置,以及它们如何通过 ExpressRoute 和/或 Internet 连接至 Microsoft 网络。

下图显示使用 Office 365 的每个位置,以及通向 Office 365 的入站和出站路由播发。

ExpressRoute 区域地域汇接

对于出站通信流,用户通过以下三种方式之一访问 Office 365:

  1. 加利福尼亚州用户可通过位于北美的汇接位置访问。

  2. 中国香港特别行政区用户可通过位于香港特别行政区的汇接位置访问。

  3. 用户数不多且未设置 ExpressRoute 线路时,可通过孟加拉的 Internet 进行访问。

区域图的出站连接

同样,来自 Office 365 的入站网络通信流可通过以下三种方式之一返回:

  1. 加利福尼亚州用户可通过位于北美的汇接位置访问。

  2. 中国香港特别行政区用户可通过位于香港特别行政区的汇接位置访问。

  3. 用户数不多且未设置 ExpressRoute 线路时,可通过孟加拉的 Internet 进行访问。

区域图的入站连接

汇接位置即 ExpressRoute 线路将用户网络连接至 Microsoft 网络的物理位置,对此位置的选择受用户访问 Office 365 的位置的影响。作为 SaaS 产品,Office 365 不像 Azure 那样在 IaaS 或 PaaS 区域模式下运营。Office 365 是一种分布式的协作服务集,用户可能需要跨多个数据中心和区域连接至终结点,这些中心和区域不一定与用户租户的托管位置或地区相同。

这意味着在为适用于 Office 365 的 ExpressRoute 选择汇接位置时,最重要的是考虑组织内的人员将从何处连接。为实现最优 Office 365 连接,常规建议是实施路由,以便用户的 Office 365 服务请求可通过最短网络路径递交至 Microsoft 网络,这通常也称为“hot potato”路由。例如,如果大多数 Office 365 用户位于一个或两个位置,可选择最接近这些用户位置的位置作为汇接位置,从而制定最佳设计。如果公司用户众多且分布在多个不同地区,可以考虑使用多个 ExpressRoute 线路和汇接位置。对于某些用户位置,指向 Microsoft 网络和 Office 365 的最短/最佳路径或许不会经过内部 WAN 和 ExpressRoute 汇接点,而是经过 Internet。

大部分情况下,一个区域中有多个汇接位置可供选择,这些位置相对靠近用户。填写下表可帮助做出决定。

计划的加利福尼亚和纽约的 ExpressRoute 汇接位置

位置

人员数目

通过 Internet 出口到达 Microsoft 网络的预期延迟

通过 ExpressRoute 到达 Microsoft 网络的预期延迟

洛杉矶

10,000

~15ms

~10ms(经过硅谷)

华盛顿特区

15,000

~20ms

~10ms(经过纽约)

达拉斯

5,000

~15ms

~40ms(经过纽约)

开发出显示有 Office 365 区域、ExpressRoute 网络服务提供商汇接位置以及按位置的人员数量的全局网络体系结构之后,便可用它来确定是否可进行任何优化。该体系结构还可能显示全局 hairpin 网络连接(其中通信流路由至远方位置),由此获取汇接位置。如果在全局网络上发现 hairpin,应在继续之前将其修正。要避免 hairpin,请查找另一个汇接位置,或使用选择性 Internet 分出口点。

第一个图显示在北美拥有两个物理位置的客户的示例。可以看到关于办公位置、Office 365 租户位置和若干可选的 ExpressRoute汇接位置的信息。在此例中,客户基于两个原则选择了汇接位置,按先后顺序是:

  1. 最靠近其组织中人员的位置。

  2. 最近接近 Microsoft 数据中心托管 Office 365 的位置。

ExpressRoute 美国地域汇接

再稍微进一步展开此概念,第二个图显示面临类似信息和决策制定的跨国客户的示例。此客户在孟加拉拥有一个小型办公室,其团队成员仅十人,专注于在本地区谋求发展。由于金奈具有一个汇接位置,并存在一个在金奈托管了 Office 365 的 Microsoft 数据中心,因此可考虑使用汇接位置,但对于十个人而言,要负担额外线路开销,则较为困难。查看网络时,需要判断,存在延迟的跨网络通信流发送是否比花钱安装另一个 ExpressRoute 线路更有效。

或者,比起在内部网络中路由,通过 Internet 将网络通信流发送至 Microsoft 网络可能会为孟加拉的这十位员工带来更好的性能体验,如下方的说明图所示。

区域图的出站连接

创建适用于 Office 365 的 ExpressRoute 实施计划

实施计划应包含有关配置 ExpressRoute 的技术细节,以及有关在网络中配置所有其他基础结构的详细信息(如下所示)。

  • 计划在 ExpressRoute 和 Internet 之间拆分哪些服务。

  • 规划带宽、安全性、高可用性和故障转移。

  • 设计入站和出站路由,包括针对不同位置的正确路由路径优化

  • 确定在多远处将 ExpressRoute 路由播发至你的网络,以及客户端选择 Internet 或 ExpressRoute 路径的机制,例如直接路由或应用程序代理。

  • 规划 DNS 记录更改,包括发件人策略框架条目。

  • 计划 NAT 战略包括站和出站源 nat。

  • 对于初始部署,建议所有入站服务,例如入站电子邮件或混合连接,均使用 Internet。

  • 规划最终用户客户端 LAN 路由,例如配置 PAC/WPAD 文件、 默认路由、 代理服务器和 BGP 路由广告。

  • 规划外围路由,包括代理服务器、 防火墙和云代理。

为每个主 Office 365 工作负荷所需带宽创建计划。分别估计 Exchange Online、SharePoint Online 和 Business Online 带宽要求。可以用我们为 Exchange Online 和 Skype for Business 提供的估计计算器作为起点,但要完全了解组织的带宽需求,则需要对具有代表性的用户配置文件和位置样本进行试点测试。

在计划中添加每个 Internet 和 ExpressRoute 出口位置处理安全性的方式,请记住,所有通向 Office 365 的 ExpressRoute 连接都使用公共对等连接,且必须根据公司有关外部网络连接的安全策略来进行保护。

向计划添加有关哪些人员会被哪种故障类型所影响,以及这些人员如何用最简单的方式发挥全部能力完成工作的详细信息。

规划带宽要求,包括针对抖动、延迟、拥塞和空余空间的 Skype for Business 的要求

Skype for Business Online 还有其他特定网络要求,详细信息请参阅文章 Skype for Business Online 中的媒体质量和网络连接性能

请阅读适用于 Office 365 的 ExpressRoute 网络规划中的 Azure ExpressRoute 带宽规划部分。

在对试点用户执行带宽评估时,可使用我们的指南;使用基线和性能历史记录优化 Office 365 性能

规划高可用性要求

创建高可用性计划以满足需求,并将其纳入更新的网络拓扑图。请参阅适用于 Office 365 的 ExpressRoute 网络规划中的 Azure ExpressRoute 高可用性和故障转移部分。

规划网络的安全要求

创建一个计划以满足网络安全要求,并将其纳入已更新的网络拓扑关系图。请参阅适用于 Office 365 的 ExpressRoute 网络规划中的将安全控件应用至适用于 Office 365 的 Azure ExpressRoute 方案部分。

适用于 Office 365 的 ExpressRoute 具有可能不常见的出站网络要求。具体而言,代表连接到 Office 365 的用户和网络并充当通向 Microsoft 的出站网络连接的源终结点的 IP 地址必须符合以下所列特定要求。

  1. 终结点必须为已向公司或提供 ExpressRoute 连接的运营商注册的公共 IP 地址。

  2. 必须将终结点播发至 Microsoft,且已由 ExpressRoute 验证/接受。

  3. 不可将终结点播发至具有相同或更多首选路由跃点数的 Internet。

  4. 终结点不可用于不是通过 ExpressRoute 配置的 Microsoft 服务连接。

如果网络设计不满足这些要求,则用户连接 Office 365 或其他 Microsoft 服务时极可能失败,这是路由黑洞或非对称路由造成的。在通过 ExpressRoute 向 Microsoft 服务发送请求时会发生这种情况,但响应会通过 Interent 传回,或者反之,且响应会被防火墙等有状态网络设备丢弃。

要满足以上要求,最常见的方法是使用源 NAT,要么作为网络的一部分实施,要么由 ExpressRoute 运营商来提供。使用源 NAT,可从 ExpressRoute 提取 Internet 网络的详细信息和专用 IP 地址,在与正确的 IP 路由播发配合使用的情况下,该源 NAT 提供一种简单机制来确保路径对称。如果使用的是特定于 ExpressRoute 对等位置的有状态网络设备,则必须为每个 ExpressRoute 对等实现独立的 NAT 池,以确保路径对称。

有关详细信息,请参阅 ExpressRoute NAT 要求

向网络拓扑图添加对出站连接所做的更改。

大多数企业版 Office 365 部署采用从 Office 365 到本地服务的入站连接的某种形式,例如针对 Exchange、SharePoint 和 Skype for Business 混合方案、电子邮件迁移和使用 ADFS 基础结构的身份验证。当为 ExpressRoute 在本地网络和 Microsoft 之间再启用一条路由路径以实现出站连接时,这些入站连接有可能意外受到非对称路由的影响,即使打算让这些通信流继续使用 Internet 也是如此。建议采用下列所述的若干预防措施,以确保从 Office 365 到本地系统的基于 Internet 的入站流不受影响。

为将入站网络通信流的非对称路由风险降至最低,所有入站连接应在路由至用户的网络段(具有到 ExpressRoute 的路由可见性)之前使用源 NAT。如果允许传入的连接在不使用源 NAT 的情况下通往具有到 ExpressRoute 的路由可见性的网络段,则由 Office 365 发起的请求将从 internet 进入,但返回到 Office 365 的相应响应将首选 ExpressRoute 网络路径返回到 Microsoft 网络,导致非对称路由。

可以考虑使用以下实施模式之一来满足此要求:

  1. 在使用防火墙或负载平衡器等网络设备将请求路由到内部网络之前,对从 Internet 到本地系统的路径执行源 NAT。

  2. 请确保 ExpressRoute 路由不会传播至驻留有处理网络连接的入站服务(如前端服务器或反向代理系统)的网络段。

清楚核算网络中的这些方案并保持所有入站网络通信流通过 Internet 传递,这样有助于将部署和运营的非对称路由风险降至最低。

有些情况下,可能会选择通过 ExpressRoute 连接定向一些入站流。对于这些方案,请考虑以下注意事项。

  1. Office 365 仅可将使用公共 IP 的本地终结点作为目标。这意味着即使本地入站终结点通过 ExpressRoute 仅向 Office 365 公开,该终结点仍需具有与之关联的公共 IP。

  2. Office 365 服务用以解析本地终结点所有 DNS 名称解析均使用公共 DNS 执行。这意味着必须在 Internet 上注册入站服务终结点的 FQDN 至 IP 映射。

  3. 为通过 ExpressRoute 接收入站网络连接,这些终结点的公共 IP 子网必须通过 ExpressRoute 播发至 Microsoft。

  4. 仔细评估这些入站网络通信流,以确保根据公司的安全和网络策略对这些通信流应用正确的安全和网络控件。

  5. 本地入站终结点通过 ExpressRoute 播发至 Microsoft 后,对于包括 Office 365 在内的所有 Microsoft 服务的终结点而言,ExpressRoute 将有效成为首选的路由路径。这意味这些终结点子网只能用于与 Office 365 服务的通信,而不得用于 Microsoft 网络中的任何其他服务。否则,用户的设计将导致非对称路由,其中来自其他 Microsoft 服务的入站连接会首选通过 ExpressRoute 实现入站路由,而返回路径将使用 Internet。

  6. 如果 ExpressRoute 线路或汇接位置关闭,需确保仍可使用本地入站终结点通过独立网络路径接受请求。这可能意味着通过多条 ExpressRoute 线路为这些终结点播发子网。

  7. 建议为所有通过 ExpressRoute 进入用户网络的入站网络通信流应用源 NAT,尤其是当这些流通过防火墙等有状态网络设备时。

  8. 某些本地服务,例如 ADFS 代理或 Exchange 自动发现,可能会同时接收到来自 Office 365 服务和来自 Internet 用户的入站请求。对于这些请求,Office 365 将通过 Internet 把与用户请求相同的 FQDN 作为目标。如果允许从 Internet 到这些本地终结点的入站用户连接,同时强制 Office 365 连接使用 ExpressRoute,则意味着路由极其复杂。出于操作方面的考虑,不建议绝大部分客户通过 ExpressRoute 实施如此复杂的方案。此额外开销涉及管理非对称路由风险,这需要用户跨多个维度仔细管理路由播发和策略。

需要避免非对称路由,以确保组织内部人员可以无缝使用 Office 365 和 Internet 上的其他重要服务。有两种常见的客户配置会导致非对称路由。现在正是查看计划使用的网络配置并检查是否存在以下任一非对称路由情况的绝佳时机。

首先,来看看与下列网络关系图相关联的几种不同情况。在此关系图中,所有接收入站请求的服务器(如 ADFS 或本地混合服务器)都位于新泽西数据中心,并播发至 Internet。

  1. 在外围网络安全的情况下,没有可用于传入请求的源 NAT。

  2. 位于新泽西数据中心的服务器可同时查看 Internet 和 ExpressRoute 路由。

ExpressRoute 连接概述

我们还提供如何解决这些问题的建议。

问题 1:通过 Internet 实现的云到本地的连接

下面的关系图显示当网络配置不为从 Microsoft 云通过 Internet 发送的入站请求提供 NAT 时,将采用的非对称网络路径。

  1. 来自 Office 365 的入站请求会检索公共 DNS 的本地终结点的 IP 地址,并将请求发送至外围网络。

  2. 在此错误配置中,向其发送通信流的外围网络中没有配置源 NAT 或无可用的源 NAT,导致实际的源 IP 地址被用作返回目标。

    • 网络上的服务器通过任何可用的 ExpressRoute 网络连接将返回流路由到 Office 365。

    • 结果是此通信流使用非对称路径去往 Office 365,导致连接断开。

ExpressRoute 非对称路由问题 1

解决方案 1a:源 NAT

仅需将源 NAT 添加至入站请求,就可以解决此错误配置网络问题。在本关系图中:

  1. 传入请求持续通过新泽西数据中心的外围网络进入。此时源 NAT 可用。

  2. 服务器响应被路由回与源 NAT 关联的 IP,而非原始 IP 地址,导致响应沿相同的网络路径返回。

ExpressRoute 非对称路由解决方案 1

解决方案 1b:路由范围

或者,可选择不允许播发 ExpressRoute BGP 前缀,并删除这些计算机的备用网络路径。在本关系图中:

  1. 传入请求持续通过新泽西数据中心的外围网络进入。此时,通过 ExpressRoute 线路从 Microsoft 中播发的前缀对新泽西数据中心不可用。

  2. 服务器响应通过唯一可用的路由返回与原始 IP 地址关联的 IP,导致响应沿相同的网络路径返回。

ExpressRoute 非对称路由解决方案 2

问题 2:通过 ExpressRoute 实现的云到本地的连接

下面的关系图显示当网络配置不为从 Microsoft 云通过 ExpressRoute 发送的入站请求提供 NAT 时,将采用的非对称网络路径。

  1. 来自 Office 365 的入站请求会从 DNS 检索 IP 地址,并将请求发送至外围网络。

  2. 在此错误配置中,向其发送通信流的外围网络中没有配置源 NAT 或无可用的源 NAT,导致实际的源 IP 地址被用作返回目标。

    • 网络上的计算机通过任何可用的 ExpressRoute 网络连接将返回流路由到 Office 365。

    • 结果是发生与 Office 365 的非对称连接。

ExpressRoute 非对称路由问题 2

解决方案 2:源 NAT

仅需将源 NAT 添加至入站请求,就可以解决此错误配置网络问题。在本关系图中:

  1. 传入请求持续通过纽约数据中心的外围网络进入。此时源 NAT 可用。

  2. 服务器响应被路由回与源 NAT 关联的 IP,而非原始 IP 地址,导致响应沿相同的网络路径返回。

ExpressRoute 非对称路由解决方案 3

论证网络设计具有路径对称性

此时,需通过纸上论证,验证所制定的实施计划可针对将使用的不同方案(将在方案中使用 Office 365)实现路由对称性。将确定人员使用服务的不同功能时预期采用的特定网络路由。从本地网络和 WAN 路由,到外围设备,到连接路径;ExpressRoute 或 Internet,再到联机终结点连接。

需要为所有先前确定为组织将采用的 Office 365 网络服务执行此操作。

这有助于与另一个人在纸上论证路由的可行性。向他们解释预期每个网络跃点在何处获取其下一个路由,并确保熟悉这些路由路径。请记住,ExpressRoute 将始终向 Microsoft 服务器 IP 地址提供作用范围更广的路由,使其的路由成本相较使用 Internet 默认路由时更低。

设计客户端连接配置

通过 ExpressRoute 使用 PAC 文件

如果您使用的 internet 的代理服务器绑定流量然后您需要调整任何 PAC 或正确配置客户端配置文件,以确保您的网络上的客户端计算机发送到 Office 365 的所需的适用 ExpressRoute 通信,而不 transiting代理服务器和剩余的通信,包括一些 Office 365 的通信,发送到相关的代理。阅读我们的指南上管理 Office 365 端点例如 PAC 文件。

注意: 终结点更改频率较高,通常每周都会更改。应仅基于组织采用的服务和功能进行更改,以减少为保持最新状态而需更改的次数。需密切关注 RSS 源中的生效日期,此源中将发布更改,同时会保留过去所有更改的记录,发布的 IP 地址可能不会被播发,或从播发中删除,直到到达生效日期为止。

生成部署和测试过程

实施计划应包括测试和回退计划。如果实施未按预期运行,则计划应设计为将问题发现之前受影响的人员数降至最低。以下是计划中应考虑的一些高级别原则。

  1. 对网络段和用户服务载入进行分段,以将中断可能性降至最低。

  2. 计划从连接 Internet 的独立主机通过 traceroute 和 TCP 连接测试路由。

  3. 最好对入站和出站服务的测试应该进行测试 Office 365 租户独立的测试网络上。

    • 或者,如果客户尚未使用 Office 365 或位于试点中,也可对生产网络执行测试。

    • 或者,测试可以在生产中断期间执行,它被设置为仅供测试或监视使用。

    • 或者,通过针对每个服务在每个第 3 层路由器节点上检查路由来进行测试。此回退仅限在其它测试不可用时使用,因为物理测试的缺失可能导致产生风险。

应分阶段向小部分人员推出部署过程,这样便可在向更多人进行部署时执行测试。以下是分阶段部署 ExpressRoute 的若干方式。

  1. 使用 Microsoft 对等连接设置 ExpressRoute,并仅出于划分测试阶段的目的将路由播发转发给单个主机。

  2. 先将指向 ExpressRoute 网络的路由播发至单个网段,然后按网络段或地区扩张路由播发。

  3. 如果是首次部署 Office 365,请使用 ExpressRoute 网络部署对少数人员进行试点测试。

  4. 如果使用代理服务器,可以配置测试 PAC 文件,在添加更多人员之前,先将少数人员定向到 ExpressRoute 以进行测试和获得反馈。

实施计划应列出每个需执行的部署过程,或用于部署网络配置的命令。当网络中断时间到来时,所做的所有更改应来自预先撰写并经过同行审查的书面部署计划。请参阅有关 ExpressRoute 技术配置的指南。

  • 如果已为任何将继续发送电子邮件的本地服务器更改 IP 地址,请更新 SPF TXT 记录。

  • 如果已更改 IP 地址以适应新的 NAT 配置,请为本地服务器更新所有 DNS 条目。

  • 请确保已订阅 RSS 源以获得 Office 365 终结点通知,由此维护任何路由或代理配置。

完成适用 ExpressRoute 部署后应执行的测试计划中的过程。对于每个过程的结果应记录。必须包括在事件的测试计划结果指示实现未成功回滚到原始生产环境的过程。

测试过程应包括针对每个 Office 365 出站和入站网络服务进行的测试,其中包括将使用和不使用 ExpressRoute 的服务。该过程应包括从每个唯一网络位置(包括并非公司 LAN 中本地用户的人员)进行的测试。

以下是一些测试活动的示例。

  1. 从本地路由器 ping 到网络运算符路由器。

  2. 验证本地路由器接收到 500 多个 Office 365 和 CRM Online IP 地址播发。

  3. 验证入站和出站 NAT 正在 ExpressRoute 和内部网络之间运行。

  4. 验证,正从路由器公布路由到您的 NAT。

  5. 验证 ExpressRoute 已接受播发前缀。

    • 使用以下 cmdlet 来验证对等的广告:

    • Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
  6. 验证公共 NAT IP 范围未通过任何其他 ExpressRoute 或公共 Internet 网络线路播发至 Microsoft,除非该范围是前例中的那种更大范围的特定子集。

  7. 完成 ExpressRoute 线路配对,验证两个 BGP 会话正同时运行。

  8. 在 NAT 内部设置单个主机,使用 Ping、tracert 和 tcpping 来测试新线路到主机 outlook.office365.com 的连接。或者,可以在镜像端口上对 MSEE 使用 Wireshark 或 Microsoft 网络监视器 3.4 等工具,来验证是否可连接到与 outlook.office365.com 相关联的 IP 地址。

  9. 测试用于 Exchange Online 的应用程序级功能。

    • 测试 Outlook 是否能够连接到 Exchange Online 和发送/接收电子邮件。

    • 测试 Outlook 是否能够使用联机模式。

    • 测试 smartphone 连接性和发送/接收功能。

  10. 测试用于 SharePoint Online 的应用程序级功能

    • 测试 OneDrive for Business 同步客户端

    • 测试 SharePoint Online Web 访问。

  11. 测试用于以下 Skype for Business 呼叫方案的应用程序级功能:

    • 作为已验证身份的用户加入电话会议 [由最终用户发起邀请 ]。

    • 邀请用户加入电话会议 [从 MCU 发送的邀请]。

    • 使用 Skype for Business Web 应用程序作为匿名用户加入会议。

    • 从有线 PC 连接、IP 电话和移动设备加入会议。

    • 呼叫到联合的用户 o PSTN 验证的呼叫: 在完成呼叫、 呼叫质量是可以接受、 连接时间是可以接受。

    • 验证租户和联合用户的成员的当前联系人状态是否已更新。

非对称路由是最常见的实施问题。以下是一些可供查找的常见源:

  • 在没有源 NAT 的情况下使用开放或平面网络路由拓扑。

  • 未使用 SNAT 通过 Internet 和 ExpressRoute 连接路由到入站服务。

  • 不测试适用 ExpressRoute 上广泛部署之前测试网络上的入站的服务。

通过自己的网络部署 ExpressRoute 连接

分阶段每次部署到网络的一个段,通过针对每个新网络段的回退计划,逐步向网络的不同部分推出连接。如果部署与 Office 365 部署保持一致,则首先部署到 Office 365 试点用户,然后从此处扩展。

首先针对测试,然后针对生产:

  • 运行部署步骤以启用 ExpressRoute。

  • 测试网络路由按预期部署。

  • 对每个入站和出站服务执行测试。

  • 如果发现任何问题则执行回退。

现在已制定完整的纸上计划,可以开始进行小规模测试了。在此测试中,将通过 Microsoft 对等连接创建一个单独的 ExpressRoute 连接,以测试本地网络上的子网。可配置一个连接到测试子网的试用版 Office 365 租户,并在测试子网中含入所有将使用的出站和入站服务。为测试网络段设置 DNS,并创建所有入站和出站服务。执行测试计划,并确保熟悉每个服务的路由以及路由传播。

完成上述项后,核对已完成的部分,并确保自己和团队在执行部署和测试计划前已对其进行了检查。

  • 网络更改中涉及的出站和入站服务的列表。

  • 全局网络体系结构关系图,同时显示有 Internet 出口和 ExpressRoute 汇接位置。

  • 网络路由关系图,展示了用于所部属的每个服务的不同网络路径。

  • 部署计划,包含实施更改和回退(如果需要)的步骤。

  • 测试计划,用于测试每个 Office 365 和网络服务。

  • 已完成的针对入站和出站服务的生产路由的纸上验证。

  • 已完成的跨测试网络段的测试,包括可用性测试。

选择一个长度足以运行整个部署计划和测试计划的中断时段,如有需要,留出一些时间来执行故障排除和回退。

警告: 由于通过 Internet 和 ExpressRoute 进行路由较为复杂,建议在此时段中添加额外的缓冲时间,以执行复杂路由的故障排除。

QoS 是获得 Skype for Business Online 的语音和会议功能所必需的。可在确保 ExpressRoute 网络连接不阻止任何其他 Office 365 服务访问之后配置 QoS。有关 QoS 的配置,请参阅文章 Skype for Business Online 中的 ExpressRoute 和 QoS

对实施进行故障排除

首先要查看的是本实施指南中的步骤,实施计划中是否漏掉任何步骤?可能的话,返回并实施更小的网络测试,复制错误,并在那里进行调试。

确定测试期间哪些入站或出站服务发生故障。专门为故障的每个服务获取 IP 地址和子网。继续执行操作,在纸上论证网络拓扑关系图,并验证路由。专门验证 ExpressRoute 路由播发到的位置,如果可能,使用跟踪测试中断期间的路由。

使用网络跟踪的 PSPing 运行到每个客户终结点并评估以验证他们按预期的源和目标 IP 地址。运行远程登录到您在端口 25 上公开,并验证 SNAT 隐藏的原始源 IP 地址,是否这预期的任何邮件主机。

请记住,当使用 ExpressRoute 连接部署 Office 365 时,需要确保对 ExpressRoute 网络配置进行了最优设计,同时已优化网络中的其他组件(如客户端计算机)。除通过此计划指南来发现可能遗漏的步骤之外,我们还攥写了 Office 365 性能故障排除计划

可通过以下短链接返回:https://aka.ms/implementexpressroute365

相关主题

网络连接到 Office 365
适用于 Office 365 的 Azure ExpressRoute
管理适用于 Office 365 连接的 ExpressRoute
路由与适用于 Office 365 ExpressRoute
网络规划使用适用于 Office 365 ExpressRoute
使用 BGP 社区中适用于 Office 365 方案 (预览) ExpressRoute
媒体质量和 Skype for Business Online 中的网络连接性能
Skype for Business Online 优化您的网络
适用 ExpressRoute 以及在 Skype for Business Online QoS
呼叫流使用适用 ExpressRoute
Office 365 性能优化使用基线和性能历史记录
性能故障排除的 Office 365 计划
Office 365 Url 和 IP 地址范围
Office 365 的网络和性能优化

注意: 机器翻译免责声明:本文是由无人工介入的计算机系统翻译的。Microsoft 提供机器翻译是为了帮助非英语国家/地区用户方便阅读有关 Microsoft 产品、服务和技术的内容。由于机器翻译的原因,本文可能包含词汇、语法或文法方面的错误。

扩展你的技能
了解培训
抢先获得新功能
加入 Office 预览体验计划

此信息是否有帮助?

谢谢您的反馈!

谢谢你的反馈! 可能需要转接到 Office 支持专员。

×