このセクションでは、ハイブリッド データ セキュリティのプロキシ サポート機能について説明します。 Cisco Webex ハイブリッド データ セキュリティの展開ガイドを補足するために用意されており、https://www.cisco.com/go/hybrid-data-security で入手可能です。 新しい展開では、HDS 設定 ISO をノードでアップロードし、マウントした後で、Cisco Webex クラウドに登録する前に、各ノードでプロキシのセットアップを設定します。

ハイブリッド データ セキュリティは、明示的な透過的な検査および非検査プロキシをサポートします。 これらのプロキシを展開に関連付けることができます。これにより、エンタープライズからクラウドに送信されるトラフィックをセキュリティ保護し、監視することができます。 証明書の管理のノードでプラットフォーム管理インターフェイスを使用して、ノードでプロキシを設定した後で、全体的な接続ステータスを確認することができます。

ハイブリッド データ セキュリティ ノードは、以下のプロキシ オプションをサポートしています。

  • プロキシなし—プロキシを統合するために、HDS ノード セットアップの信頼ストアとプロキシ設定を使用しない場合は、デフォルトになります。 証明書の更新は必要ありません。

  • 透過型の検査なしのプロキシ—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていないため、検査なしのプロキシで動作するように変更を加える必要はありません。 証明書の更新は必要ありません。

  • 透過トンネリングまたは検査プロキシ—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていません。 ノードでは、HTTP または HTTPS の設定変更は必要ありません。 ただし、ノードはプロキシを信頼するためにルート証明書を必要とします。 プロキシを検査することで、Web サイトにアクセスするか、どのタイプのコンテンツを使用するかを強制するポリシーを施行することができます。 このタイプのプロキシは、すべてのトラフィック (HTTPS さえも含む) を復号化します。

  • 明示的プロキシ—明示的なプロキシを使用して、使用するプロキシ サーバーと認証スキームを指定します。 明示的なプロキシを設定するには、各ノードに次の情報を入力する必要があります。

    1. プロキシ IP/FQDN—プロキシ マシンに到達するために使用できるアドレス。

    2. プロキシ ポート-プロキシがプロキシ トラフィックをリスンするために使用するポート番号。

    3. プロキシ プロトコル-プロキシ サーバーがサポートするものに応じて、次のいずれかのプロトコルを選択します。

      • HTTP—クライアントが送信するすべての要求を表示し、コントロールします。

      • HTTPS—サーバーにチャネルを提供します。 クライアントがサーバーの証明書を受け取り、検証します。

    4. 認証タイプ-次の認証タイプから選択します。

      • なし—追加の認証は必要ありません。

        プロキシ プロトコルとして HTTP または HTTPS のいずれかを選択した場合に利用できます。

      • ベーシック—HTTP ユーザー エージェントがリクエストを行う際にユーザー名とパスワードを指定するために使用されます。 Base64 エンコードを使用します。

        プロキシ プロトコルとして HTTP または HTTPS のいずれかを選択した場合に利用できます。

        各ノードにユーザー名とパスワードを入力する必要があります。

      • ダイジェスト—機密情報を送信する前にアカウントを確認するために使用されます。 ネットワークを経由して送信する前に、ユーザー名およびパスワードにハッシュ機能を適用します。

        プロキシ プロトコルとして HTTPS を選択した場合にのみ利用できます。

        各ノードにユーザー名とパスワードを入力する必要があります。

ハイブリッド データ セキュリティ ノードとプロキシの例

この図は、ハイブリッド データ セキュリティ、ネットワーク、およびプロキシ間の接続例を示しています。 透過的な検査および HTTPS 明示的な検査プロキシ オプションの場合、同じルート証明書がプロキシとハイブリッド データ セキュリティ ノードにインストールされている必要があります。

外部 DNS 解決ブロックモード (明示的プロキシ構成)

ノードを登録するか、またはノードのプロキシ構成を確認するとき、プロセスは DNS 検索と Cisco Webex クラウドへの接続をテストします。 内部クライアントのための外部 DNS 解決が許可されていない、明示的なプロキシ構成の展開では、ノードが DNS サーバーに問い合わせができない場合、自動的に外部 DNS 解決ブロックモードに切り替わります。 このモードでは、ノード登録および他のプロキシ接続テストを続行することができます。

  • お使いのハイブリッド データ セキュリティ ノードと統合できる次のプロキシ ソリューションを正式にサポートしています。

    • 透過的プロキシ—Cisco Web Security Appliance (WSA)。

    • 明示的プロキシ—Squid。


      HTTPS トラフィックを検査する Squid プロキシは、websocket (wss:) 接続の確立に干渉することができます。 接続の確立に干渉することができます。 この問題を回避するには、ハイブリッド データ セキュリティの Squid プロキシを設定する を参照してください。

  • 明示的プロキシに対して次の認証タイプの組み合わせがサポートされています。

    • HTTP または HTTPS による認証がありません

    • HTTP または HTTPS による基本認証

    • HTTPS のみによるダイジェスト認証

  • 透過的検査プロキシまたは HTTPS 明示的プロキシについては、プロキシのルート証明書のコピーが必要です。 このガイドに記載されている展開手順は、ハイブリッド データ セキュリティ ノードの信頼ストアにコピーをアップロードする方法を説明しています。

  • HDS ノードをホストするネットワークは、ポート 443 のアウトバウンド TCP トラフィックを強制的にプロキシ経由でルーティングするように設定されている必要があります。

  • Web トラフィックを検査するプロキシは、Web ソケット接続に干渉する場合があります。 この問題が発生した場合、wbx2.com および ciscospark.com へのトラフィックをバイパスする (検査しない) ことで問題を解決します。

ネットワーク環境でプロキシが必要な場合は、この手順を使用して、ハイブリッド データ セキュリティと統合するプロキシのタイプを指定します。 透過型のプロキシまたは HTTPS を明示的なプロキシを選択した場合、ノードのインターフェイスを使用してルート証明書をアップロードしてインストールすることができます。 インターフェイスからプロキシ接続を確認し、潜在的な問題をトラブルシューティングすることもできます。

始める前に

1

HDS ノードセットアップ URL https://[HDS Node IP or FQDN]/setup を入力して、ノードに対して設定した管理者資格情報を入力し、[サインイン] をクリックします。

2

[信頼ストアとロキシ] に移動して、次のオプションを選択します。

  • プロキシなし—プロキシを統合する前のデフォルトのオプション。 証明書の更新は必要ありません。
  • 透過型の検査なしのプロキシ—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていないため、検査なしのプロキシで動作するように変更を加える必要はありません。 証明書の更新は必要ありません。
  • 透過トンネリングまたは検査プロキシ—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていません。 ハイブリッド データ セキュリティの展開では HTTPS 構成の変更は必要ありませんが、HDS ノードはプロキシを信頼できるようにするためにルート証明書を必要とします。 プロキシを検査することで、Web サイトにアクセスするか、どのタイプのコンテンツを使用するかを強制するポリシーを施行することができます。 このタイプのプロキシは、すべてのトラフィック (HTTPS さえも含む) を復号化します。
  • 明示的プロキシ—明示的なプロキシを使用して、使用するプロキシ サーバーをクライアント (HDS ノード) を指示し、このオプションはいくつかの認証スキームをサポートします。 このオプションを選択した後、次の情報を入力する必要があります。
    1. プロキシ IP/FQDN—プロキシ マシンに到達するために使用できるアドレス。

    2. プロキシ ポート-プロキシがプロキシ トラフィックをリスンするために使用するポート番号。

    3. プロキシ プロトコル- http (クライアントから受信したすべての要求を表示して管理) または https (クライアントがサーバーへのチャネルを提供し、サーバーの証明書を検証) を選択します。 プロキシ サーバーがサポートするオプションを選択します。

    4. 認証タイプ-次の認証タイプから選択します。

      • なし—追加の認証は必要ありません。

        HTTP または HTTPS プロキシで利用できます。

      • ベーシック—HTTP ユーザー エージェントがリクエストを行う際にユーザー名とパスワードを指定するために使用されます。 Base64 エンコードを使用します。

        HTTP または HTTPS プロキシで利用できます。

        このオプションを選択した場合は、ユーザー名とパスワードも入力する必要があります。

      • ダイジェスト—機密情報を送信する前にアカウントを確認するために使用されます。 ネットワークを経由して送信する前に、ユーザー名およびパスワードにハッシュ機能を適用します。

        HTTPS プロキシに対してのみ利用できます。

        このオプションを選択した場合は、ユーザー名とパスワードも入力する必要があります。

透過型検査プロキシ、基本認証を持つ HTTP 明示プロキシ、または HTTPS 明示プロキシについては、次のステップに従ってください。

3

[ルート証明書またはエンティティ終了証明書のアップロード] をクリックし、プロキシのルート証明書を選択するために移動します。

証明書はアップロードされていますが、まだインストールされていません。証明書をインストールするにはノードを再起動する必要があります。 証明書発行者名の山形矢印をクリックして詳細を確認するか、間違っている場合は [削除] をクリックして、ファイルを再度アップロードしてください。

4

[プロキシ接続を確認する] をクリックして、ノードとプロキシ間のネットワーク接続性をテストします。

接続テストが失敗した場合は、エラーメッセージが表示され、問題を解決するための理由と方法が示されます。

外部 DNS の解決が正常に行われなかったという内容のメッセージが表示された場合、ノードが DNS サーバーに到達できなかったことを示しています。 この状況は、多くの明示的なプロキシ構成で想定されています。 セットアップを続行すると、ノードは外部 DNS 解決ブロックモードで機能します。 これがエラーによるものである思われる場合は、これらのステップを完了して、外部 DNS 解決ブロックモードをオフにするを参照してください。

5

接続テストが成功した後、明示的なプロキシについては https のみに設定し、このノードからの すべてのポートの 443/444 https 要求を明示的プロキシを通してルーティングするように切り替えます。 この設定を有効にするには 15 秒かかります。

6

[すべての証明書を信頼ストアにインストールする(HTTPS 明示プロキシまたは透過型のプロキシで表示される)] または [再起動] をクリックして、プロンプトを読み、準備が完了したら [インストール] をクリックします。

ノードが数分以内に再起動されます。

7

ノードが再起動したら、必要に応じて再度サインインして、[概要] ページを開き、接続チェックを確認してすべて緑色のステータスになっていることを確認します。

プロキシ接続の確認は webex.com のサブドメインのみをテストします。 接続の問題がある場合、インストール手順に記載されているクラウド ドメインの一部がプロキシでブロックされているという問題がよく見られます。

このセクションでは、Webex ビデオ メッシュのプロキシ サポート機能について説明します。 Cisco Webex ビデオ メッシュの展開ガイドを補足するために用意されており、https://www.cisco.com/go/video-mesh で入手可能です。 新しい展開では、仮想マシン環境にビデオ メッシュ ソフトウェアを展開してから、ノードを Cisco Webex クラウドに登録する前に、各ノードでプロキシセットアップを設定します。

Cisco Webex ビデオ メッシュは、明示的で透過的な検査と非検査プロキシをサポートしています。 これらのプロキシを Webex ビデオ メッシュの展開と関連付けて、エンタープライズからクラウドへのトラフィックをセキュリティ保護し、監視できるようにすることができます。 この機能は、シグナリングおよび管理用 https ベースのトラフィックをプロキシに送信します。 透過プロキシについては、ビデオ メッシュ ノードからのネットワーク要求はエンタープライズネットワーク ルーティング ルールにより、特定のプロキシに転送されます。 ノードにプロキシを実装した後で、証明書の管理および全体の接続状態に Webex ビデオ メッシュ管理インタフェースを使用できます。


メディアはプロキシを通して転送されません。 クラウドに直接到達するために、メディア ストリームに必要なポートを開く必要があります。

次のプロキシ タイプはビデオ メッシュによりサポートされています。

  • 明示的プロキシ (検査または検査なし)—明示的なプロキシを使用して、プロキシサーバー使用するクライアント (ビデオ メッシュ ノード) を指示します。 このオプションは、次のいずれかの認証タイプに対応しています。

    • なし—追加の認証は必要ありません。 (HTTP または HTTPS 明示的プロキシの場合)

    • ベーシック—HTTP ユーザー エージェントがリクエストを行う際にユーザー名とパスワードを指定するために使用されます。 (HTTP または HTTPS 明示的プロキシの場合)

    • ダイジェスト—機密情報を送信する前にアカウントの識別を確認するために使用され、ネットワークを経由して送信する前に、ユーザー名とパスワードにハッシュ機能を適用します。 (HTTPS 明示的プロキシの場合)

    • NTLM—ダイジェストと同様に、NTLM は機密情報を送信する前にアカウントの ID を確認するために使用されます。 ユーザー名およびパスワードの代わりに Windows 資格情報を使用します。 この認証スキームでは、複数の交換が完了する必要があります。 (HTTP 明示的プロキシの場合)

  • 透過型プロキシ (検査なし)—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていないため、検査なしのプロキシで動作するように変更を加える必要はありません。

  • 透過型プロキシ (検査あり)—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていません。 ビデオ メッシュでは http(s) 構成の変更は必要ありませんが、ビデオ ノードはプロキシを信頼できるようにするためにルート証明書を必要とします。 プロキシの検査は、アクセスする Web サイトや許可されないコンテンツのタイプに関するポリシーを施行するために、一般的に IT が使用します。 このタイプのプロキシは、すべてのトラフィック (HTTPS さえも含む) を復号化します。

図 1. Webex ビデオ メッシュ ノードとプロキシの例.

この図は、Webex ビデオ メッシュ、ネットワーク、およびプロキシ間の接続例を示しています。 透過的な検査および明示的な検査プロキシ オプションの場合、同じルート証明書がプロキシとビデオ メッシュ ノードにインストールされなければなりません。

  • お使いの Webex ビデオ メッシュ ノードと統合できる次のプロキシ ソリューションを正式にサポートしています。

    • 透過プロキシ用の Cisco Web Security Appliance (WSA)

    • 明示的プロキシ用の Squid

  • 明示的なプロキシまたは検査を行う透過的な検査プロキシ (トラフィックを復号する) の場合、Web インターフェイスの Webex ビデオ メッシュ ノード信頼ストアにアップロードする必要があるプロキシのルート証明書のコピーを持っている必要があります。

  • 以下の明示的なプロキシと認証タイプの組み合わせをサポートしています。

    • http および https による認証がありません

    • http および https による基本認証

    • https のみによるダイジェスト認証

    • http のみによる NTLM 認証

  • 透過プロキシについては、ルーター/スイッチを使用して、HTTPS/443 トラフィックをプロキシに移動する必要があります。 また、強制的に Web ソケット/444 をプロキシに移動させることもできます。 (Web ソケットは https を使用します。) ポート 444 は、ネットワークの設定によって異なります。 ポート 444 がプロキシを通してルーティングされていない場合、ノードからクラウドに直接開く必要があります。


    Webex ビデオ メッシュは、クラウド サービスへの Web ソケット接続が必要なため、ノードが正常に機能するようになります。 明示的な検査および透過的な検査プロキシでは、正確な websocket 接続に必要な http ヘッダーが変更され、websocket 接続に失敗します。

    この問題がポート 443 で発生する場合 (透過型のプロキシが有効になっている場合)、Control Hub での登録後の警告が表示されます。 「Webex ビデオ メッシュ SIP は正しく動作していません。」 プロキシが有効になっていない場合、同じ警告が発生する可能性があります。 websocket ヘッダーがポート 443 でブロックされている場合、メディアはアプリと SIP クライアント間ではフローしません。

    メディアがフローしていない場合、ポート444またはポート443経由の https トラフィックが失敗した場合によく発生します。

    • プロキシが検査されていませんが、ポート 444 トラフィックはプロキシによって許可されていません。

    • ポート443またはポート444トラフィックはプロキシにより許可されていますが、これは検査プロキシであり、websocket を壊してしまいます。

    これらの問題を修正するには、ポート 444 および 443 のポートおよびの「バイパス」または「スプライス」 (検査を無効にする) が必要な場合があります。 *.wbx2.com および *.ciscospark.com

Webex ビデオ メッシュとインテグレーションする必要があるプロキシのタイプを指定するために、この手順を使用します。 透過型のプロキシまたは明示的なプロキシを選択した場合、ノードのインターフェイスを使用してルート証明書をアップロードしてインストール、プロキシ接続を確認し、潜在的な問題をトラブルシューティングすることができます。

始める前に

1

Web ブラウザーで Webex ビデオ メッシュ セットアップ URL https://[IP or FQDN]/setup を入力して、ノードに対して設定した管理者資格情報を入力し、[サイン イン] をクリックします。

2

[信頼ストアとロキシ] に移動して、次のオプションを選択します。

  • プロキシなし—プロキシを統合する前のデフォルトのオプション。 証明書の更新は必要ありません。
  • 透過型プロキシ (検査なし)—ビデオ メッシュ ノードは特定のプロキシ サーバー アドレスを使用するように設定されていないため、検査なしのプロキシで動作するように変更を加える必要はありません。 証明書の更新は必要ありません。
  • 透過型プロキシ (検査あり)—ビデオ メッシュ ノードは特定のプロキシ サーバー アドレスを使用するように設定されていません。 ビデオ メッシュでは http(s) 構成の変更は必要ありませんが;ビデオ ノードはプロキシを信頼できるようにするためにルート証明書を必要とします。 プロキシの検査は、アクセスする Web サイトや許可されないコンテンツのタイプに関するポリシーを施行するために、一般的に IT が使用します。 このタイプのプロキシは、すべてのトラフィック (HTTPS さえも含む) を復号化します。
  • 明示的プロキシ—明示的なプロキシを使用して、使用するプロキシ サーバーをクライアント (ビデオ メッシュ ノード) を指示し、このオプションはいくつかの認証スキームをサポートします。 このオプションを選択した後、次の情報を入力する必要があります。
    1. プロキシ IP/FQDN—プロキシ マシンに到達するために使用できるアドレス。

    2. プロキシ ポート-プロキシがプロキシ トラフィックをリスンするために使用するポート番号。

    3. プロキシ プロトコル-http (ビデオ メッシュ トンネルで https プロキシ経由の https トラフィック) または https (ビデオメッシュノードからプロキシへのトラフィックを https プロトコルを使用) を選択します。 プロキシ サーバーがサポートするオプションを選択します。

    4. プロキシ環境に応じて、以下の認証タイプの中から選択します。

      オプション

      使用法

      なし

      認証方法がない HTTP または HTTPS 明示的プロキシを選択します。

      ベーシック

      HTTP または HTTPS 明示的プロキシに利用できます。

      HTTP ユーザー エージェントがリクエストを行う際にユーザー名とパスワードを指定するために使用されます。

      ダイジェスト

      HTTPS 明示的プロキシに対してのみ利用できます。

      機密情報を送信する前にアカウントを確認するために使用され、ネットワークを経由して送信する前に、ユーザー名とパスワードにハッシュ機能を適用します。

      NTLM

      HTTPS 明示的プロキシに対してのみ利用できます。

      ダイジェストと同様に、機密情報を送信する前にアカウントを確認するために使用されます。 ユーザー名およびパスワードの代わりに Windows 資格情報を使用します。

      また、このオプションを選択した場合、[NTLM ドメイン] フィールドで、プロキシが認証のために使用する Active Directory ドメインを入力します。 [NTLM ワークステーション] フィールドに、指定した NTLM ドメイン内のプロキシ ワークステーション (ワークステーション アカウントまたはマシン アカウントとも呼ばれる) の名を入力します。

透過的または明示的なプロキシの次の手順に従います。

3

[ルート証明書またはエンティティ終了証明書のアップロード] をクリックし、明示的または透過的検査プロキシのルート証明書を検索し、選択します。

証明書はアップロードされていますが、インストールされていません。証明書をインストールするにはノードを再起動する必要があるためです。 証明書発行者名の矢印をクリックして詳細を確認するか、間違っている場合は [削除] をクリックして、ファイルを再度アップロードしてください。

4

透過型の検査または明示的プロキシの場合、[プロキシ接続を確認する] をクリックして、ビデオ メッシュ ノードとプロキシ間のネットワーク接続性をテストします。

接続テストが失敗した場合は、エラーメッセージが表示され、問題を解決するための理由と方法が示されます。

5

接続テストが成功した後、明示的なプロキシについては、このノードからのすべてのポート 443/444 https 要求を明示的プロキシを通してルーティングするように切り替えます。 この設定を有効にするには 15 秒かかります。

6

[すべての証明書を信頼ストアにインストールする(HTTPS 明示プロキシまたは透過型のプロキシで表示される)] または [再起動](ルート証明書が追加されない場合に表示される) をクリックして、プロンプトを読み、準備が完了したら [インストール] をクリックします。

ノードが数分以内に再起動されます。

7

ノードが再起動したら、必要に応じて再度サインインして、[概要] ページを開き、接続チェックを確認してすべて緑色のステータスになっていることを確認します。

プロキシ接続の確認は webex.com のサブドメインのみをテストします。 接続の問題がある場合、インストール手順に記載されているクラウド ドメインの一部がプロキシでブロックされているという問題がよく見られます。

どのトラフィックがプロキシを通じて行われるか

ビデオ メッシュの場合、メディアはプロキシを通過しません。 この機能は、シグナリングおよび管理用 https ベースのトラフィックをプロキシに送信します。クラウドに直接到達するために、メディア ストリームに必要なポートを開く必要があります。

プロキシで TCP ポート 444 が有効になっていません

このポートはビデオ メッシュの要件です。ビデオ メッシュはこのポートを使用して、正常に機能するために必要なクラウドベースのサービスにアクセスするためです。 プロキシ例外はこのポートに対して、ビデオ メッシュ展開ガイド および Webex Teams サービスのネットワーク要件に記載されているとおりに行う必要があります。


IP アドレスによりシグナリング トラフィックをフィルタリングは、当社のソリューションにより使用される IP アドレスが動的で、いつでも変更されてしまう可能性があるため、サポートされていません。

ルート証明書がインストールされていません

ノードが明示的プロキシと通信しているとき、ルート証明書をインストールして、ファイアウォール上の URL の例外を入力する必要があります。

接続確認が失敗しました

プロキシ接続確認が成功し、プロキシインストールが完了した場合、概要ページの接続確認は次のような理由で引き続き失敗する場合があります。

  • プロキシが、webex.com に移動しないトラフィックを検査している。

  • プロキシが、webex.com 以外のドメインをブロックしている。

認証の詳細が正しくない

認証メカニズムを使用するプロキシについては、ノードに正しい認証詳細を追加していることを確認してください。

プロキシの輻輳

プロキシの輻輳により、遅延が発生し、クラウドへのトラフィックが減少する場合があります。 プロキシ環境を確認して、トラフィックの調整が必要かどうかを確認してください。

HTTPS トラフィックを検査する Squid プロキシは、websocket (wss:) 接続の確立に干渉することができます。 これは、Hybrid Data Security が必要な接続です。 これらのセクションでは、wss: トラフィックを無視するためのさまざまなバージョンの Squid の設定方法について説明してい ます。 これは、サービスの適切な運用のためのトラフィックです。

Squid 4 および5

On_unsupported_protocol ディレクティブを squid.conf:

on_unsupported_protocol tunnel all に追加します。

Squid 3.5.27

以下の規則が squid.conf に追加されて、ハイブリッドデータセキュリティのテストに成功しました。 これらのルールは、機能を開発し、Webex クラウドを更新する際に変更されることがあります。

acl wssMercuryConnection ssl::server_name_regex mercury-connection ssl_bump splice wssMercuryConnection acl step1 at_step SslBump1 acl step2 at_step SslBump2 acl step3 at_step SslBump3 ssl_bump peek step1 all ssl_bump stare step2 all ssl_bump bump step3 all