本區段額外提供了與 Hybrid Services 相關的重要設定項目的內容。

如果想要成功部署 Webex 裝置的混合通話功能，以下幾點至關重要。出於下列原因，我們著重強調這些要點：

• 我們想要解釋這五個要點，以便您瞭解它們在混合部署中的角色，打消疑慮。

• 它們是必要條件，確保在雲端與內部部署環境之間安全部署。

• 它們應該視為前置零日活動：較之一般設定，它們在使用者介面中的完成時間稍微長一些，因此要留出一些時間讓這些項目排序。

• 在環境中解決這些項目後，餘下的 Hybrid Services 設定將會順利進行。

Expressway-C 與 Expressway-E 對部署 允許使用 防火牆穿越技術進行與 Internet 之間的通話。此部署方案可安全地將您的本機呼叫控制系統與 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 服務位置：

優先順序 = 10

權數 = 10

埠 = 5062

SVR 主機名稱 = us-expe1.example.com

_sips._tcp.example.com SRV 服務位置：

優先順序 = 10

權數 = 10

埠 = 5062

SVR 主機名稱 = us-expe2.example.com

這些記錄表示通話會以相等負載共用（優先順序和權數）導向至 us-expe1.example.com 和 us-expe2.example.com，其中使用 TLS 作為傳輸類型，且使用 5062 作為接聽埠號。

如果裝置位於網路外部（在網際網路上）並且對公司網域使用者 (user1@example.com) 進行 SIP 呼叫，則必須查詢 DNS 以瞭解要使用的傳輸類型、埠號、流量負載共用的方式以及呼叫傳送至的 SIP 伺服器。

如果 DNS 項目包含 _sips._tcp，則該項目指定 SIP TLS。

TLS 是用戶端/伺服器通訊協定，在最常見的實作中，使用憑證進行驗證。在企業對企業通話情境中，TLS 用戶端是呼叫裝置，而 TLS 伺服器是被呼叫裝置。藉由 TLS，用戶端會檢查伺服器的憑證，如果憑證檢查失敗，則會中斷通話連線。用戶端不需要憑證。

下圖顯示了 TLS 交握：

然而，TLS 規格說明伺服器也可以在 TLS 交握通訊協定期間，透過將「憑證要求」訊息傳送至用戶端來檢查用戶端憑證。此訊息對伺服器到伺服器的連線很有幫助，例如在 Expressway-E 和 Webex 雲端之間建立的通話。這種概念稱為具有相互認證的 TLS，在與 Webex 整合時是必需的。

呼叫方及被呼叫方都會檢查另一方的憑證，如下圖所示：

雲端會檢查 Expressway 身分，而 Expressway 會檢查雲端身分。比方說，如果憑證中的雲端身分（CN 或 SAN）與 Expressway 上的設定不相符，則連線會中斷。

如果開啟雙向驗證，則 Expressway-E 總是會請求用戶端憑證。因此，Mobile and Remote Access (MRA) 將無法運作，因為在大多數情況下，憑證不會部署在 Jabber 用戶端上。在企業對企業情境中，如果呼叫實體無法提供憑證，則會中斷呼叫連線。

我們建議您將 5061 以外的值用於雙向驗證的 TLS，例如埠 5062。Webex Hybrid Services 使用與 B2B 相同的 SIP TLS 記錄。如果是埠 5061，則其他無法提供 TLS 用戶端憑證的服務就無法運作。

如果現有記錄已用於企業對企業通信，我們建議在 Control Hub 中將企業網域的子網域指定為 SIP 目標，並相應地建立一個公共 DNS SRV 記錄，如下所示：

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

同一條高速公路上的企業對企業、行動和遠端存取以及 Webex 流量

企業對企業 (B2B) 和移動及遠端存取 (MRA) 呼叫使用連接埠 5061 進行 SIP TLS 通信，Webex 流量使用連接埠 5062 進行 SIP TLS 通訊並進行相互認證。

在身分驗證程序中檢查網域所有權。網域驗證是 Webex 雲端平台實施的安全措施和身份驗證，用於證明您是您所聲稱的那個人。

分兩個階段執行身分檢查：

1. 網域所有權檢查。此步驟涉及三種網域，而且是一次性驗證檢查：

   • 電子郵件網域

   • Expressway-E DNS 網域

   • 目錄 URI 網域

2. Expressway-E DNS 名稱所有權檢查。透過實作雙向驗證的 TLS來執行此步驟，並且此步驟涉及在雲端及 Expressway 上使用公用憑證。和網域身分檢查不同，此步驟是在呼叫雲端以及接聽來自雲端的呼叫期間執行。

域名所有權檢查的重要性

Webex 雲端平台會執行網域名稱所有權檢查以確保安全性。如果不執行此檢查，則身分盜竊是一種可能的威脅。

下列故事詳細說明了不執行網域所有權檢查時可能發生的情況。

一家網域為「hacker.com」的公司收購了Webex 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 網域。

接下來，她登入了 Webex 應用程式。 jane.roe@hacker.com. 因為她擁有網域，所以驗證電子郵件可以被閱讀及回覆，然後她可以登入。最後，她撥打了同事約翰·多伊的電話。 john.doe@example.com 來自她的 Webex 應用程式。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開始驗證過程，創建一個 TXT 記錄來匹配 Webex 雲端產生的令牌：

     

   • 然後，DNS 管理員為該網域建立一個 TXT 記錄，其值設定為 123456789abcdef123456789abcdef123456789abcdef123456789abcdef，如下例所示：

     

   • 此時，雲端可以驗證網域 example.com 的 TXT 記錄是否與權杖相符。

   • 雲端會執行 TXT DNS 查找：

     

   • 因為 TXT 值與權杖值相符，所以此相符證明了管理員已將她自己的網域 TXT 記錄新增至公用 DNS，而且她擁有該網域。

2. Expressway-E DNS 名稱所有權檢查。

   • 雲端必須檢查 Expressway-E 具有雲端信任的其中一個憑證授權單位所確認的身分。Expressway-E 管理員必須向其中一個憑證授權單位申請其 Expressway-E 的公用憑證。為了頒發憑證，憑證授權單位會根據網域驗證檢查（針對網域驗證的憑證）或組織驗證檢查（針對組織驗證的憑證）執行身分驗證程序。

   • 呼叫雲端及從雲端呼叫相依於已頒發給 Expressway-E 的憑證。如果憑證無效，則通話會中斷。

Webex 裝置連接器必須與 Webex 通信，混合通話功能才能正常運作。

Webex 裝置連接器部署在內部網路中，它與雲端通訊的方式是透過出站 HTTPS 連線——與任何連接到 Web 伺服器的瀏覽器所使用的連線類型相同。

與 Webex 雲端的通訊使用 TLS 協定。Webex Device Connector 是 TLS 用戶端，Webex 雲端是 TLS 伺服器。因此，Webex 裝置連接器會檢查伺服器憑證。

憑證授權單位會使用其自己的私密金鑰來簽署伺服器憑證。具有公開金鑰的任何人都可以解碼該簽章，並證明該憑證是由相同的憑證授權單位簽署。

如果 Webex Device Connector 需要驗證雲端提供的證書，則必須使用簽署該證書的證書頒發機構的公鑰來解碼簽署。公開金鑰包含在憑證授權單位的憑證中。若要與雲端使用的憑證授權單位建立信任，這些受信任憑證授權單位的憑證清單必須位於 Webex 裝置連接器信任儲存中。

在與裝置通訊時，該工具使用您提供的受信任憑證。目前實現這一目標的方法是將它們放在 [home folder]/.devicestool/certs中。

遍訪配對中的 Expressway-E 也需要憑證授權單位憑證的清單。Expressway-E 使用 SIP 和 TLS 與 Webex 雲端通信，並透過相互認證來強制執行。Expressway-E 僅信任來自雲端和發送到雲端的呼叫，前提是雲端在 TLS 連線建立期間提供的憑證的 CN 或 SAN 與 Expressway 上為 DNS 區域配置的主題名稱（「callservice.webex.com」）相符。只有在進行身分檢查之後，憑證授權單位才會發行憑證。要取得簽章證書，必須證明 callservice.webex.com 網域的所有權。因為我們（思科）擁有該域名，DNS 名稱「callservice.webex.com」直接證明遠端對等方確實是 Webex。

Calendar Connector 透過模仿帳戶將 Webex 與 Microsoft Exchange 2013、2016、2019 或 Office 365 整合。Exchange 中的應用程式模仿管理角色可讓應用程式模仿組織中的使用者，以代表使用者執行任務。應用程式模仿角色必須在 Exchange 中配置，而且用在 Calendar Connector 中，作為 Expressway-C 介面上 Exchange 配置的一部分。

Microsoft 建議使用 Exchange 模擬帳戶來完成此任務。Expressway-C 管理員不需要知道密碼，因為 Exchange 管理員可以在 Expressway-C 介面中輸入此值。密碼不會以明文顯示，即使 Expressway-C 管理員具有 Expressway-C 產品的 root 存取權亦如此。該密碼使用與 Expressway-C 上其他密碼相同的認證加密機制來加密儲存。

為獲得額外的安全性，請遵循 Cisco Webex 混合行事曆服務的部署指南中的步驟，以啟用 TLS 以便保護 EWS 的有線連線。

若要獲得額外的安全性， 請遵循部署 Microsoft Exchange Expressway Calendar Connector 中的步驟以啟用 TLS，以確保 EWS 的有線連接安全。