交换公共基础设施|公开与非公开的交换网站 | 5#23

本篇文章专门讨论 Exchange 公共基础设施的主题。
当我们涉及 Exchange 2013 共存环境和客户端协议连接流程的主题时，决定和影响的最基本因素之一是“客户端协议连接流程”是 Exchange 客户端的物理位置。

简而言之，寻址 Exchange CAS 服务器的 Exchange 客户端是否被视为位于公共网络上的 Exchange 客户端，还是我们在内部\私人组织网络中找到的 Exchange 客户端。

因此，我们有必要更好地理解交易所公共基础设施的一些基本概念和特点。

交换公共基础设施|基本术语

让我们从最基本的术语开始：面向公众的 Exchange CAS 服务器和面向公众的 Exchange 站点。

术语“面向公众的 Exchange 站点”涉及对位于公共网络的 Exchange 客户端“公开”或“可用”的 Exchange 基础设施。

从技术上讲，不存在“面向公众的 Exchange 站点”这样的东西，因为实际上，我们不发布 Exchange 站点，而是发布该站点的“代表”，该站点被描述为面向公众的 Exchange CAS 服务器。

面向公众的 Exchange CAS 服务器的职责

1.服务和保护

面向公众的 Exchange CAS 服务器的“工作”是隐藏和保护不暴露于公共网络的“内部 Exchange 基础设施”。

2.代理或重定向

接受外部 Exchange 客户端请求的面向公众的 Exchange CAS 服务器根据从 Active Directory 中“提取”的有关 Exchange 用户的信息做出必要的决定。

面向公众的 Exchange CAS 服务器的“决定”取决于几个因素，例如 - 托管用户邮箱的 Exchange 邮箱服务器的位置，如果“目标 Exchange 站点”被视为私有（内联网）或“ public”（面向公众的 Exchange 站点）、Exchange 客户端的类型等。

基于不同因素的权重，面向公众的 Exchange CAS 服务器将决定是自行将外部 Exchange 客户端请求代理到目标 Exchange 服务器，还是引导外部 Exchange 客户端寻址其他面向公众的 Exchange CAS 服务器或其他面向公众的 Exchange CAS 服务器。交换站点。

3.处理不同Exchange客户端的连接请求

面向公众的 Exchange CAS 服务器必须足够智能，并且能够同时“讲”多种语言。

每个不同的 Exchange 客户端“讲”不同的语言，并且面向 Exchange CAS 服务器的公众需要识别特定的 Exchange 客户端类型（例如 Outlook、ActiveSync 或 OWA），并使用所需的“语言”与特定的 Exchange 客户端进行通信。

发布 Exchange 基础结构的需求是否是强制性的？

从技术上讲，没有强制需要向公共环境“公开”Exchange 基础结构或服务，但是，99% 的情况下，组织业务的要求规定需要向 Exchange 客户端公开至少部分 Exchange 环境。位于公共网络上。

私人与公共交换基础设施同义词和反义词

Exchange 私有环境与公共环境的“令人困惑的部分”是使用许多同义词来描述不同的 Exchange 基础架构。

例如，以下术语用于描述对外部 Exchange 客户端可用或“公开”的 Exchange 环境：

• 面向公众的 Exchange CAS 服务器
• 面向公众的交换站点
• 面向互联网的网站
• 面向互联网的广告网站
• 外部客户端连接流程

我们使用以下术语列表来描述不暴露于公共网络（可以由外部客户端连接）且仅适用于连接到私有组织网络的 Exchange 客户端的 Exchange 站点：

• 内联网站点
• 内部站点
• 面向互联网的广告网站
• 非面向互联网的广告网站
• 非面向互联网的网站
• 内部客户端连接流程
• 外部客户端连接流程

“代表”的概念

公共 Exchange 邮件基础设施的实施基于我所描述的一个概念：“以 Exchange CAS 服务器为代表”

当我们需要将我们的邮件基础设施“暴露”到公共\外部网络时，基本的假设是我们希望最大限度地减少“暴露”可能的公共网络威胁。

为了启用外部 Exchange 客户端访问“内部 Exchange 邮件服务”的机制，同时“保护”内部 Exchange 邮件基础设施免受可能的公共网络威胁，我们“决定”一个非常特殊的 Exchange CAS 服务器将充当： 面向公众的 Exchange CAS 服务器。

外部 Exchange 客户端对邮件服务的请求将“指向”专用的面向公众的 Exchange CAS 服务器。
面向公众的 Exchange CAS 服务器将执行识别外部 Exchange 客户端的过程，并在验证外部 Exchange 客户端的身份后外部 Exchange 客户端，通过将其请求代理到内部 Exchange 服务器来为外部 Exchange 客户端提供服务，或者在某些情况下，将外部 Exchange 客户端重定向到“其他 Exchange 服务器”。
或 -“其他面向公众的 Exchange 站点”。

Exchange 公共邮件基础设施 |多种场景

“Exchange 公共邮件基础设施”一词可以翻译成许多可能的场景。

在下一节中，我们将回顾实施 Exchange 公共邮件基础设施的几种可能方案。

场景 1：公共交换基础设施 |中心化模式

我将 Exchange 基础设施描述为：“中心化模型”，基于以下特征：

一个组织，在不同的地理位置拥有多个站点。

只有一个公司站点：纽约站点配置为 - 面向公众的 Exchange 站点。

“面向纽约公众的 Exchange CAS”将被设置为公共自动发现端点，并将使用主机名进行发布：autodiscover.o365info.com

此外，“纽约面向公众的 Exchange CAS”将使用公共主机名进行发布：mail.o365info.com
外部 Exchange 客户端使用的公共名称将“面向纽约公众的 Exchange CAS”称为“邮件服务器”，使他们能够访问其邮箱内容。

在“公共 Exchange 客户”场景中，来自公司各地（例如洛杉矶、马德里和纽约）的所有公司员工都将向面向公众的 Exchange 站点发表讲话，该站点以“纽约面向公众的 Exchange CAS”为代表。 ”

公共自动发现记录：autodiscover.o365info.com 指向“面向纽约公众的交易所 CAS”。

在下图中，我们可以看到集中式模型的基础设施。只有一个特定站点被视为：“面向公众的 Exchange 站点。所有外部 Exchange 客户端都将“指向”面向公众的 Exchange 站点，或者如果我们想要更准确的话：指向面向公众的 Exchange CAS 服务器，并且面向公众的 Exchange CAS 服务器将通过以下方式“处理”外部 Exchange 客户端请求：将他们的请求代理到所需的内部 Exchange 资源。

如果位于公共网络中的组织用户需要访问 Exchange 基础设施，则通向 Exchange 基础设施的“网关”或“门”是：公司总部站点，该站点具有面向公众的 Exchange CAS 服务器。
面向公众的 Exchange CAS 服务器充当 Exchange 客户端的“焦点”，其邮箱托管在纽约站点和公司所有其他站点（马德里 + 洛杉矶站点）上。

“其他”公司站点（马德里 + 洛杉矶站点）没有“公共可用性”，或者在其他方面，外部 Exchange 客户端无法直接访问这些词。

来自马德里 + 洛杉矶站点（未暴露于公共网络的站点）的 Exchange 用户将连接纽约站点中面向公众的 Exchange CAS 服务器。

当“面向纽约公众的 Exchange CAS”接受来自外部 Exchange 客户端的连接请求时，他将根据特定 Exchange 客户端的位置决定“做什么”或“如何代理”客户端请求到适当的服务器（托管 Exchange 用户邮箱的 Exchange 邮箱服务器）。

场景 2：公共交换基础设施 |分布式模型

第二种模型可以描述为：“分布式模型”，有时也可以描述为“区域模型”。 ”

“分布式模型”基于一个概念，其中每个物理公司站点（或特定公司站点）都由专用的面向公众的交换站点代表。

此模型背后的想法是优化面向公众的 Exchange CAS 服务器提供的性能和响应时间。

属于站点 A 的 Exchange 客户端将访问代表站点 A 的面向公众的 Exchange CAS 服务器，依此类推。

在这种情况下，组织决定“公开”多个 Exchange 站点。
例如，Exchange 公共基础设施将包括位于美国的公司总部站点以及位于欧洲的公司站点。

请注意，该公司在不同地区还有一个未暴露于公共网络的附加站点：洛杉矶站点，被描述为非面向互联网的站点。

为了能够区分两个公共可用的 Exchange 站点，每个站点将使用不同的命名空间。

例如 - 使用 FQDN 发布的总部面向公众的 Exchange CAS 服务器： mail.o365info.com 和欧洲站点的面向公众的 Exchange CAS 服务器将由使用 FQDN：europe.mail.o365info.com

外部欧洲 Exchange 用户将使用“欧洲命名空间”来连接 Exchange 基础设施。

所有其余外部 Exchange 用户将连接到总部面向公众的 Exchange CAS 服务器。

Exchange 服务器 公共可用性与内部 Exchange 服务器

交换外部和内部 FQDN 和 URL 地址

我想澄清的另一点是 Exchange 外部和内部 URL 地址。

在上一节中，我们了解了 Exchange 组织基于多个面向 Internet 的站点的场景，并且在某些场景中，Exchange CAS 服务器可以决定将 Exchange 客户端的请求重定向到“其他 Exchange CAS 服务器”其他交换站点。其他选项是向 Exchange 客户端提供自动发现信息，其中包括“其他面向公众的 Exchange CAS 服务器”的“链接”（URL 地址和 FQDN）。

现在可能出现的问题是：Exchange CAS 服务器如何了解“其他面向公众的 Exchange CAS 服务器”？

答案很简单：在“外部 URL 地址”字段中具有“值”的 Exchange CAS 服务器，被视为“面向公众的 Exchange CAS 服务器”。

当我们在“外部URL”部分填写信息（URL地址）时，该信息将发布在Active Directory中，并且该信息可供所有Exchange服务器使用。

每次我们使用诸如“面向公众的 Exchange CAS 服务器”之类的术语时，其含义是“存在”其虚拟目录已填充ExternalURL 属性的 Exchange CAS 服务器。

我们可以用“否定”来表达同样的意思：非面向 Internet 的 Exchange 站点，简单地说，任何包含 Exchange CAS 服务器且其虚拟目录未填充ExternalURL 属性的 Active Directory 站点。

交换外部和内部 FQDN 和 URL 地址

Exchange 公共基础设施的另一个构建块是术语：URL 地址和 FQDN

Exchange 客户端通过使用包含特定主机名 (FQDN) 的 URL 地址或直接寻址特定主机名来访问或寻址 Exchange 服务器。

例如。在下图中，我们可以看到 Exchange Web 服务的 URL 地址的示例。

提供 Exchange Web 服务的 Exchange 主机是：mail.o365info.com
当 Exchange 客户端使用此 URL 时，他知道他应该寻址的 Exchange 服务器是: mail.o365info.com

在其他情况下，Exchange 客户端将使用代表 Exchange 服务器的特定 FQDN（主机名），

例如，“属于”组织名为：o365info.com 的外部 Exchange 客户端将通过查找名为：autodiscover.o365info.com 的自动发现端点来启动通信过程。

另一个示例可能是 Outlook 客户端使用的 RPC 端点名称。在我们的场景中，面向公众的 Exchange CAS 服务器充当： 名为 mail.o365info.com 的外部 Outlook 客户端的 RPC 端点

将提供给外部 Exchange、Outlook 客户端的自动发现信息将包括对主机名的引用：

外部 FQDN 与内部 FQDN

与公共 Exchange 客户端基础结构相关的另一个重要观察结果是外部 FQDN 名称与内部 FQDN 名称的主题。

每个 Exchange 服务器都必须由主机名 (FQDN) 表示。

• 内部 FQDN 名称 - Exchange 客户端主机名可以描述为私有，在这种情况下，位于私有公司网络上的唯一内部 Exchange 客户端将能够使用特定主机名寻址和访问特定 Exchange 服务器。
• 公共 FQDN 名称 - Exchange 客户端主机名可以描述为 - 公共，以防外部 Exchange 客户端可以寻址和访问特定 Exchange 服务器。为了能够供外部 Exchange 客户端使用，配置为面向公众的 Exchange CAS 服务器和 Exchange 服务器主机名的 Exchange 服务器必须在外部\公共 DNS 服务器中发布。

多个面向公众的交换站点

在多个面向公众的 Exchange 站点的方案中，每个面向公众的 Exchange 站点都需要有一个代表： 面向公众的 Exchange CAS 服务器，它将接受来自外部 Exchange 客户端的通信请求。

例如，一家公司拥有两个面向公众的 Exchange 站点，一个站点位于纽约，另一个站点位于马德里。

• 代表纽约的面向公众的 Exchange CAS 服务器将按主机名 (FQDN) 发布：mail.o365info.com
• 代表马德里的面向公众的 Exchange CAS 服务器将按主机名 (FQDN) 发布：europe.mail.o365info.com