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

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

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

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

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

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

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 服務位置：

優先順序 = 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 記錄，如下所示：

 服務和通訊協定：_sips 。_tcp .mtls.example.com 優先順序：1 重量：10 通訊埠號碼：5062 目標：us-expe1.example.com 

企業對企業、Mobile and Remote Access及Webex流量位於相同 Expressway 配對上

企業對企業 (B2B) 及 Mobile and Remote Access (MRA) 通話使用連接埠 5061 進行SIP TLS， Webex流量TLS連接埠 5062 進行SIP驗證。

在身分驗證程序中檢查網域所有權。網域驗證是由Webex雲端實作的安全措施及身分檢查，用以證明您的身分。

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

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

   • 電子郵件網域

   • Expressway-E DNS 網域

   • 目錄 URI 網域

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

網域所有權檢查的重要性

Webex雲端會執行網域所有權檢查以強制實施安全性。如果不執行此檢查，則身分盜竊是一種可能的威脅。

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

一家DNS 網域設定為「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 網域。

接下來，她使用 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，她會透過建立 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 Device Connector 部署在內部網路中，它與雲端通訊的方式是透過出埠 HTTPS 連線 — 與連接到Web 伺服器的任何瀏覽器所使用的類型相同。

與Webex雲端的通訊使用TLS。Webex Device Connector 是TLS用戶端，而Webex Cloud 是TLS伺服器。因此， Webex Device Connector 會檢查伺服器憑證。

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

如果Webex Device Connector 必須驗證雲端提供的憑證，則它必須使用簽署該憑證的憑證授權單位的公鑰來解碼簽名。公開金鑰包含在憑證授權單位的憑證中。若要與雲端使用的憑證授權單位建立信任，這些受信任的憑證授權單位的憑證清單必須位於Webex Device Connector 信任儲存區中。

與裝置通訊時，此工具會使用您提供的受信任憑證。目前，執行此操作的方法是將它們放在[主資料夾]/.裝置工具/憑證。

遍訪配對中的 Expressway-E 也需要憑證授權單位憑證的清單。Expressway-E 使用SIP與TLS ，透過雙向驗證強制執行，與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 中配置，而且用在 Calendar Connector 中，作為 Expressway-C 介面上 Exchange 配置的一部分。

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

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

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