部署 Cisco Spark Hybrid Services 前的五项重要准备工作

Document created by Cisco Localization Team on Feb 4, 2017
Version 1Show Document
  • View in full screen mode
 

以下五点对 Cisco Spark Hybrid Services 部署具有重要性之原因

 

本文档补充了关于与 Cisco Spark Hybrid Services 有关的五个关键配置项目的上下文。

  

如果您希望成功部署由 Expressway 托管的 Cisco Spark Hybrid Services(Call Service Aware/Connect 和 Calendar Service),那么这五点至关重要。 我们特别强调这五点的原因如下:

  
  •  

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

      

  •  

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

      

  •  

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

      

  •  

    在环境中设置好这些项目后,其他 Cisco Spark Hybrid Services 配置便会顺利进行。

      

  

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

 

Expressway-C 和 Expressway-E 对部署允许使用防火墙穿越技术向/从互联网发起/接收呼叫。 此部署通过 Cisco Collaboration Cloud 安全连接内建呼叫控制与 Cisco Spark。

防火墙穿越架构使得 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.comus-expe2.example.com

 

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

 

如果 DNS 条目包含 _sips._tcp,则该条目指定 SIP TLS。

 

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

下图显示的是 TLS 握手:


 

但是,TLS 规范声明服务器也可以通过在 TLS 握手协议期间向客户端发送“证书请求”消息来检查客户端证书。 在服务器对服务器的连接中(例如,在 Expressway-E 和 Cisco Collaboration Cloud 间建立起的呼叫),此消息也很有用。 此概念称为具有相互验证的 TLS,在与 Cisco Spark 进行集成时为必要条件。

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


 

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

 

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

 

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

     

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

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

云为何会检查域所有权

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

 

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

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

     

    • 电子邮件域

       

    • Expressway-E DNS 域

       

    • 目录 URI 域

       

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

     

       

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

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

 

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

 

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

 

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

 

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

 

为检查身份,Cisco Spark 要求公司证明其拥有在 Spark 混合呼叫中使用的域。 如果公司无法提供证明,Cisco Spark Hybrid Services 将不会运行。

 

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

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

      

    •  

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

        

    •  

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

        

    •  

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

        

    •  

      如果 TXT 查询成功且结果与 Cisco Collaboration Cloud 生成的令牌相匹配,则该域通过验证。

        

    •  

      例如,如果上述管理员希望 Cisco Spark 与 Cisco Spark Hybrid Services 在其域上能够运行,则必须证明其拥有域“example.com”。

        

    •  
      通过管理门户,她创建了 TXT 记录以与 Cisco Collaboration Cloud 生成的令牌进行匹配,进而开始验证过程。


        
    •  
      然后,DNS 管理员为此域创建了 TXT 记录,并将值设置为 123456789abcdef123456789abcdef123456789abcdef123456789abcdef,如下例所示:


        
    •  

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

        

    •  
      云执行 TXT DNS 查找:


        
    •  

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

        

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

      

    •  

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

        

    •  

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

        

    

支持的认证中心

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

 

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

 

使用 TLS 注册到 Cisco Collaboration Cloud 以及与之通信。 Expressway-C 是 TLS 客户端,Cisco Collaboration Cloud 是 TLS 服务器。 因此,由 Expressway-C 检查服务器证书。

 

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

 

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

 

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

 

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

 

如果您允许自动安装认证中心的证书,您将重定向至 Cisco Cloud Collaboration Management(管理门户)。 Expressway-C 可自行完成重定向,无需任何用户干预。 Cisco Spark 的管理员必须通过 HTTPS 连接进行验证。 然后,云会将 CA 证书推送至 Expressway-C。

 

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

 

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

 
此过程十分安全,原因如下:
  •  

    访问 Expressway-C 和 Cisco Cloud Collaboration Management (admin.ciscospark.com) 时要求管理员权限。 上述连接使用 HTTPS 且经过加密处理。

      

  •  

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

      

   

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

  • 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 Collaboration Cloud 进行通信。 仅当在 TLS 连接设置期间云提交的证书 CN 或 SAN 与 Expressway 上针对 DNS 区域配置的使用者名称(“callservice.ciscospark.com”)相匹配时,Expressway-E 才会信任与云之间来往的呼叫。 认证中心仅在完成身份检查后才会发布证书。 必须在证明 callservice.ciscospark.com 域的所有权后才能签署证书。 因为我们 (Cisco) 拥有该域,所以 DNS 名称“callservice.ciscospark.com”是远程同伴即真正 Cisco Collaboration Cloud 的直接证明。

 

交换模拟帐户

 

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

Exchange 模拟帐户是 Microsoft 建议用于此任务的方法。 使用模拟帐户通过 Exchange Web Services (ESW) 进行访问十分安全,原因如下:

  • 该访问对用户不可用,并且通过 TLS 以有线连接方式对 EWS 连接进行保护。

     

  • 该帐户只能通过 EWS 进行使用;可访问具有模拟权限的帐户的用户将需要编写一个 EWS 应用程序以访问用户邮箱,而不能通过邮箱客户端直接访问邮箱。

     

  • 模拟帐户密码在 Expressway-C 上进行加密存储。

     

  

因此,Expressway-C 管理员无需知道密码,因为可由 Exchange 管理员在 Expressway-C 界面中输入该值。 即便 Expressway-C 管理员拥有对 Expressway-C 服务器的根访问权,也不会明确地显示密码。

 

这种安全性确保只有 Expressway-C 应用程序能够使用该密码。

 

多重 Expressway 部署

Expressway-C 连接器主机最多可以聚集六台服务器。 在多个 Unified CM 集群分布于不同区域的情境中,您可以部署仅具备本地冗余的多个 Expressway-C 集群,每个 Unified CM 集群对应一个 Expressway-C 集群。 如果 Expressway-C 的一个节点出现故障,集群中的另一节点将连接至 Cisco Collaboration Cloud 和 Unified CM。 当前无法实现地理冗余。

用于 SIP 信号与媒体的 Expressway-C 和 Expressway-E

   

您可以将多个 Expressway-C 和 Expressway-E 集群分布在多个区域中。 Unified CM 基于分区与呼叫搜索空间配置,使用最近的 Expressway 集群处理从 Unified CM 到 Cisco Collaboration Cloud 的出站呼叫。

  

对于入站呼叫,您必须了解如何将流量分配到 Internet Edge 的不同 Expressway-E 集群中。

  
  •  

    如果 Internet Edge 部署在同一数据中心或同一区域内,可能会在 DNS SRV 级别进行负载均衡。 例如,如果企业网络包括用于 Spark 混合呼叫的三个 Internet Edge,每一个 Internet Edge 均由包含两个 Expressway-E 和 Expressway-C 节点的一个集群组成,那么 _sips._tcp.example.com 将包含所有六条 Expressway-E 记录(3 个 Expressway-E 乘以 2),且它们优先级相同,权重相等。 此设置将来自 Cisco Collaboration Cloud 的呼叫平均地分配到各个 Expressway-E 和 Expressway-C 集群中。

      

  •  

    如果 Internet Edge 部署到不同的域中,那么最佳解决方案是使用 Geo DNS 服务。

      

    许多 DNS 供应商都提供 Geo DNS 服务,此类服务基于 Geo DNS 的以下能力:查看源 IP 地址,了解该 IP 地址属于哪个国家或地区,以及将请求转发至距该地区实际距离最近的边缘。 请注意:向 Expressway-E 传送的混合呼叫来自 Cisco Collaboration Cloud,而非直接来自于 Spark 客户端。 因此,源 IP 地址是 Cisco Collaboration Cloud 正在使用的众多 IP 地址之一。

      

    基于此分类以及 Geo DNS 上的配置,呼叫发往距主叫 IP 地址所属区域实际距离最近的 Expressway-E。

      

  
例如,AWS Geo DNS 服务以如下方式进行配置:


  

SRV 记录一经创建,便应用了“地点”标签并指定了国家/地区。 来自云且 IP 地址属于同一地点(此例中为意大利)的呼叫发往 emea-expe1.example.com。 许多 SRV 记录均可基于区域数量进行创建。

  

Geo DNS 的配置取决于 DNS 供应商,此配置示例仅供参考。

  
如果两个不同的 Expressway-C 和 Expressway-E 集群部署在美国和欧洲、中东及非洲地区 (EMEA),DNS SRV 记录 _sips._tcp.example.com 将配置为属于两个不同的区域。 使用 AWS 要求 _sips._tcp.example.com 有两条 DNS SRV 记录,如下例所示:


  

这样,离开美国 Cisco Collaboration Cloud 的呼叫进入了美国 Expressway-E,且仅在该美国 Expressway-E 集群不可用的情况下,才使用 EMEA Expressway-E 集群。 如果呼叫离开 EMEA Cisco Collaboration Cloud,它将进入位于 EMEA 的 Expressway-E 集群,且仅在 EMEA 集群不可用的情况下才使用美国集群。

  
 

Attachments

    Outcomes