ハイブリッド データ セキュリティとビデオ メッシュのプロキシ サポート
Cisco Webex Hybrid Data Security および Webex ビデオ メッシュでプロキシを設定する方法については、透過型検査プロキシまたは明示的プロキシを使用して動作するようにノードを設定するための要件と手順などを参照してください。基本的なトラブルシューティング情報も確認できます。
このセクションでは、ハイブリッド データ セキュリティのプロキシ サポート機能について説明します。Cisco Webex ハイブリッド データ セキュリティの展開ガイドを補足するために用意されており、https://www.cisco.com/go/hybrid-data-security で入手可能です。新しい展開では、HDS 設定 ISO をノードでアップロードし、マウントした後で、Cisco Webex クラウドに登録する前に、各ノードでプロキシのセットアップを設定します。
ハイブリッド データ セキュリティは、明示的な透過的な検査および非検査プロキシをサポートします。これらのプロキシを展開に関連付けることができます。これにより、エンタープライズからクラウドに送信されるトラフィックをセキュリティ保護し、監視することができます。証明書の管理のノードでプラットフォーム管理インターフェイスを使用して、ノードでプロキシを設定した後で、全体的な接続ステータスを確認することができます。
ハイブリッド データ セキュリティ ノードは、以下のプロキシ オプションをサポートしています。
-
プロキシなし: プロキシを統合するために HDS ノードのセットアップ信頼ストアとプロキシ構成を使用しない場合のデフォルト。証明書の更新は必要ありません。
-
透過的な検査なしのプロキシ: ノードは特定のプロキシ サーバー アドレスを使用するように設定されていないため、検査なしのプロキシで動作するように変更を加える必要はありません。証明書の更新は必要ありません。
-
透過的なトンネリングまたは検査プロキシ: ノードは特定のプロキシ サーバー アドレスを使用するように設定されていません。ノードでは、HTTP または HTTPS の設定変更は必要ありません。ただし、ノードはプロキシを信頼するためにルート証明書を必要とします。プロキシを検査することで、Web サイトにアクセスするか、どのタイプのコンテンツを使用するかを強制するポリシーを施行することができます。このタイプのプロキシは、すべてのトラフィック (HTTPS さえも含む) を復号化します。
-
明示的プロキシ: 明示的プロキシを使用して、使用するプロキシ サーバーと認証スキームを HDS ノードに指示します。明示的なプロキシを設定するには、各ノードに次の情報を入力する必要があります。
-
プロキシ IP/FQDN—プロキシ マシンに到達するために使用できるアドレス。
-
プロキシ ポート: プロキシがプロキシ トラフィックをリッスンするために使用するポート番号。
-
プロキシ プロトコル: プロキシ サーバーがサポートしているものに応じて、次のプロトコルから選択します。
-
HTTP—クライアントが送信するすべての要求を表示し、コントロールします。
-
HTTPS—サーバーにチャネルを提供します。クライアントがサーバーの証明書を受け取り、検証します。
-
-
認証タイプ: 次の認証タイプから選択します。
-
なし: 追加の認証は必要ありません。
プロキシ プロトコルとして 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 |
2 |
[信頼ストアとロキシ] に移動して、次のオプションを選択します。
透過型検査プロキシ、基本認証を持つ HTTP 明示プロキシ、または HTTPS 明示プロキシについては、次のステップに従ってください。 |
3 |
[ルート証明書またはエンティティ終了証明書のアップロード] をクリックし、プロキシのルート証明書を選択するために移動します。 証明書はアップロードされていますが、まだインストールされていません。証明書をインストールするにはノードを再起動する必要があります。証明書発行者名の山形矢印をクリックして詳細を確認するか、間違っている場合は [削除] をクリックして、ファイルを再度アップロードしてください。 |
4 |
[プロキシ接続を確認する] をクリックして、ノードとプロキシ間のネットワーク接続性をテストします。 接続テストが失敗した場合は、エラーメッセージが表示され、問題を解決するための理由と方法が示されます。 外部 DNS の解決が正常に行われなかったという内容のメッセージが表示された場合、ノードが DNS サーバーに到達できなかったことを示しています。この状況は、多くの明示的なプロキシ構成で想定されています。セットアップを続行すると、ノードは外部 DNS 解決ブロックモードで機能します。これがエラーだと思われる場合は、これらの手順を完了し、「ブロックされた外部 DNS 解決モードをオフにする」を参照してください。 |
5 |
接続テストが成功した後、明示的なプロキシについては https のみに設定し、このノードからの すべてのポートの 443/444 https 要求を明示的プロキシを通してルーティングするように切り替えます。この設定を有効にするには 15 秒かかります。 |
6 |
[すべての証明書を信頼ストアにインストールする(HTTPS 明示プロキシまたは透過型のプロキシで表示される)] または [再起動] をクリックして、プロンプトを読み、準備が完了したら [インストール] をクリックします。 ノードが数分以内に再起動されます。 |
7 |
ノードが再起動したら、必要に応じて再度サインインして、[概要] ページを開き、接続チェックを確認してすべて緑色のステータスになっていることを確認します。 プロキシ接続の確認は webex.com のサブドメインのみをテストします。接続の問題がある場合、インストール手順に記載されているクラウド ドメインの一部がプロキシでブロックされているという問題がよく見られます。 |
ノードを登録するか、またはノードのプロキシ構成を確認するとき、プロセスは DNS 検索と Cisco Webex クラウドへの接続をテストします。ノードの DNS サーバーがパブリック DNS 名を解決できない場合、ノードは自動的に外部 DNS 解決ブロックモードに進みます。
ノードが内部 DNS サーバーを通してパブリック DNS 名を解決できる場合、各ノードでプロキシ接続テストを再実行することで、このモードをオフにすることができます。
開始する前に
1 |
Web ブラウザで、ハイブリッド データ セキュリティ ノード インターフェイス (IP アドレス/セットアップ、例: https://192.0.2.0/setup), ノードに設定した管理者資格情報を入力し、 サインイン。 |
2 |
[概要] (デフォルトページ) に移動します。 有効になっている場合、 [外部 DNS 解決ブロック] は [はい] に設定されています。 |
3 |
[信頼ストアとプロキシ] ページに移動します。 |
4 |
[プロキシ接続を確認する] をクリックします。 外部 DNS の解決が正常に行われなかったという内容のメッセージが表示された場合、ノードが DNS サーバーに到達できなかったことを示しており、このモードに留まっています。そうでない場合には、ノードを再起動して[概要] ページに戻ると、[外部 DNS 解決ブロック] は [いいえ] に設定されるはずです。 |
次に行うこと
このセクションでは、Webex ビデオ メッシュのプロキシ サポート機能について説明します。Cisco Webex ビデオ メッシュの展開ガイドを補足するために用意されており、https://www.cisco.com/go/video-mesh で入手可能です。新しい展開では、仮想マシン環境にビデオ メッシュ ソフトウェアを展開してから、ノードを Cisco Webex クラウドに登録する前に、各ノードでプロキシセットアップを設定します。
ビデオ メッシュは、明示的で透過的な検査および非検査プロキシをサポートします。これらのプロキシをビデオ メッシュ展開に関連付けることで、エンタープライズからクラウドへのトラフィックを保護し、監視できます。この機能は、シグナリングおよび管理用 https ベースのトラフィックをプロキシに送信します。透過プロキシについては、ビデオ メッシュ ノードからのネットワーク要求はエンタープライズネットワーク ルーティング ルールにより、特定のプロキシに転送されます。ノードでプロキシを実装した後、証明書管理と全体的な接続ステータスにビデオ メッシュ管理インターフェイスを使用できます。
メディアはプロキシを通して転送されません。クラウドに直接到達するために、メディア ストリームに必要なポートを開く必要があります。「管理用のポートとプロトコル」を参照してください。
次のプロキシ タイプはビデオ メッシュによりサポートされています。
-
明示的プロキシ (検査または検査なし)—明示的なプロキシを使用して、プロキシサーバー使用するクライアント (ビデオ メッシュ ノード) を指示します。このオプションは、次のいずれかの認証タイプに対応しています。
-
なし—追加の認証は必要ありません。(HTTP または HTTPS 明示的プロキシの場合)
-
ベーシック—HTTP ユーザー エージェントがリクエストを行う際にユーザー名とパスワードを指定するために使用されます。(HTTP または HTTPS 明示的プロキシの場合)
-
ダイジェスト—機密情報を送信する前にアカウントの識別を確認するために使用され、ネットワークを経由して送信する前に、ユーザー名とパスワードにハッシュ機能を適用します。(HTTPS 明示的プロキシの場合)
-
NTLM—ダイジェストと同様に、NTLM は機密情報を送信する前にアカウントの ID を確認するために使用されます。ユーザー名およびパスワードの代わりに Windows 資格情報を使用します。この認証スキームでは、複数の交換が完了する必要があります。(HTTP 明示的プロキシの場合)
-
-
透過型プロキシ (検査なし)—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていないため、検査なしのプロキシで動作するように変更を加える必要はありません。
-
透過型プロキシ (検査あり)—ノードは特定のプロキシ サーバー アドレスを使用するように設定されていません。ビデオ メッシュでは http(s) 構成の変更は必要ありませんが、ビデオ ノードはプロキシを信頼できるようにするためにルート証明書を必要とします。プロキシの検査は、アクセスする Web サイトや許可されないコンテンツのタイプに関するポリシーを施行するために、一般的に IT が使用します。このタイプのプロキシは、すべてのトラフィック (HTTPS さえも含む) を復号化します。
-
ビデオ メッシュ ノードと統合できる次のプロキシ ソリューションを正式にサポートしています。
-
透過プロキシ用の Cisco Web Security Appliance (WSA)
-
明示的プロキシ用の Squid
-
-
明示的なプロキシまたは検査する透過的な検査プロキシ (トラフィックを復号) の場合、Web インターフェイスのビデオ メッシュ ノードの信頼ストアにアップロードする必要があるプロキシのルート証明書のコピーを持っている必要があります。
-
以下の明示的なプロキシと認証タイプの組み合わせをサポートしています。
-
http および https による認証がありません
-
http および https による基本認証
-
https のみによるダイジェスト認証
-
http のみによる NTLM 認証
-
-
透過プロキシについては、ルーター/スイッチを使用して、HTTPS/443 トラフィックをプロキシに移動する必要があります。また、Web ソケットを強制的にプロキシに移動することもできます。(Web ソケットは https を使用します。)
ビデオ メッシュは、クラウド サービスへの Web ソケット接続を必要とするため、ノードが正しく機能します。明示的な検査および透過的な検査プロキシでは、適切な websocket 接続に http ヘッダーが必要です。変更された場合、websocket 接続は失敗します。
ポート 443 で websocket 接続に失敗した場合 (透過型検査プロキシが有効になっている)、Control Hub で登録後の警告が表示されます。「Webex ビデオ メッシュ SIP 通話が正常に機能していません。」プロキシが有効になっていない場合、同じ警告が発生する可能性があります。websocket ヘッダーがポート 443 でブロックされている場合、メディアはアプリと SIP クライアント間ではフローしません。
メディアがフローしていない場合、ポート 443 経由のノードからの https トラフィックが失敗した場合に発生します。
-
ポート 443 トラフィックはプロキシによって許可されますが、検査プロキシであり、websocket を壊しています。
これらの問題を修正するには、ポート 443 で *.wbx2.com および *.ciscospark.com に「バイパス」または「スプライス」(検査を無効にする)する必要がある場合があります。
-
ビデオ メッシュと統合するプロキシのタイプを指定するには、次の手順を使用します。透過型のプロキシまたは明示的なプロキシを選択した場合、ノードのインターフェイスを使用してルート証明書をアップロードしてインストール、プロキシ接続を確認し、潜在的な問題をトラブルシューティングすることができます。
開始する前に
-
サポートされているプロキシ オプションの概要については、「ビデオ メッシュのプロキシ サポート 」を参照してください。
1 |
ウェブ ブラウザーでビデオ メッシュのセットアップ URL | ||||||||||
2 |
[信頼ストアとロキシ] に移動して、次のオプションを選択します。
透過的または明示的なプロキシの次の手順に従います。 | ||||||||||
3 |
[ルート証明書またはエンティティ終了証明書のアップロード] をクリックし、明示的または透過的検査プロキシのルート証明書を検索し、選択します。 証明書はアップロードされていますが、インストールされていません。証明書をインストールするにはノードを再起動する必要があるためです。証明書発行者名の矢印をクリックして詳細を確認するか、間違っている場合は [削除] をクリックして、ファイルを再度アップロードしてください。 | ||||||||||
4 |
透過型の検査または明示的プロキシの場合、[プロキシ接続を確認する] をクリックして、ビデオ メッシュ ノードとプロキシ間のネットワーク接続性をテストします。 接続テストが失敗した場合は、エラーメッセージが表示され、問題を解決するための理由と方法が示されます。 | ||||||||||
5 |
接続テストに合格した後、明示的なプロキシについては、[このノードからのすべてのポート 443 https 要求を明示的なプロキシを通してルーティングする] に切り替えます。この設定を有効にするには 15 秒かかります。 | ||||||||||
6 |
[すべての証明書を信頼ストアにインストールする(HTTPS 明示プロキシまたは透過型のプロキシで表示される)] または [再起動](ルート証明書が追加されない場合に表示される) をクリックして、プロンプトを読み、準備が完了したら [インストール] をクリックします。 ノードが数分以内に再起動されます。 | ||||||||||
7 |
ノードが再起動したら、必要に応じて再度サインインして、[概要] ページを開き、接続チェックを確認してすべて緑色のステータスになっていることを確認します。 プロキシ接続の確認は webex.com のサブドメインのみをテストします。接続の問題がある場合、インストール手順に記載されているクラウド ドメインの一部がプロキシでブロックされているという問題がよく見られます。 |
どのトラフィックがプロキシを通じて行われるか
ビデオ メッシュの場合、メディアはプロキシを通過しません。この機能は、シグナリングおよび管理用 https ベースのトラフィックをプロキシに送信します。クラウドに直接到達するために、メディア ストリームに必要なポートを開く必要があります。
プロキシで TCP ポート 444 が有効になっていません
このポートはビデオ メッシュの要件です。ビデオ メッシュはこのポートを使用して、正常に機能するために必要なクラウドベースのサービスにアクセスするためです。プロキシ例外はこのポートに対して、ビデオ メッシュ展開ガイド および Webex Teams サービスのネットワーク要件に記載されているとおりに行う必要があります。
IP アドレスによりシグナリング トラフィックをフィルタリングは、当社のソリューションにより使用される IP アドレスが動的で、いつでも変更されてしまう可能性があるため、サポートされていません。
ルート証明書がインストールされていません
ノードが明示的プロキシと通信しているとき、ルート証明書をインストールして、ファイアウォール上の URL の例外を入力する必要があります。
接続確認が失敗しました
プロキシ接続確認が成功し、プロキシインストールが完了した場合、概要ページの接続確認は次のような理由で引き続き失敗する場合があります。
-
プロキシが、webex.com に移動しないトラフィックを検査している。
-
プロキシが、webex.com 以外のドメインをブロックしている。
認証の詳細が正しくない
認証メカニズムを使用するプロキシについては、ノードに正しい認証詳細を追加していることを確認してください。
プロキシの輻輳
プロキシの輻輳により、遅延が発生し、クラウドへのトラフィックが減少する場合があります。プロキシ環境を確認して、トラフィックの調整が必要かどうかを確認してください。
Websocket は Squid プロキシを通じて接続できません
HTTPS トラフィックを検査する Squid プロキシは、ハイブリッド データ セキュリティが必要とする websocket (wss:
) 接続の確立に干渉する可能性があります。これらのセクションでは、wss: トラフィックを無視するためのさまざまなバージョンの Squid の設定方法について説明してい ます。
これは、サービスの適切な運用のためのトラフィックです。
Squid 4 および5
on_unsupported_protocol
ディレクティブを squid.conf
に追加します。
on_unsupported_protocol すべてトンネル
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