本部分添加了与 混合服务有关的关键配置项目的相关背景信息。

如果要成功部署Webex设备的混合呼叫，这些点至关重要。我们特别强调这些项目的原因如下：

• 我们希望详加解释，以便于您能够理解它们在混合部署中的角色并感到放心。

• 它们是确保云和内建环境之间安全部署的必要前提条件。

• 应将它们视为前期准备活动：相较于用户界面中的典型配置，它们设置起来的时间可能会稍久一些，因此请预留一段时间以将这些项目设置妥当。

• 在环境中设置好这些项目后，其他 混合服务配置便会顺利进行。

Expressway-C和Expressway-E对 部署允许使用防火墙遍历技术往返互联网的呼叫。此部署可以安全地控制您的内部呼叫并与Webex相连。

由于防火墙穿越体系结构，Expressway-C 和 Expressway-E 不要求在隔离区 (DMZ) 防火墙上开放任何入站端口。但在互联网防火墙上必须开放入站的 TCP SIP 信令端口和 UDP 媒体端口才能让传入呼叫通过。您必须预留时间以在企业防火墙上打开相应端口。

下图显示的是防火墙穿越架构：

例如，对于使用 SIP 协议的企业对企业 (B2B) 入站呼叫，TCP 端口 5060 和 5061（5061 用于 SIP TLS）以及用于多种服务（如语音、视频、内容共享、双视频等）的 UDP 媒体端口必须在外部防火墙上打开。要开放哪些媒体端口取决于并发呼叫的数量与服务数量。

您可以将 Expressway 上的 SIP 侦听端口配置为 1024 至 65534 之间的任意值。同时，必须在公共 DNS SRV 记录中传播此值与协议类型，且必须在互联网防火墙上打开该值。

虽然标准设置是 SIP TCP 使用 5060，SIP TLS 使用 5061，但并不会阻止使用其他端口，如以下示例所示。

示例

在此例中，我们假定端口 5062 用于入站 SIP TLS 呼叫。

包含两个 Expressway 服务器的集群的 DNS SRV 记录类似于：

_sips。_tcp。example.com SRV服务位置：

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sips。_tcp。example.com SRV服务位置：

priority = 10

weight = 10

port = 5062

svr hostname = us-expe2.example.com

上述记录表示，使用传输类型 TLS 和侦听端口号 5062，以相同的负载分配（优先级与权重）将呼叫定向至 us-expe1.example.com 和 us-expe2.example.com。

网络（指互联网）外部设备向企业域用户 (user1@example.com) 发起 SIP 呼叫时，必须查询 DNS 以了解要使用哪一种传输类型、端口号、如何均衡流量负载以及向哪些 SIP 服务器发送呼叫。

如果DNS条目包括 _sips。_tcp，则条目指定SIP TLS。

TLS 是客户端/服务器协议，在最通用的实现中使用证书进行验证。在企业对企业呼叫情境中，TLS 客户端为主叫设备，TLS 服务器为被叫设备。客户端通过 TLS 检查服务器证书，如果证书检查失败，将断开呼叫连接。客户端无需证书。

下图显示的是 TLS 握手：

但是，TLS 规范声明服务器也可以通过在 TLS 握手协议期间向客户端发送“证书请求”消息来检查客户端证书。此消息在服务器与服务器连接上很有帮助，例如在Expressway-E和Webex云之间建立的呼叫。此概念称为具有相互身份验证的TLS，在与Webex集成时是必需的。

主叫方和被叫方都会检查对方的证书，如下图所示：

云与 Expressway 相互检查身份。例如，如果证书中的云身份（CN 或 SAN）与 Expressway 上已配置的身份不匹配，则连接断开。

如果开启相互验证，Expressway-E 会一直请求客户端证书。结果，移动和远程访问 (MRA) 无法正常工作，因为在大多数情况下，证书不会部署到 Jabber 客户端。在企业对企业情境中，如果主叫实体无法提供证书，呼叫则将断开连接。

我们建议您将非 5061 的值用于具有相互验证的 TLS，如端口 5062。Webex混合服务使用用于B2B的SIP TLS记录相同。如果使用端口 5061，其他一些无法提供 TLS 客户端证书的服务将无法运行。

如果现有记录已用于企业对企业通信，我们建议在Control Hub中指定企业域的子域作为SIP目标，并指定公共DNS SRV记录，如下所示：

 服务和协议：_sips。_tcp。mtls.example.com优先级：1个重量：10端口号：5062目标：us-expe1.example.com 

在同一高速公路对上的企业对企业、移动和远程访问以及Webex流量

企业对企业(B2B)和移动和远程访问(MRA)呼叫使用SIP TLS端口5061，Webex流量使用SIP TLS端口5062。

域所有权检查是身份验证的一部分。域验证是Webex云实施的安全措施和身份验证，以证明您就是您自称的人。

身份检查分两个阶段执行：

1. 域所有权检查。此步骤涉及三种类型的域，且属于一次性验证检查：

   • 电子邮件域

   • Expressway-E DNS 域

   • 目录 URI 域

2. Expressway-E DNS 名称所有权检查。此步骤通过具有相互验证的 TLS 的实施得以执行，包括在云与 Expressway 上使用公共证书。不同于域身份检查，此步骤在向/从云发起/接收的任何呼叫期间执行。

域名所有权检查的重要性

Webex云执行域所有权检查以执行安全性。如果未执行此检查，则将面临身份盗窃这一潜在威胁。

以下案例详述了未执行域所有权检查可能导致的后果。

将DNS域设置为“hacker.com”的公司购买Webex混合服务。另外一家域设置为“example.com”的公司也在使用混合服务。Example.com 公司的其中一位总经理名叫 Jane Roe，其目录 URI 为 jane.roe@example.com。

Hacker.com 公司的管理员将她的其中一个目录 URI 设置为 jane.roe@example.com，同时将电子邮件地址设置为 jane.roe@hacker.com。她可以这样设置的原因是，在此例中云并不检查 SIP URI 域。

接下来，她通过jane.roe@hacker.com登录Webex应用程序。她拥有该域，验证电子邮件已被阅读并得到答复，因此得以成功登录。最后，她通过从Webex应用程序中拨打john.doe@example.com来给同事John Doe打电话。John 正坐在办公室里，他在视频设备上看到了一通来自 jane.roe@example.com 的呼叫；那是与该电子邮件帐户关联的目录 URI。

他不禁想道：“她目前人在国外，或许需要某些重要的资料。” 他接听了电话，假冒的 Jane Roe 索要一些重要文档。她解释说她的设备坏了，又因为她在旅行途中，因此让他将文档发送至她的私人电子邮件地址：jane.roe@hacker.com。就这样，公司在 Jane Roe 回到办公室后才意识到重要信息已外泄。

Example.com公司有许多方法可以防止来自互联网的欺诈性呼叫，但Webex云的职责之一是确保从Webex呼叫的任何人的身份是正确的，而不是伪造的。

要检查身份，Webex要求公司证明其拥有混合呼叫中使用的域。如果没有，混合服务将无法使用。

为确保此所有权，要求进行以下两个域验证步骤：

1. 证明公司拥有电子邮件域、Expressway-E 域和目录 URI 域。

   • 以上所有域都必须可路由且可被公共 DNS 服务器识别。

   • 为证明所有权，DNS 管理员必须输入 DNS 文本记录 (TXT)。TXT 记录是 DNS 中的一种资源类型，使您能够将某些随意的无格式文本与主机或其他名称关联起来。

   • DNS 管理员必须将该 TXT 记录输入必须证明所有权的区域中。在此步骤之后，Webex云执行该域的TXT记录查询。

   • 如果TXT查询成功，并且结果与Webex云生成的令牌相符，则域将验证。

   • 例如，如果管理员希望Webex Hybrid Services在其域上工作，则必须证明她拥有域名“example.com”。

   • 通过 https://admin.webex.com，她通过创建与Webex云生成的令牌匹配的TXT记录开始验证过程：

     

   • 然后，DNS管理员为此域创建一个TXT记录，其值设置为 123456789abcdef123456789abcdef123456789abcdef，如下示例所示：

     

   • 此时，云可以验证域 example.com 的 TXT 记录是否与令牌相匹配。

   • 云执行 TXT DNS 查找：

     

   • 鉴于该 TXT 值与令牌值相匹配，此种匹配证明管理员向公共 DNS 添加了其域的 TXT 记录，从而证明了她拥有该域。

2. Expressway-E DNS 名称所有权检查。

   • 云必须核实 Expressway-E 拥有受云所信任的某个认证中心确认的身份。Expressway-E 管理员必须向上述某个认证中心请求 Expressway-E 的公共证书。为颁发证书，认证中心基于域验证检查（针对域验证证书）或组织验证检查（针对组织验证证书）执行身份验证过程。

   • 向/从云发起/接收的呼叫取决于已颁发给 Expressway-E 的证书。如果该证书无效，则呼叫断开。

Webex设备连接器必须与Webex通信，才能使用Hybrid呼叫。

Webex Device Connector部署在内部网络中，它与云通信的方式是通过出站的HTTPS连接，与连接到Web服务器的任何浏览器都使用相同的类型。

与Webex云的通信使用TLS。Webex设备连接器是TLS客户端，Webex云是TLS服务器。因此，Webex Device Connector会检查服务器证书。

认证中心使用其私有密钥签署服务器证书。拥有公共密钥的任何人都能对该签名进行解码，并可证明是同一认证中心签发的该证书。

如果Webex Device Connector需要验证云提供的证书，则必须使用签署该证书的证书颁发机构的公钥来解码签名。认证中心的证书中包含公共密钥。要与云使用的证书颁发机构建立信任，这些受信任证书颁发机构的证书列表必须在Webex Device Connector信任存储中。

在与设备通信时，该工具使用您提供的可信证书。目前的方法是将其置于[home folder]/。devicestool/certs中。

穿越对中的 Expressway-E 同样需要认证中心的证书列表。Expressway-E使用TLS的SIP与Webex云进行通信，并通过相互身份验证执行。Expressway-E信任来自和传入云的呼叫，只有当云在TLS连接设置过程中呈现的证书的CN或SAN与Expressway上配置的DNS区域的主题名称相匹配(“callservice.webex.com”)。认证中心仅在完成身份检查后才会发布证书。必须证明callservice.webex.com域的所有权才能获得签名的证书。由于我们(Cisco)拥有该域，DNS名称“callservice.webex.com”直接证明远程对等是真正的Webex。

calendar Connector 通过Webex帐户将日历连接器与 Microsoft Exchange 2013、2016、2019 或 Office 365 集成。Exchange 中的应用程序模拟管理角色让应用程序能够模拟组织中的用户，代表该用户执行任务。应用程序模拟角色必须在 Exchange 中配置，并且用作 Expressway-C 界面上 Exchange 配置的一部分。

Exchange模拟帐户是Microsoft为此任务推荐的方法。Expressway-C 管理员无需知道密码，因为可由 Exchange 管理员在 Expressway-C 界面中输入该值。即便 Expressway-C 管理员拥有对 Expressway-C 框的根访问权，密码也不会明确显示。与 Expressway-C 上的其他密码一样，该密码也将采用相同的凭证加密机制进行加密存储。

为了提高安全性，请按照《Cisco Webex 混合日历服务部署指南》中的步骤启用 TLS，以确保 EWS 有线连接的安全。

为了提高安全性，请按 部署 Expressway Calendar Connector for Microsoft Exchange 中的步骤启用 TLS，以确保 EWS 有线连接的安全。