Exchange 客户端及其面向公众的 Exchange 服务器 |第 13 部分#36

当前的文章将专门讨论从公共网络访问 Exchange 服务的 Exchange 客户端的主题。
重点是“公共 Exchange 客户端”，因为 Exchange 服务器与其 Exchange 客户端之间的通信通道的特征在公共环境中，与在被视为基于“专用”或“内部网络”的环境中的 Exchange 客户端和 Exchange Server 之间实现的通信通道具有不同的特征。

公共环境的主要特征以及Exchange服务器及其Exchange客户端的关系是：

• 面向公众的 Exchange 服务器 - 为了能够寻址 Exchange 服务器，应将 Exchange 服务器配置为“面向公众的 Exchange 服务器”。该术语的翻译是 - 具有公共 FQDN、公共 IP 和公共证书的 Exchange 服务器。此外，我们需要在防火墙\代理基础结构中进行所有必需的配置，以允许从外部客户端访问“内部”Exchange 服务器。

• 自动发现流程\流程 - 公共环境中的自动发现流程（其中自动发现客户端需要找到其自动发现端点）将不会通过使用对 Active Directory 的访问来实现，因为在公共环境中，Active Directory 服务不可用。相反，自动发现客户端将尝试使用预定义的命名结构和 DNS 基础结构来确定所需的自动发现端点，从而找到其自动发现端点。

问题1：Exchange 服务器是否必须配置为面向公众的 Exchange 服务器？

A1：不，从技术上讲，我们不必将 Exchange 服务器暴露给位于公共网络中的 Exchange 客户端。在大多数现代工作环境中，“业务需求”是使外部 Exchange 客户端能够访问组织邮件服务，但这不是强制性要求。

Q2：如果组织有多个站点，并且每个站点都包含多台Exchange服务器，我们是否需要“发布”所有现有的Exchange服务器？

A2：答案是否定的。例如，在包含多台 Exchange 服务器的站点中，我们只需要“公开”一台特定的 Exchange 服务器，该服务器将充当所有“内部 Exchange 基础架构”的代表。

当公共 Exchange 客户端对面向公众的 Exchange 服务器进行寻址时，Exchange 服务器“知道”如何将其请求路由到内部 Exchange 资源，并从内部 Exchange 资源向外部 Exchange 客户端提供“答案”。

在这种情况下，面向公众的 Exchange 服务器将具有两个不同的身份或接口：

• 用于内部\专用 Exchange 基础架构的一个接口
• Public Exchange 客户端的一个界面

面向公众的 Exchange CAS 服务器 |两个世界

为了能够演示 Exchange 服务器的“两个世界”——内部接口与外部接口以及这种不同环境的特征，让我们使用具有以下特征的基础设施场景：

我们场景中的Exchange环境的章程如下：

• Active Directory 内部域名是 - o365info.local
• 公共域名是 - o365info.com
• 组织用户的电子邮件地址基于邮件后缀 - o365info.com
• Exchange\Active Directory 站点 - 该组织有两个 Exchange\Active Directory 站点：纽约站点和洛杉矶站点（纽约站点是公司总部）。
• 纽约站点的 Exchange CAS 服务器的名称是 - exo1.o365info.local
• 洛杉矶站点中的 Exchange CAS 服务器的名称是 - exo2.o365info.local
• John 是一个组织的用户，他的邮箱托管在纽约交易所网站上。
• Alice 是一个组织的用户，其邮箱托管在 Los Angles Exchange 站点上。

Exchange CAS 服务器 - 内部和外部 FQDN 命名方案

规划或构建 Exchange 基础结构时的主要任务之一是命名方案（命名空间）的主题，其中包括内部和外部 Exchange 服务器 FQDN。

结果取决于特定的组织场景以及组织需要或想要向其内部和外部邮件客户端提供的服务。

在我们的示例中，我们将回顾需要访问其 Exchange 服务器（面向公众的 Exchange 服务器）的公共 Exchange 客户端的三种不同的可选方案。

很多时候，中小型组织只会“公开”一台 Exchange CAS 服务器，该服务器将充当“面向公众的 Exchange CAS 服务器”。

在企业公司在不同地理位置拥有多个站点的情况下，Exchange 公共基础设施将包括多个“面向公众的 Exchange CAS 服务器”。

例如，每个公司站点都可以有一个“面向公众的 Exchange CAS 服务器”。

在下一节中，我们将回顾四种不同的场景：

• 场景 1 和场景 2 将演示只有一个“面向公众的 Exchange CAS 服务器”的 Exchange 基础架构。
• 方案 3 和方案 4 将描述为每个公司 Exchange 站点（多个面向公众的 Exchange 服务器）使用“面向公众的 Exchange CAS 服务器”的 Exchange 基础设施。

我们将从一个简单的场景开始，然后转向更复杂或更高级的场景。

在下表中，我们可以看到为特定组织选择的命名方案（o365info.com ）

注意：下表包含我们将审查的所有场景的信息。某些简单或基本方案不会使用“Exchange FQDN”表中显示的所有信息。

纽约交易所 CAS 服务器

纽约站点的 Exchange CAS 服务器配置为“面向公众的 Exchange CAS 服务器”。

“纽约交易所 CAS 服务器”的内部或私有名称是 - exo1.o365info.local

我们将为“纽约交易所 CAS 服务器”使用三个“公共名称”：

• autodiscover.o365info.com
• mail.o365info.com
• owa.o365info.com

洛杉矶 Exchange CAS 服务器

“Los Angles Exchange CAS 服务器”的内部或私有名称是 - exo2.o365info.local

我们将为“Los Angles Exchange CAS 服务器”使用两个“公共名称”：

• mail-la.o365info.com
• owa-la.o365info.com

额外的考虑

公共 DNS 和 A 记录
此公共名称必须在公共 DNS 上重新“注册”并映射到“纽约 + 洛杉矶 Exchange CAS 服务器”公共 IP。

公共IP地址

在我们的场景中，尽管面向公众的 Exchange 服务器有多个主机名，但只有一个公共 IP 地址分配给“New York Exchange CAS 服务器”。 ”

邮件客户端对此事实不“感兴趣”。

使用多个主机名 (FQDN) 的原因只是为了方便。

例如，大多数时候，访问 Exchange Web 邮件服务的流行命名约定是使用主机名，例如 - owa.o365info.com

交换CAS服务器公共证书

“面向公众的 Exchange 服务器”向外部邮件客户端提供的证书需要包含我们提到的所有不同的 FQDN 名称。

请注意，公共服务器包括“纽约和洛杉矶 Exchange CAS 服务器”的内部名称 (FQDN)。
外部邮件客户端与此“内部 FQDN”无关，并且不需要验证此“内部 FQDN。 ”

此内部名称仅由从组织专用网络“内部”连接 Exchange CAS 服务器的内部邮件客户端使用。

面向公众的 Exchange CAS 服务器 |命名方案和交换服务

我们可以问自己的一个简单问题是——为什么要使用多个公共名称以及我们选择这些“特定名称”的目的是什么？

答案是这些公共名称基于标准命名约定。从技术上讲，我们可以只使用一个公共名称，选择其他公共名称或选择不同的主机名（自动发现主机名除外，它被视为保留名称）。

为“面向公众的 Exchange 服务器”选择的公共名称只是大多数时间使用的“标准名称”。

自动发现公共 FQDN

将查找自动发现端点的外部 Exchange 客户端（自动发现客户端）将查找特定主机名 - autodiscover.o365info.com

因此，该主机名是强制性的，我们不能选择其他或不同的名称。

注意：还有一种基于 SRV 记录的附加自动发现方法，允许我们为提供自动发现服务的“面向公共的 Exchange CAS 服务器”使用不同的名称，但我们不会审查此方法当前文章中的选项。

Exchange 网络邮件服务公共 FQDN

外部网络邮件客户端将使用主机名寻址面向公众的 Exchange 服务器 - owa.o365info.com

许多组织使用命名约定 - OWA + 来发布 Exchange 服务，这些服务提供外部邮件使用 Web 浏览器（Web 邮件客户端）访问其邮箱的选项).
如前所述，组织可以选择任何适合其需要的名称，并且没有强制要求选择该特定主机名（OWA）

面向公众的 Exchange 服务器的“公众 FQDN”

公共主机名 - mail.o365info.com 将用于所有其余的 Exchange Web 服务，例如 - 可用性服务（空闲\忙碌时间）、自动回复（外出）办公室）、统一消息传递等。

大多数情况下，此公共名称 (mail.o365info.com) 还将用于发布 Exchange MX 记录。

洛杉矶网站。

“面向公众的 Exchange 服务器洛杉矶 Exchange 服务器”必须使用不同的主机名，因为我们不能对不同的 Exchange 服务器使用相同的主机名。

注意 - 在最后一个场景中，我们将审查此规则的例外情况。可以通过使用 GeoDNS 来实现对不同 Exchange 服务器使用相同主机名的能力。

洛杉矶 Exchange 网络邮件服务公共 FQDN

外部网络邮件客户端将使用主机名来寻址面向公众的 Exchange 服务器 - owa-la.o365info.com

洛杉矶 - 面向公众的 Exchange 服务器的“公众 FQDN”

公共主机名 - mail-la.o365info.com，将用于所有其余的 Exchange Web 服务，例如 - 可用性服务（空闲\忙碌时间）、自动回复（外出）、统一消息等。

外部 Exchange 邮件客户端访问 - 场景

在下一节中，我们将回顾“外部 Exchange 客户端访问方案”的几个选项

每个方案中的工作流描述不包括 Exchange 邮件客户端和面向公众的 Exchange CAS 服务器之间的通信过程中涉及的所有详细信息。

主要目的只是提供公共 Exchange 客户端和面向公众的 Exchange 服务器之间实现的通信通道的高级视图。

• 公共自动发现客户端如何找到其自动发现端点。
• 面向公众的 Exchange 服务器如何通过提供公共证书来识别自己的身份？
• 自动发现客户端如何获取所需的自动发现信息（自动发现服务器响应）。

注意 - 还有一种基于 SRV 记录的附加自动发现方法，允许我们为提供自动发现服务的“面向公共的 Exchange CAS 服务器”使用不同的名称，但我们不会在当前文章中讨论此选项。

1. ECP URL 地址
   ECP（Exchange 控制面板）由 OWA 等 Web 邮件客户端使用，用于使用 OWA Web 界面管理和配置许多用户设置。
2. EWS URL 地址 - Exchange 使用 EWS（Exchange Web 服务）URL 来提供各种 Web 服务，例如可用性服务（空闲/忙碌时间）、自动重播（外出）、邮件提示等。

场景 1：外部邮件客户端的 Exchange 邮件服务 |简单场景

在这种情况下，John 尝试从公共网络访问纽约交易所站点上托管的邮箱。约翰想要创建一个新的 Outlook 邮件配置文件。

John 需要提供的信息是 - 他的电子邮件地址 ([email protected] ) + 他的用户凭据。

在这种情况下，我们将“忽略”其他公司 Exchange 站点（洛杉矶），仅关注外部邮件客户端访问“面向纽约公众的 Exchange CAS 服务器”时的自动发现工作流程。

第 1 步：外部邮件客户端 |自动发现过程

由于 John 位于公共网络上，因此自动发现方法（其中自动发现客户端连接本地 Active Directory 以获取有关可用 Exchange CAS 服务器的信息）对他不可用因为内部 Active Directory 并未“暴露”到公共网络。

在这种情况下，“定位潜在自动发现端点”的自动发现过程是通过查找从收件人电子邮件地址中提取的自动发现端点主机名来实现的。
在我们的示例中，John 将通过以下方式查找自动发现端点：使用主机名 - o365info.com （数字1）。

在我们的场景中，此主机名未发布，并且由于自动发现客户端找不到此类主机名，因此自动发现客户端将创建一个新的 DNS 查询来查找主机名 - autodiscover.o365info.com

第 2 步：连接面向公众的 Exchange CAS 服务器

在我们的场景中，组织使用“New York Exchange CAS 服务器”作为面向公众的 Exchange CAS 服务器。

外部邮件客户端使用 HTTPS 协议发起与面向公众的 Exchange 服务器的连接尝试。
邮件客户端将要求服务器通过提供公共证书（编号2）来证明其身份）。

第 3 步 - 验证 Exchange 服务器公共证书

邮件客户端将验证服务器证书是否包含 FQDN - autodiscover.o365info.com

注意：如果面向公众的 Exchange 服务器使用通配符证书；自动发现客户端将仅验证域名的一部分，在我们的例子中 - o365info.com。

如果外部邮件客户端验证 Exchange 证书“OK”，则客户端还将提供其身份（用户名和密码）。

步骤 4 - Exchange 客户端请求 Exchange 服务器提供 autodiscover.xml 文件

外部邮件客户端将请求 Exchange 服务器为其提供所需的 autodiscover.xml 文件（编号4）。

第 5 步 - Exchange 服务器向 Exchange 客户端提供自动发现响应 (autodiscover.xml)

Exchange 服务器向外部邮件客户端发送所需的自动发现响应（编号5）。

在下面的屏幕截图中，我们可以看到 autodiscover.xml 文件内容的一个小示例。

• Exchange EWS 服务 - 我们可以看到 Exchange EWS 服务的 URL 地址是通过使用主机名提供的 - o365info.com
• Exchange ECP - Exchange 控制面板的 URL 地址（网络邮件客户端用于配置用户设置的 Web 地址）包括主机名 - o365info.com

场景 2：外部邮件客户端的 Exchange 邮件服务 |面向公众的单一 Exchange CAS 服务器 |多个交换站点

在下一个场景中，Alice 尝试从公共网络连接到她的邮箱。

如前所述，该组织有两个 Exchange 站点。 Alice 的邮箱托管在位于洛杉矶站点的 Exchange CAS 服务器上。
洛杉矶站点中的 Exchange CAS 服务器是“非面向公共的 Exchange CAS 服务器”。

简单来说，外部邮件客户端无法直接连接此 Exchange 服务器。

为了能够向外部邮件客户端提供邮件服务，选择作为具有公共可用性的“代表”（面向公众的 Exchange CAS 服务器）的 Exchange CAS 服务器是来自纽约站点的 Exchange CAS 服务器。

第 1 步：外部邮件客户端 |自动发现过程

当 Alice 启动 Outlook 时，Outlook 客户端将尝试寻找自动发现端点。

在这种情况下，自动发现过程是通过查找从收件人电子邮件地址中提取的自动发现端点主机名来实现的。

在我们的示例中，Alice Outlook 客户端将使用主机名 - o365info.com （编号 1）查找自动发现端点。
在我们的示例中在这种情况下，此主机名未发布，并且由于自动发现客户端找不到此类主机名，因此自动发现客户端将创建一个新的 DNS 查询来查找主机名 - autodiscover.o365info.com

第 2 步：连接面向公众的 Exchange CAS 服务器

在我们的场景中，组织使用“纽约 Exchange CAS 服务器”作为面向公众的 Exchange 服务器。

请注意，Alice 的邮箱位于洛杉矶站点的 Exchange CAS 服务器上。

外部邮件客户端使用 HTTPS 协议发起与面向公众的 Exchange 服务器的连接尝试。
邮件客户端将要求服务器通过提供公共证书（编号2）来证明其身份）。

第 3 步 - 验证 Exchange 服务器公共证书

邮件客户端将验证服务器证书是否包含 FQDN -autodiscover.o365info.com

如果外部邮件客户端验证 Exchange 证书“正常”，则客户端还将提供其身份（用户名和密码）。

第 4 步 - 请求 Exchange 服务器提供 autodiscover.xml 文件

外部邮件客户端将要求 Exchange 服务器提供所需的 autodiscover.xml 文件（编号4）。

第 5 步 - Exchange 向邮件客户端提供 autodiscover.xml

Exchange 服务器向外部邮件客户端发送所需的 autodiscover.xml 文件（编号5）。

在下图中，我们可以从 autodiscover.xml 文件的内容中看到一个示例。

• Exchange EWS 服务 - 我们可以看到 Exchange EWS 服务的 URL 地址是使用主机名提供的 - o365info.com
• Exchange ECP - Exchange 控制面板的 URL 地址（Web 邮件客户端用于配置用户设置的 Web 地址）包括主机名 -
  o365info.com

第6步-外部邮件客户端访问邮箱数据|代理机制

请注意一个有趣的事实，Alice 无法直接连接她的 Los Angles Exchange CAS 服务器 - exo2.0365info.com

相反，每次 Alice 需要访问其邮箱中的数据时，请求都会到达 New York Exchange 服务器（具有公共可用性的 Exchange 服务器）； New York Exchange 服务器将创建一个 LDAP 查询，查找托管 Alice 邮箱的 Exchange CAS 服务器。

当 New York Exchange CAS 服务器发现托管 Alice 邮箱的 Exchange CAS 服务器是 - exo2.0365info.com 时，他将创建一个连接请求，要求“获取”信息来自 Alice 的邮箱（号码6）。

Exchange CAS 服务器从另一个 Exchange CAS 服务器（提供对所需用户邮箱的访问的 Exchange CAS 服务器）发送数据记录的方法，描述为“代理”。 ”

第 7 步 - 返回所需数据

洛杉矶 Exchange CAS 服务器 (exo2.0365info.com) 将所需的邮箱数据返回到纽约 Exchange CAS 服务器 (exo1.0365info.com)。 com）。

New York Exchange 服务器，向外部邮件客户端发送或提供所需的邮箱数据（号码7和号码8）。

字首

以下两个方案与 Exchange 基础结构相关，其中包括多个 Exchange 站点以及各种面向公众的 Exchange CAS 服务器。

理论上，可能只有一个“焦点”代表域自动发现端点。

稍后（在场景4中），我们将了解如何实现不同的网络基础设施，使我们能够克服这一理论限制。

场景 3：外部邮件客户端的 Exchange 邮件服务 |多个面向公众的 Exchange CAS 服务器 |多个交换站点

在以下场景中，每个 Exchange 站点都由面向公众的 Exchange 服务器表示。

在我们开始详细了解自动发现工作流程之前，重要的是要了解自动发现客户端知道如何查找代表自动发现端点的预定义主机名。

在我们的示例中，外部邮件客户端将查找的自动发现端点名称是 - autodiscover.o365info.com

我们现在面临的挑战是——“我们如何使用相同的主机名发布两个不同的面向公众的 Exchange CAS 服务器？

我们是否应该将 autodiscover.o365info.com DNS 记录指向纽约站点 Exchange CAS 服务器，或者，我们是否应该指向
自动发现。 o365info.com DNS 记录到洛杉矶站点Exchange CAS 服务器上？

在我们的场景中，我们将继续将 autodiscover.o365info.com 记录指向面向公众的纽约交易所 CAS 服务器的公共 IP 地址。

当其邮箱托管在洛杉矶站点的外部邮件客户端将连接面向公众的纽约 Exchange CAS 服务器时，面向公众的纽约 Exchange CAS 服务器将回复一条特定的重定向消息，该消息会将外部邮件客户端指向他们的“面向公众的洛杉矶 Exchange CAS 服务器”。

为了使自动发现工作流程更“易于理解”，我将省略该过程的某些部分。

步骤1、2、3和4 - 外部邮件客户端查找主机的公共IP地址 - autodiscover.o365info.com 并尝试创建 HTTPS 会话。

外部邮件客户端将请求服务器证书并验证证书是否有效。

由于证书测试成功完成，外部邮件客户端假定他到达了“正确的 Exchange CAS 服务器”。 ”

邮件客户端将从服务器请求 autodiscover.xml 文件

现在，上述方案之间的主要区别是：面向纽约公众的 Exchange CAS 服务器发送重定向消息，而不是向邮件客户端提供所需的 autodiscover.xml 文件。

重定向消息包括面向洛杉矶公众的 Exchange CAS 服务器所使用的主机名。

在我们的场景中，主机名是 - mail-la.o365info.com

现在，外部邮件客户端的旅程重新开始。

外部邮件客户端需要获取主机的公共IP地址 -
mail-la.o365info.com

外部邮件客户端获取所需的公共IP地址后，邮件客户端会检查主机mail-la.o365info.com是否可以使用HTTPS协议进行通信。

如果洛杉矶面向公众的 Exchange 服务器“开放”使用端口 443 进行通信，则外部邮件客户端将发送服务器证书请求。

当面向洛杉矶公众的 Exchange CAS 服务器提供其证书时，邮件客户端将检查服务器证书是否包含主机名 -
mail-la.o365info.com

相互身份验证过程完成后，外部邮件客户端会请求 autodiscover.xml 文件。

在下图中，我们可以看到；我们可以从autodiscover.xml文件的内容中看到一个小例子。

请注意，URL 地址包括“属于”洛杉矶面向公众的 Exchange CAS 服务器的公共 FQDN

场景 4：外部邮件客户端的 Exchange 邮件服务 |多个面向公众的 Exchange CAS 服务器 |多个交换站点 |地理域名系统

在下面的场景中，我们将回顾一个基于使用 GeoDNS 功能的不错的解决方案。

“GeoDNS”一词描述了一种“智能 DNS 服务器”技术。

在标准 DNS 会话中，DNS 客户端向 DNS 服务器查询特定主机名，然后 DNS 服务器使用其数据库中的信息进行回复，GeoDNS 的功能使 DNS 服务器能够识别其地理位置。 “客户”并根据这些信息提供不同的答案。

在以下场景中，我们将使用 GeoDNS 选项来发布有关自动发现记录的信息。

主机名 - 自动发现将同时指向两个不同的 Exchange 服务器。

当地理位置在纽约的用户向 DNS 服务器查询主机名 - autodiscover.o365info.com 时，DNS 服务器将“识别”他的地理位置并为他提供信息“面向纽约公众的 Exchange 服务器”的公共 IP 地址。

Exchange 客户端也是如此，其地理位置位于洛杉矶。

每次“洛杉矶”邮件客户端向 DNS 查询主机的公共 IP - autodiscover.o365info.com 时，DNS 服务器都会为其提供公共 IP 地址“洛杉矶面向公众的 Exchange 服务器”。

John 是其邮箱托管在纽约 Exchange 站点的用户，Alice 是其邮箱托管在洛杉矶 Exchange 站点的用户。

假设两者都完成了查找面向公众的 Exchange CAS 服务器、身份验证等所有阶段。

当 John 向他的“自动发现端点”询问包含有关现有公共 Exchange 服务所需信息的 autodiscover.xml 文件时，答案将由面向纽约公众的 Exchange CAS 服务器发送，并将包含该公共主机名 (FQDN) “映射”到面向纽约公众的 Exchange CAS 服务器的公共 IP 地址。

当 Alice 获取她的 autodiscover.xml 时，该文件的内容将包括指向面向洛杉矶公众的 Exchange CAS 服务器的公共主机名称的不同信息。