域名、FQDN 和 URL 地址的基础知识 |交换基础设施 |第 09#36 部分

Exchange 客户端和 Exchange 服务器之间的通信通道基于一个简单的概念，其中 Exchange 客户端使用 Exchange 主机名（或者，如果我们想要更准确的话）使用 Exchange 服务器 FQDN 来寻址 Exchange 服务器。

Exchange 服务器向请求 Exchange Web 服务的 Exchange 客户端提供的各种服务，以及 Webmail 客户端（例如 OWA）的服务，都是由使用 URL 地址访问此 Exchange 服务的 Exchange 客户端实现的。

关于 Exchange 服务器和 Outlook 客户端之间存在的关系，所有这些信息都通过 Exchange 服务器提供的自动发现响应打包并传送到 Outlook 客户端。

正如上一篇文章中提到的，每个面向公众的 Exchange 服务器都有两个身份 - 私有身份与公共身份。

当 Exchange 提供有关可用 Exchange Web 服务的信息时，该信息以两种不同的“格式”提供：

• 与内部 Outlook 客户端相关的信息
• 与外部 Outlook 客户端相关的信息

为内部和外部 Outlook 客户端提供的信息的主要区别在于 Exchange Web 服务 URL 地址。

• 与内部 Outlook 客户端相关的信息包括使用内部 Exchange FQDN 的 Exchange Web 服务 URL 地址。
• 与外部 Outlook 客户端相关的信息包括使用外部 Exchange FQDN 的 Exchange Web 服务 URL 地址。

URL 地址概念和 Exchange Web 服务

虽然显然我们熟悉使用网址 (URL) 的概念，但我想将以下部分专门讨论自动发现和 URL 地址这一主题，因为该主题并不像看起来那么简单。

在成为“自动发现专业人士”的过程中，我们需要熟悉

1. Exchange Web 服务 URL 地址的结构
2. 由地址 Web 服务 URL 地址组成的不同部分
3. Exchange 为内部邮件客户端和外部邮件客户端提供的不同 URL 地址。

此外，可能出现的问题可能是：

1. Exchange CAS 服务器如何设置 Web 服务的 URL 地址？
2. 我们是否应该“干预”Exchange Web 服务 URL 地址的默认设置？
3. 哪些场景需要我们实施这种“干预”？
4. Exchange Web 服务的 URL 地址是否有最佳实践？

与往常一样，这个问题没有一个简单的答案。
在当前文章中，我们将重点讨论 Exchange Web 服务 URL 地址的“物理结构”

URL地址的结构 |高层视图

让我们从一个非常简单的问题开始：
问。你知道URL代表什么吗？

A：嗯……我不会用学术讨论来烦你们，但是，对于那些不知道答案的人来说，URL 代表统一资源定位符。

我们大多数人都会将术语“URL”与浏览器、网站等术语联系起来。

“浏览器”只是可以使用基于 Web 的服务的“客户端”的一个示例。

实际上，有许多类型的“客户端”可以使用基于 Web 的服务。
例如，Outlook 就是一个严重依赖于 Exchange Web 服务的客户端。

URL地址的结构

URL 地址就像一个拼图，由许多部分组成。

URL地址的“乞求”将“声明”客户端和服务器将使用的协议（语言）。在基于Exchange的环境中，Web服务是通过使用HTTP协议和HTTPS协议（HTTP协议的加密版本）来提供的。

URL地址的“中间部分”包括有关主机的信息或将提供Web服务的“元素”名称。

大多数时候，我们用于“指向”提供特定 Web 服务的主机的命名约定基于 FQDN（完全限定域名）命名约定。

URL 地址的“最后部分”或“右侧部分”包括特定 Web 服务的路径。 “路径”不是 URL 地址的强制部分。

如果特定主机提供了几个 Web 服务，或者我们希望将客户端指向特定的文件夹或文件，则我们使用“way”选项。

例如，Exchange CAS服务器提供多种类型的Web服务。当 Exchange 客户端需要来自 Exchange CAS 服务器的特定 Web 服务时，Exchange 客户端必须使用包含 Exchange CAS 服务器名称 + 特定 Web 服务的路径的 URL 来寻址 Exchange CAS 服务器。

在本文中，我们将仅关注 Exchange Web 服务 URL 地址的“中间部分”（主机名或 FQDN 名称），因为如果我们需要配置或调整特定 Exchange Web 服务的 URL 地址，我们将更新或设置与 Exchange 主机名相关的部分。

我们更新 Exchange Web 服务 URL 地址的“路径”部分的情况非常罕见，不建议这样做。

主机名与 FQDN 名称

主机名是我们用来寻址特定网络“元素”的逻辑名称。
我们可以将术语主机名定义为“单个名称”或“单字名称”。

FQDN 一词代表 - 完全合格的域名。
对我来说，FQDN 这个词听起来总是很奇怪。

术语“完全限定域名”定义了命名约定，但术语 FQDN 涉及“完整主机名”，而不是使用单个主机名进行评级的术语“主机”。

FQDN 使用以下公式创建：

为了能够更好地理解术语主机名和术语 FQDN 名称之间的区别，我们可以将其与标准的“人类地址”联系起来。 ”

当我们使用名称“John”来指代某人时，这相当于术语“主机名”。 “John”这个名字不能被视为唯一标识符。

如果我们需要将包裹发送给约翰，我们将需要使用一个地址，该地址将是唯一标识符，并使我们能够确保包裹发送到所需的目的地收件人。

在这种情况下，我们将使用约翰的“完整”或“完整”地址，包括他的姓氏、街道地址、城市等。

我们可以说 John 的“完整地址”与我们在网络环境中使用他的 FQDN 来寻址特定主机的场景相同。

从技术上讲，在内部网络中，我们可以仅使用主机名来寻址特定的“主机”，但大多数时候，寻址“服务器”或提供服务的主机的首选方法是使用主机的 FQDN。

在公共网络环境中，对主机进行寻址的唯一方法是使用其 FQDN。

域名

域名也是一种基于特定结构的命名约定。
官方域名由组织名称和域名后缀组成。

注意：实际上，术语“域名”比这个简化的描述更复杂，并且可以包含其他部分，例如子域等。

域名后缀

每个域名都有一个后缀（就像每个项目符号都有一个地址一样）。域名可以分为私有或公共。

私有域名后缀

基于非公开后缀的私有域名后缀（是的，我知道这句话不太清楚）。
换句话说——私有域名后缀不能在公共网络上发布。如果我们想使用私有域名后缀，从技术上讲，我们可以发明任何我们想要的名称。

例如，私有域名后缀的可用选项可以是 blab la，完整域名可以是 - o365info.blabla

公共域名后缀。

基于公共后缀的公共域名后缀。
如果我们想要使用公共域名后缀，我们需要从公共提供商处购买域名，并且公共域名的数量有限我们可以选择的后缀。

具有公有域名后缀的主机可以发布并被外部网络上的主机（也可以被内部\私有网络中的主机）访问。

在下图中，我们可以看到一个带有私有域名后缀的域名示例 - o365info.lcoal

还有公共域名的其他示例，例如 - o365info.com

Active Directory 域名

每个 Active Directory 都必须有一个域名。

由安装第一台 DC 服务器的人员保护的 Active Directory 域名。 Active Directory 管理员可以决定选择什么类型的域作为 Active Directory 域名后缀。

如果管理员更喜欢为 Active Directory 使用私有域名，则常见域名后缀为 - local

域名后缀“local”未在公网发布。

在下图中，我们可以看到 Active Directory 管理员可用的选项示例。

Active Directory 管理员可以选择使用 Active Directory 的“内部命名空间”，例如 - o365info.lcoal 或“外部命名空间”，例如 - o365info.com。
“com”后缀是公共域名后缀。

Active Directory 域名和 Exchange 基础结构

Exchange 基础架构“集成”或“交织”到 Active Directory 基础架构中。

交换基础设施不能“存在于”Active Directory 之外，或者换句话说； Active Directory 充当 Exchange 基础架构的平台，而 Exchange 基础架构“绑定”到 Active Directory 林的边界。

每台 Exchange 服务器的默认 FQDN

每个 Exchange 服务器的默认 FQDN 由 Exchange 主机名 + 本地 Active Directory 域名构建。

如果我们对 Active Directory 域使用私有域名后缀，Exchange 将“继承”Active Directory 域名，结果是所有 Exchange 服务器的 FQDN 将具有 Active Directory 私有域名后缀。

从理论上讲，这种情况没有“危害”，但由于 Active Directory 基础结构与 Exchange 基础结构的性质不同，因此出现了问题。

当我们涉及 Active Directory 基础架构时，基本假设是我们永远不会想要/不需要将 Active Directory 基础架构暴露给公共网络或允许外部主机访问内部 Active Directory。

当涉及到Exchange基础设施时，“隐藏”内部主机或防止外部主机访问私有主机的概念是无法实现的。大多数时候，我们需要“公开”一些 Exchange Server（面向公众的 Exchange 服务器），以便外部主机（例如外部 Exchange 客户端）能够与 Exchange 服务器进行通信。

为了能够满足“发布Exchange资源”的要求，我们需要使用公共域名来发布所需的主机。

例如，外部 Exchange 客户端将使用 FQDN 来寻址面向公众的 Exchange CAS 服务器，例如 - mail.o365info.com

面向公众的 Exchange CAS 服务器的两个身份

如果 Exchange CAS 服务器是“面向公共的 Exchange 服务器”并且 Active Directory 基于私有域名，则结果是 -
Exchange CAS 服务器将具有两个不同的“身份”。

1. 内部——“Active Directory”身份
2. 公共身份

术语“身份”描述了 Exchange CAS 服务器将使用的 FQDN。

• 当 Exchange 客户端需要寻址 Exchange CAS 服务器时，Exchange 客户端将寻址 Exchange CAS 服务器私有或公共身份 (FQDN)。
• 当 Exchange 客户端需要使用特定 Exchange Web 服务时，Exchange 客户端将使用包含提供特定 Exchange Web 服务的 Exchange 服务器的私有或公共身份 (FQDN) 的 URL 地址。

交换 Web 服务和 URL 地址

Exchange 服务器，为其 Exchange 客户端提供各种 Web 服务。

Exchange CAS 服务器“公开”特定 Exchange Web 服务的方式是使用 URL 地址。换句话说 - Exchange 客户端使用 URL 地址访问 Exchange Web 服务。

在本节中，我想重点讨论我们用于 Exchange Web 服务的 URL 地址的一个非常具体的部分 - FQDN。

在上一节中，我们讨论了Active Directory基于私有域名的场景，我们还讨论了使用额外域名的必要性：公共域名，供需要通信的面向公众的Exchange服务器使用与外部 Exchange 客户端。

在此场景中，我们需要实现一个场景，我将其描述为“两个不同的身份”，将其分配给面向公众的 Exchange 服务器。外部身份和内部身份。

示例 1 - Outlook 客户端查找 Exchange CAS 服务器

当 Outlook 客户端尝试查找可用的 Exchange CAS 服务器时，将执行以下过程。

• 内部 Outlook 客户端（位于公司内部网络上的 Outlook 客户端）将使用其“私有 FQDN”对 Exchange CAS 服务器进行寻址。
• 外部 Outlook 客户端（位于公司内部网络上的 Outlook 客户端）将使用其“公共 FQDN”对 Exchange CAS 服务器进行寻址。

示例 2 - 发布有关 Exchange Web 服务的信息

当 Exchange CAS 服务器回复自动发现请求时，自动发现响应将包括有关 Exchange Web 服务的两种类型的信息：

• 内部自动发现客户端的信息，基于 URL 地址，其中包括提供特定 Exchange Web 服务的 Exchange 服务器的私有 FQDN。
• 外部自动发现客户端的信息，基于 URL 地址，其中包括提供特定 Exchange Web 服务的 Exchange 服务器的公共 FQDN。

Exchange Web 服务和 URL 地址结构

Exchange服务器，提供各种基于网络的服务。每个不同的 Exchange Web 服务都由专用 URL 地址“表示”。

尽管我们使用不同 Exchange Web 服务的专用 URL，但我们使用的 URL 地址基于所有 Exchange Web 服务 URL 地址中使用的基本结构。

“标准”Exchange Web 服务 URL 地址将包括四个部分：

1. 协议名称

URL地址的第一部分是协议名称。
使用HTTP或HTTPS协议实现的Exchange Web服务。
大多数时候，Exchange服务器与其客户端之间的通信将使用HTTPS 协议。

注意：此角色的例外情况是 Exchange 服务器使用 HTTP 协议（非加密通信）为自动发现客户端提供重定向。

2.FQDN 名称

FQDN 名称是“完整主机名”，包括主机名 + 域名。

如果 Exchange 服务器未暴露在公共网络中，则 Exchange CAS 服务器 FQDN 是根据“正确的服务器名称”（服务器 NetBIOS 名称）+ 内部 Active Directory 域名构建的。

如果 Exchange CAS 服务器配置为“面向公共的 Exchange 服务器”，则 Exchange CAS 服务器会通过使用公共 FQDN 来“暴露”自身，此外，大多数情况下可以并且将会有几个 FQDN 名称。

是否需要多个“公共 FQDN”取决于“面向公众的 Exchange 服务器”提供的服务。

3. 文件夹名称

对于 Exchange 提供的每项 Web 服务，都有一个“专用虚拟文件夹”。

例如，Exchange服务器的自动发现服务就是通过一个名为“自动发现”的专用文件夹来实现的。

当 Exchange 客户端需要获取特定服务时，Exchange 客户端需要知道并使用包含代表其所需特定服务的特定“文件夹名称”的 URL 地址。

注意：特定的 Web 文件夹可以为不同的 Exchange Web 服务提供服务。例如，EWS 文件夹用于提供 Exchange 可用服务、邮件提示等。

4. 文件名

URL 地址的最后部分可以包含文件名。例如，在自动发现服务的场景中，自动发现客户端使用的 URL 地址包含客户端从服务器请求的特定文件的名称。
自动发现客户端将请求名为 - autodiscover.xml

URL 地址中包含文件名的需要不是强制要求，文件名的需要取决于 Exchange 服务器提供的特定服务。

内部与外部自动发现 URL 地址示例

为了能够演示 Exchange CAS 服务器的“双重身份”概念，让我们回顾一下内部 Exchange 客户端使用的自动发现 URL 地址与外部 Exchange 客户端使用的自动发现 URL 地址。

场景章程：

组织使用私有域名作为 Active Directory 域名。
Active Directory 域名是 - o365info.local

组织公共域名是 - o365info.com

Exchange CAS 服务器名称是 - exo1

在某种情况下，Exchange CAS 服务器为内部 Exchange 客户端提供服务，也为公共或外部 Exchange 客户端提供帮助。

在下图中，我们可以看到自动发现 Web 服务 URL 地址的基本结构。

自动发现 URL 地址 |内部 Exchange 客户端

在我们的示例中，Exchange CAS 服务器将使用以下主机名自动在 Active Directory 的 SCP 上注册 - ex01.o365info.local

如果我们想要更准确，Exchange CAS 服务器使用以下 URL 在 Active Directory 的 SCP 中注册自动发现 URL 地址：
https://ex01.o365info.local /autodiscover/autodiscover.xml

当内部 Outlook 客户端启动自动发现过程时，Outlook 客户端将从本地 Active Directory 获取 Exchange 自动发现服务的 URL 地址，并从该 URL 地址“提取”Exchange CAS 服务器主机名 - ex01.o365info.local 并在内部 DNS 中查询该主机名。
DNS“答案”将包括 Exchange CAS 服务器的内部\私有 IP 地址。

自动发现 URL 地址 |外部 Exchange 客户端

在我们的示例中，当 Outlook 等外部邮件客户端需要为 [email protected] 创建新的 Outlook 邮件配置文件时，Outlook “假设”自动发现 URL 地址为请遵循：https://autodiscover.o365info.com/autodiscover/autodiscover.xml

为了能够连接面向公众的 Exchange 服务器，Outlook 将从公共自动发现地址中“提取”Exchange 服务器的 FQDN 名称。

在我们的场景中 - autodiscover.o365info.com

Outlook 客户端将寻址公共 DNS 服务器并发送查询以查找有关该主机的公共 IP 地址的信息。

交换双重身份 |使用相同或不同的 FQDN？

作为 Exchange 管理员，我们要做的最基本、最重要的决策之一是有关 Exchange 命名空间基础结构的决策。

我们的基本假设是，部分 Exchange 基础设施将配置为面向公众，因此，Exchange 将需要为内部 + 外部 Exchange 客户端提供服务。

换句话说，面向公众的 Exchange 服务器将有两个不同的接口。

选项 1 - 使用独立的命名空间

在这种情况下，每个面向公众的 Exchange 服务器将为每个“身份”使用不同的命名空间。

为了演示这个概念，我们使用以下场景：

• 内部 Active Directory 域名是 - o365info.local
• 组织公共域名是 - o365info.com

例如

• Exchange 服务器的“内部身份”将由主机名表示 - ex01.o365info.local
• Exchange 服务器的“外部身份”将由主机名表示 - mail.o365info.com 和 autodiscover.o365info.com

需要寻址 Exchange 服务器的内部 Exchange 客户端，寻找自动发现基础结构将使用主机名寻址 Exchange 服务器 - ex01.o365info.local

需要寻址 Exchange 服务器的外部 Exchange 客户端，寻找自动发现基础结构将使用主机名寻址 Exchange 服务器 - autodiscover.o365info.com

选项 2 - 使用统一的命名空间

在这种情况下，我们将为每个 Exchange 服务器“身份”使用相同的命名空间。

为了演示这个概念，我们使用以下场景：

• 内部 Active Directory 域名是 - o365info.local
• 组织公共域名是 - o365info.com

主要区别在于，在这种情况下，我们不会使用本地 Active Directory 域名作为 Exchange 主机名的一部分。

在我描述的统一命名空间的场景中，Exchange 服务器将通过使用公共域命名空间为内部 + 外部 Exchange 客户端“发布”。

• Exchange 服务器的“内部身份”将由主机名表示 - mail.o365info.com 和 autodiscover.o365info.com
• Exchange 服务器的“外部身份”将由主机名表示 - mail.o365info.com 和 autodiscover.o365info.com

需要寻址 Exchange 服务器的内部 Exchange 客户端，寻找自动发现基础结构将使用主机名来寻址 Exchange 服务器 - autodiscover.o365info.com

需要寻址 Exchange 服务器的外部 Exchange 客户端，寻找自动发现基础结构将使用主机名寻址 Exchange 服务器 - autodiscover.o365info.com

过去，“趋势”是强调“内部交换环境”与“外部交换环境”之间存在的差异。 ”

这种趋势的原因基于这样的假设：使用分离的命名空间更安全，因为“分离”可以保护内部 Exchange 基础结构免受外部主机的不需要的访问。

我的观点是，“逻辑分离”实际上并不能保护内部 Exchange 基础设施，因为实际上，保护和分离将由不同的解决方案实施。

使用分离命名空间的概念将使 Exchange 管理员的工作变得更加复杂并使用户感到困惑。