关于混合服务部署的重要事项

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

如果您希望成功部署 Expressway 托管的 ( Cisco Webex 混合服务如混合日历服务), 那么这些要点至关重要 混合呼叫服务 。 我们特别强调这些项目的原因如下：

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

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

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

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

互联网防火墙上的 TCP 端口 5062

Expressway-C 和 Expressway-E 对部署允许使用防火墙穿越技术向/从互联网发起/接收呼叫。 此部署将安全连接本地部署呼叫控制与 Cisco 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 service location:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV service location:

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 和 Cisco Webex 云间建立起的呼叫），此消息也很有用。 此概念称为具有相互验证的 TLS，在与 Cisco Webex 进行集成时为必要条件。

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

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

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

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

同一 Expressway 对上的企业对企业、移动与远程访问和 Cisco Webex 流量

企业对企业和移动与远程访问呼叫将端口 5061 用于 SIP TLS，Cisco Webex 流量将端口 5062 用于具有相互验证的 SIP TLS。

云为何会检查域所有权

域所有权检查是身份验证的一部分。 域验证是 Cisco Webex 云为证明您与所您所声称的身份相符而实施的安全措施与身份检查。

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

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

    • 电子邮件域

    • Expressway-E DNS 域

    • 目录 URI 域

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

案例演示：域所有权检查的重要性

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

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

一家 DNS 域设置为“hacker.com”的公司购买了 Cisco 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 登录 Cisco Webex Teams。 她拥有该域，验证电子邮件已被阅读并得到答复，因此得以成功登录。 最后，她通过从 Cisco Webex Teams 应用程序拨打 john.doe@example.com，向同事 John Doe 发起了呼叫。John 正坐在办公室里，他在视频设备上看到了一通来自 jane.roe@example.com 的呼叫；那是与该电子邮件帐户关联的目录 URI。

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

Example.com 公司拥有多种可防范互联网诈骗呼叫的途径，但 Cisco Webex 云的责任之一是确保从 Cisco Webex 进行呼叫的任何人的身份是正确的，而不是伪造的。

为检查身份，Cisco Webex 要求公司证明其拥有在混合呼叫中使用的域。 否则， 无法正常工作。

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

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

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

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

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

    • 如果 TXT 查询成功且结果与 Cisco Webex 云生成的令牌相匹配，则该域通过验证。

    • 例如，如果上述管理员希望 Cisco Webex 混合服务在其域上能够运行，则必须证明其拥有域“example.com”。

    • 通过 https://admin.webex.com，她创建了 TXT 记录以与 Cisco Webex 云生成的令牌进行匹配，进而开始验证过程：
    • 然后，DNS 管理员为此域创建了 TXT 记录，并将值设置为 123456789abcdef123456789abcdef123456789abcdef123456789abcdef，如下例所示：

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

    • 云执行 TXT DNS 查找：

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

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

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

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

支持的认证中心

必须向 Cisco Webex 注册 Expressway-C 连接器主机，混合服务才能运行。

Expressway-C 部署在内部网络中，通过出站 HTTPS 连接（与连接至 Web 服务器的任何浏览器所使用的类型相同）注册到云。

使用 TLS 注册到 Cisco Webex 云并与之通信。 Expressway-C 是 TLS 客户端，Cisco Webex 云是 TLS 服务器。 因此，由 Expressway-C 检查服务器证书。

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

如果 Expressway-C 必须验证云提供的证书，那么必须使用签发该证书的认证中心的公共密钥对签名进行解码。 认证中心的证书中包含公共密钥。 为与云所使用的认证中心建立信任，这些受信任的认证中心的证书列表必须包含在 Expressway 的信任库中。 这样，Expressway 才能确认呼叫确实来自 Cisco Webex Cloud。

通过手动上传，您可以将所有相关的认证中心证书上传至 Expressway-C 的信任库。

通过自动上传，云可以自行将上述证书上传至 Expressway-C 的信任库中。 我们建议您使用自动上传。 证书列表可能会发生变化，而自动上传保证您始终获取最新列表。

如果您允许自动安装认证中心的证书，您将被重定向至 https://admin.webex.com（管理门户）。 Expressway-C 可自行完成重定向，无需任何用户干预。 作为 Cisco Webex 管理员，您必须通过 HTTPS 连接进行验证。 然后，云会将 CA 证书推送至 Expressway-C。

在证书上传至 Expressway-C 信任库之后，才能建立 HTTPS 连接。

为避免此问题，Expressway-C 已预先安装了受 Cisco Webex 信任的 CA 证书。 上述证书仅用于设置及验证初始 HTTPS 连接，不会出现在 Expressway-C 信任列表中。 通过此初始 HTTPS 连接从云中抽取了受信任的认证中心的证书后，这些证书将在平台范围内可用；而后，它们将出现在 Expressway-C 信任列表中。

此过程十分安全，原因如下：

  • 访问 Expressway-C 和 https://admin.webex.com 时要求管理员权限。 上述连接使用 HTTPS 且经过加密处理。

  • 通过相同的加密连接将证书从云推送至 Expressway。

此列表显示 Cisco Webex 云当前使用的认证中心的证书。 此列表将来可能会发生变化：

  • C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

  • C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

  • C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

  • C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

  • C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

  • C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

  • C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

穿越对中的 Expressway-E 同样需要认证中心的证书列表。 Expressway-E 使用实施双向验证的 SIP TLS 与 Cisco Webex 云进行通信。 仅当在 TLS 连接设置期间云提交的证书 CN 或 SAN 与 Expressway 上针对 DNS 区域配置的使用者名称（“callservice.webex.com”）相匹配时，Expressway-E 才会信任与云之间来往的呼叫。 认证中心仅在完成身份检查后才会发布证书。 必须在证明 callservice.webex.com 域的所有权后才能签署证书。 因为我们 (Cisco) 拥有该域，所以 DNS 名称“callservice.webex.com”直接证明了远程同伴确系 Cisco Webex。

交换模拟帐户

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

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

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