Cisco セキュリティ アプライアンス コマンドライン コンフィギュレーション ガイド v.8.0
Cisco Unified Communications プロキシ機能の設定
Cisco Unified Communications プロキシ機能の設定
発行日;2012/02/01 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 20MB) | フィードバック

目次

Cisco Unified Communications プロキシ機能の設定

Cisco Unified Communications の適応型セキュリティ アプライアンスの概要

Cisco Unified Communications での TLS プロキシ アプリケーション

Cisco Unified Communications プロキシ機能のライセンス

フォン プロキシ

フォン プロキシの概要

フォン プロキシの制限事項

フォン プロキシ設定

設定の前提条件

7960 および 7940 IP 電話をサポートするための要件

複数のインターフェイスにおける IP 電話のアドレッシングの要件

フォン プロキシでサポートされる Cisco UCM と IP 電話

エンド ユーザの電話のプロビジョニング

ノンセキュア Cisco UCM クラスタでのフォン プロキシの設定

Cisco UCM からの証明書のインポート

混合モードの Cisco UCM クラスタでのフォン プロキシの設定

Cisco IP Communicator のフォン プロキシ設定

UDP ポート転送用に Linksys ルータを設定

レート制限 TFTP 要求の概要

メディア終端アドレス宛の ICMP トラフィックの概要

フォン プロキシのトラブルシューティング

セキュリティ アプライアンスからのデバッグ情報

IP 電話からのデバッグ情報

IP 電話の登録の失敗

メディア終端アドレスのエラー

IP 電話の音声の問題

SAST キーの保存

暗号化音声検査の TLS プロキシ

概要

TLS プロキシの設定

TLS プロキシのデバッグ

CTL クライアント

Cisco Unified Mobility と MMP 検査エンジン

モビリティ プロキシの概要

モビリティ プロキシの導入シナリオ

Cisco UMA 配置の信頼関係の確立

Cisco Unified Mobility のセキュリティ アプライアンスの設定

Cisco Unified Mobility のデバッグ

Cisco Unified Presence

Cisco Unified Presence のアーキテクチャ

プレゼンス フェデレーションでの信頼関係の確立

Cisco UP とセキュリティ アプライアンス間のセキュリティ証明書の交換に関する概要

Cisco Unified Presence のプレゼンス フェデレーション プロキシの設定

Cisco Unified Presence のセキュリティ アプライアンスのデバッグ

Cisco Unified Communications プロキシ機能の設定例

フォン プロキシの設定例

例 1:Publisher でのノンセキュア Cisco UCM クラスタ、Cisco UCM、および TFTP サーバ

例 2:Publisher での混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバ

例 3:別のサーバでの混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバ

例 4:別のサーバでの混合モードの Cisco UCM クラスタ、プライマリ Cisco UCM、セカンダリ、および TFTP サーバ

例 5:Publisher での混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバでの LSC プロビジョニング

例 6:VLAN トランスバーサル

Cisco Unified Mobility の設定例

例 1:Cisco UMC と Cisco UMA のアーキテクチャ:TLS プロキシと MMP 検査を備えたファイアウォールとしてのセキュリティ アプライアンス

例 2:Cisco UMC および Cisco UMA アーキテクチャ:TLS プロキシとしてだけのセキュリティ アプライアンス

Cisco Unified Presence 設定例

Cisco Unified Communications プロキシ機能の設定

この章では、Cisco Unified Communications プロキシ機能用に適応型セキュリティ アプライアンスを設定する方法について説明します。

この章は、次の項で構成されています。

「Cisco Unified Communications の適応型セキュリティ アプライアンスの概要」

「Cisco Unified Communications での TLS プロキシ アプリケーション」

「フォン プロキシ」

「暗号化音声検査の TLS プロキシ」

「Cisco Unified Mobility と MMP 検査エンジン」

「Cisco Unified Presence」

「Cisco Unified Communications プロキシ機能の設定例」

Cisco Unified Communications の適応型セキュリティ アプライアンスの概要

ここでは、Cisco ASA 5500 シリーズ アプライアンスの Cisco UC プロキシ機能について説明します。プロキシの目的は、クライアントとサーバの間の接続を終了して、再発信することです。プロキシは、内部ネットワークのセキュリティを確保するために、トラフィック検査、プロトコルへの準拠、およびポリシー制御などのさまざまなセキュリティ機能を提供します。ますます普及してきているプロキシ機能は、セキュリティ ポリシーを適用するために暗号化された接続を終了し、同時に接続の機密性を維持することです。Cisco ASA 5500 シリーズ アプライアンスは、ユニファイド コミュニケーションの導入のためにプロキシ機能を提供する戦略的なプラットフォームです。

Cisco UC プロキシには次のソリューションが含まれています。

フォン プロキシ:シスコの暗号化されたエンドポイントのセキュアなリモート アクセスと、シスコのソフトフォンの VLANトラバーサル

フォン プロキシ機能を使用すると、セキュアなリモート アクセスを実現するために、Cisco SRTP/TLSで暗号化されたエンドポイントを終端することができます。フォン プロキシによって、大規模な Virtual Private VPNリモート アクセス ハードウェアを導入せずに、セキュアな電話機を大規模展開できます。エンド ユーザ インフラストラクチャは IP エンドポイントだけに制限され、VPN トンネルまたはハードウェアは不要です。

シスコの適応型セキュリティ アプライアンス フォン プロキシは、Cisco Unified Phone Proxy の代替製品です。また、フォン プロキシは、ソフトフォン アプリケーションの音声とデータ VLAN トラバーサルのために導入することもできます。セキュリティ アプライアンスを通じて Cisco IP Communicator(CIPC)のトラフィック(メディアとシグナリングの両方)をプロキシできるため、音声とデータ VLAN の間でコールを安全に通過させることができます。

TLS プロキシとフォン プロキシの違いについては、『TLS Proxy vs. Phone Proxy』のホワイト ペーパーなど、次の URL にあるユニファイド コミュニケーションのコンテンツを 参照してください。

http://www.cisco.com/go/secureuc

TLS プロキシ:Cisco Unified Communications の暗号化されたシグナリングの復号化と検査

エンドツーエンド暗号化によって、多くの場合ネットワーク セキュリティ アプライアンスはメディアとシグナリング トラフィックを「認識しない」ままになります。これは、アクセス コントロールと脅威防止セキュリティ機能を危険にさらすおそれがあります。この可視性の欠落によって、ファイアウォール機能と暗号化された音声との間の相互運用性がなくなり、企業は両方の主要なセキュリティ要件を満たすことができないままになります。

セキュリティ アプライアンスは、Cisco Unified Communications Manager(Cisco UCM)へのシスコの暗号化されたエンドポイントから、暗号化されたシグナリングを代行受信して復号化し、必要な脅威保護とアクセス コントロールを適用できます。Cisco UCM サーバへのトラフィックの再暗号化を行うことによって、機密保持を確保することもできます。

通常、セキュリティ アプライアンス TLS プロキシ機能は、キャンパスのユニファイド コミュニケーション ネットワークに配置されます。このソリューションは、エンドツーエンド暗号化とファイアウォールを使用して Unified Communications Manager サーバを保護する配置の場合に理想的です。

モビリティ プロキシ:Cisco Unified Mobility Advantage サーバと Cisco Unified Mobile Communicator クライアント間のセキュアな通信

Cisco Unified Mobility ソリューションには Cisco Unified Mobile Communicator(Cisco UMC)が含まれます。これは、エンタープライズ コミュニケーション アプリケーションとサービスを携帯電話と Cisco Unified Mobility Advantage(Cisco UMA)サーバにまで拡張する、モバイル ハンドセット用の使いやすいソフトウェア アプリケーションです。Cisco Unified Mobility ソリューションは、コミュニケーション エクスペリエンスを効率化し、Single Number Reach と、モバイル エンドポイントのユニファイド コミュニケーション インフラストラクチャへの統合を可能にします。

セキュリティ アプライアンスはプロキシとして機能し、Cisco UMC と Cisco UMA 間の TLS シグナリングの終端と再発信を行います。プロキシ セキュリティ機能の一部として、Cisco UMC と Cisco UMA 間のプロトコルである Cisco UMA Mobile Multiplexing Protocol(MMP)で検査がイネーブルになっています。

プレゼンス フェデレーション プロキシ:Cisco Unified Presence サーバと Cisco Presence および Microsoft Presence サーバ間のセキュアな接続

Cisco Unified Presence ソリューションは、ユーザが特定の時間に IP 電話のような通信デバイスを使用しているかどうかなど、ユーザのアベイラビリティとステータスに関する情報を収集します。また、Web Collaboration やテレビ会議がイネーブルになっているかどうかなど、通信機能に関する情報も収集します。Cisco Unified Personal Communicator や Cisco UCM などのアプリケーションは、Cisco Unified Presence によって収集されたユーザ情報を使用して、コラボレーション型の通信を行うために最も効果的な方法を判別することで、ユーザがより効率的に同僚に接続できるようにして、生産性を向上させることができます。

セキュリティ アプライアンスをセキュアなプレゼンス フェデレーション プロキシとして使用すると、企業は、Cisco Unified Presence(Cisco UP)サーバを他の Cisco Presence または Microsoft Presence サーバに安全に接続して、企業内通信を可能にできます。セキュリティ アプライアンスは、サーバ間の TLS 接続を終了します。サーバ間の SIP 通信のポリシーを検査して適用することができます。

Cisco Unified Communications での TLS プロキシ アプリケーション

表 27-1 に、セキュリティ アプライアンスで TLS プロキシを使用する Cisco Unified Communications アプリケーションを示します。

 

表 27-1 TLS プロキシ アプリケーションとセキュリティ アプライアンス

アプリケーション
TLS クライアント
TLS サーバ
クライアント認証
セキュリティ アプライアンス サーバの役割
セキュリティ アプライアンス クライアントの役割

フォン プロキシと TLS プロキシ

IP 電話

Cisco UCM

あり

プロキシ証明書、自己署名または内部 CAによる

セキュリティ アプライアンス CA によって署名されたローカル ダイナミック証明書(フォン プロキシ アプリケーションでは証明書は必要ないことがあります)

モビリティ プロキシ

Cisco UMC

Cisco UMA

なし

Cisco UMA 秘密キーまたは証明書の偽装の使用

任意のスタティックな設定済み証明書

プレゼンス フェデレーション プロキシ

Cisco UP または MS LCS/OCS

Cisco UP または MS LCS/OCS

あり

プロキシ証明書、自己署名または内部 CA による

Cisco UP 秘密キーまたは証明書の偽装の使用

セキュリティ アプライアンスでは、さまざまな音声アプリケーションで TLS プロキシがサポートされます。フォン プロキシの場合は、セキュリティ アプライアンスで実行されている TLS プロキシには、次の主な機能があります。

セキュリティ アプライアンスは、Cisco UCM クラスタがノンセキュア モードになっている場合でも、インターネットを介してフォン プロキシに接続されているリモート IP 電話を強制的にセキュア モードにします。

IP 電話から TLS シグナリングを代行受信するために、TLS プロキシがセキュリティ アプライアンスに実装されます。

TLS プロキシは、パケットを復号化し NAT のリライトとプロトコルへの準拠のために検査エンジンにパケットを送信します。オプションでパケットを暗号化し、Cisco UCM に送信するか、IP 電話が Cisco UCM でノンセキュア モードになるよう設定されている場合はクリア テキストで送信します。

セキュリティ アプライアンスは、必要に応じてメディア ターミネータとして機能し、SRTP と RTPメディア ストリーム間の変換を行います。

TLS プロキシは、TLS クライアント、プロキシ(セキュリティ アプライアンス)、および TLS サーバ間の信頼関係の確立に基づいて機能する透過的なプロキシです。

Cisco Unified Mobility ソリューションでは、TLS クライアントは Cisco UMA クライアントで、TLS サーバは Cisco UMA サーバです。セキュリティ アプライアンスは、Cisco UMA クライアントと Cisco UMA サーバ間にあります。Cisco Unified Mobility のモビリティ プロキシ(TLS プロキシとして実装されます)によって、クライアントとのハンドシェイク中にサーバ プロキシのインポート済みの PKCS-12 証明書を使用できます。ハンドシェイク中に証明書(クライアント認証ではない)を提示するために Cisco UMA クライアントは必要ありません。

Cisco Unified Presence ソリューションでは、セキュリティ アプライアンスは、Cisco UP サーバと外部サーバ間の TLS プロキシとして機能します。これによって、セキュリティ アプライアンスは、TLS 接続を開始するサーバの代わりに TLS メッセージをプロキシして、プロキシした TLS メッセージをクライアントにルーティングできます。セキュリティ アプライアンスは、サーバとクライアントの証明書トラストポイントを保存して、TLS セッションの確立時にこれらの証明書を提示します。

Cisco Unified Communications プロキシ機能のライセンス

セキュリティ アプライアンスでサポートされる Cisco Unified Communications プロキシ機能では、次のユニファイド コミュニケーション プロキシ ライセンスが必要です。

フォン プロキシ

暗号化音声検査の TLS プロキシ

モビリティ プロキシ

プレゼンス フェデレーション プロキシ

ユニファイド コミュニケーション プロキシ機能は、TLS セッションによってライセンスされます。フォン プロキシまたは TLS プロキシでは、それぞれの IP 電話では、Cisco UCM サーバへの単一の接続または 2 つの接続(プライマリ Cisco UCM への接続が 1 つと、バックアップ Cisco UCM への接続が 1 つ)を確立できます。2 番目のシナリオでは、2 つの TLS セッションが設定されているため、フォン プロキシは 2 つの Unified Communications プロキシ セッションを使用します。モビリティ プロキシとプレゼンス フェデレーション プロキシでは、それぞれのエンドポイントは、ユニファイド コミュニケーション プロキシ セッションを 1 つ使用します。

表 27-2 に、プラットフォーム別のユニファイド コミュニケーション プロキシ ライセンスの詳細を示します。

 

表 27-2 セキュリティ アプライアンスのライセンス要件

セキュリティ アプライアンスのプラットフォーム
UC プロキシ ライセンスの最大数
UC プロキシ ライセンスのティア

ASA 5505

24

24

ASA 5510

100

24, 50, 100

ASA 5520

1,000

24, 50, 100, 250, 500, 750, 1000

ASA 5540

2,000

24, 50, 100, 250, 500, 750, 1000, 2000

ASA 5550

3,000

24, 50, 100, 250, 500, 750, 1000, 2000, 3000

ユニファイド コミュニケーション プロキシ ライセンスは、 activation-key コマンドを使用して、ライセンスを取得した他の機能(SSL VPN など)と同じ方法で適用されます。セキュリティ アプライアンスでライセンスを確認するには、 show version コマンドまたは show activation-key コマンドを使用します。

hostname# show activation-key
Serial Number: P3000000179
Running Activation Key: 0xa700d24c 0x98caab35 0x88038550 0xaf383078 0x02382080
 
Licensed features for this platform:
Maximum Physical Interfaces : Unlimited
Maximum VLANs : 150
Inside Hosts : Unlimited
Failover : Active/Active
VPN-DES : Enabled
VPN-3DES-AES : Enabled
Security Contexts : 10
GTP/GPRS : Enabled
VPN Peers : 750
WebVPN Peers : 750
AnyConnect for Mobile : Disabled
AnyConnect for Linksys phone : Disabled
Advanced Endpoint Assessment : Enabled
UC Proxy Sessions : 1000
This platform has an ASA 5520 VPN Plus license.
 
The flash activation key is the SAME as the running key.
hostname#
 

ライセンスの追加情報については、次のリンクを参照してください。Cisco.com の登録ユーザである場合に、ユニファイド コミュニケーション プロキシ ライセンスを取得するには、次の Web サイトにアクセスしてください。

http://www.cisco.com/go/license

Cisco.com の登録ユーザ以外の場合は、次の Web サイトにアクセスしてください。

https://tools.cisco.com/SWIFT/Licensing/RegistrationServlet

名前、E メール アドレス、およびセキュリティ アプライアンスのシリアル番号を show version コマンド出力で表示されたとおりに指定します。

フォン プロキシ

この項は、次の内容で構成されています。

「フォン プロキシの概要」

「フォン プロキシ設定」

「フォン プロキシのトラブルシューティング」

フォン プロキシの概要

セキュリティ アプライアンスのフォン プロキシは、信頼できないネットワーク上のリモート電話からのデータを強制的に暗号化することによって、企業の IP テレフォニー ネットワークとインターネット間の IP テレフォニーをセキュアな方法でブリッジングします。図 27-1 に示されているように、在宅勤務者は、フォン プロキシを介してインターネットで自分の IP 電話を企業の IP テレフォニー ネットワークに安全に接続できるため、VPN トンネルで接続する必要がありません。

図 27-1 フォン プロキシのセキュアな配置

 

 

フォン プロキシでは、混合モードまたはノンセキュア モードで Cisco UCM クラスタがサポートされます。クラスタ モードに関係なく、暗号化を行うことができるリモート電話は、常に強制的に暗号化モードになります。TLS(シグナリング)と SRTP(メディア)は、常にセキュリティ アプライアンスで終端されます。セキュリティ アプライアンスは、NAT の実行、メディアのピンホールのオープン、および SCCP プロトコルと SIP プロトコルの検査ポリシーの適用も行うことができます。電話がノンセキュアとして設定されているノンセキュア クラスタ モードまたは混合モードでは、フォン プロキシは次の方法で動作します。

電話機からの TLS 接続はセキュリティ アプライアンスで終了し、Cisco UCM に対する TCP 接続が開始されます。

セキュリティ アプライアンス経由で外部 IP 電話から内部ネットワーク IP 電話に送信された SRTP は、RTP に変換されます。

内部 IP 電話が認証済みとして設定された混合モードのクラスタでは、TLS 接続は、Cisco UCM への TCP には変換されませんが、SRTP は RTP に変換されます。

内部 IP 電話が暗号化済みとして設定されている混合モードのクラスタでは、TLS 接続は Cisco UCM への TLS 接続のままになり、リモート電話からの SRTP は内部 IP 電話への SRTP のままになります。

フォン プロキシの主な目的は、ノンセキュア クラスタへのコールの発信中に電話を安全に動作させることであるため、フォン プロキシは、次の主な機能を実行します。

Certificate Trust List(CTL; 証明書信頼リスト)ファイルを作成します。これは、リモート電話で証明書ベースの認証を実行するために使用されます。

TFTP を介して要求された場合に、IP 電話のコンフィギュレーション ファイルを修正し、セキュリティ フィールドをノンセキュアからセキュアに変更して、電話に送信されるすべてのファイルに署名します。これらの修正は、電話に暗号化されたシグナリングとメディアを強制的に実行させることによって、リモート電話を保護します。

電話からの TLS シグナリングを終端して、Cisco UCM への TCP または TLS を開始します。

Skinny と SIP シグナリング メッセージを変更することによって、メディア パスに自身を挿入します。

SRTP を終端して、受信側への RTP または SRTP を開始します。


) TLS ハンドシェイクによってリモート IP 電話を認証する別の方法として、LSC プロビジョニングによる認証を設定することもできます。LSC プロビジョニングを使用して、リモート IP 電話ユーザごとにパスワードを作成して、各ユーザが、リモート IP 電話でそのパスワードを入力して LSC を取得します。

LSC プロビジョニングを使用してリモート IP 電話を認証する場合は最初に IP 電話をノンセキュア モードで登録する必要があるため、シスコでは、エンド ユーザに IP 電話を提供する前に、企業ネットワーク内で LSC プロビジョニングを行うことを推奨します。そうしないと、IP 電話をノンセキュア モードで登録する場合に、管理者はセキュリティ アプライアンスで SIP と SCCP のノンセキュア シグナリング ポートを開かなければなりません。

「例 5:Publisher での混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバでの LSC プロビジョニング」を参照してください。Certificate Authority Proxy Function(CAPF; 認証局プロキシ関数)を使用した Locally Significant Certificate(LSC; ローカルで有効な証明書)のインストールについては、『Cisco Unified Communications Manager Security Guide』も参照してください。


フォン プロキシの制限事項

フォン プロキシには、次の制限事項があります。

フォン プロキシは、マルチ コンテキスト モードではサポートされません。

フォン プロキシでは、VPN トンネルを介してフォン プロキシに接続されている電話からのパケットの検査はサポートされていません。そのため、VPN トンネルを介したフォン プロキシ トラフィックの送信はサポートされません。セキュリティ アプライアンスでフォン プロキシ機能を設定すると、そのトラフィックを VPN トンネルを通過させることなく IP 電話を企業ネットワークに接続できます。

フォン プロキシでは、記録トラフィックが記録デバイスに到達するためにセキュリティ アプライアンスを通過しなければならない場合、記録コールはサポートされません。たとえば、Unified Communication Manager バージョン 6.x と 7.x では、フォーク機能を備えたサードパーティの記録デバイスの使用がサポートされます。フォン プロキシで記録機能を使用する場合は、この機能によって、オリジナルの RTP メディア ストリームのコピーである 2 番目の RTP メディア ストリームが作成されます。外部の IP 電話からセキュリティ デバイスの背後にある記録デバイスへの RTP メディア ストリームが 2 つ存在すると、IP 電話の音声が中断されます。

セキュリティ アプライアンスでは、フォン プロキシのステートフル フェールオーバーは次の方法でサポートされます。アクティブ装置がダウンすると、フォン プロキシを通過する IP 電話からのコールは失敗し、メディアのフローは停止します。また、故障した装置から IP 電話を登録解除して、アクティブ装置に再登録する必要があります。その後、コールを再確立する必要があります。

セキュリティ アプライアンスが透過モードまたはマルチモードで稼動している場合、フォン プロキシはサポートされません。

フォン プロキシでは、Secure Real-Time Protocol(SRTP)をネイティブに使用する内部 IP 電話との通信はサポートされません。

フォン プロキシは、セキュリティ アプライアンスから Real-Time Control Protocol(RTCP)パケットを送信する IP 電話をサポートしていません。Cisco Unified CM 管理コンソールの [Phone Configuration] ページで RTCP パケットをディセーブルにしてください。この設定オプションの設定については、Cisco Unified Communications Manager(CallManager)のマニュアルを参照してください。

フォン プロキシは、CIPC とともに使用する場合、エンド ユーザが CIPC でデバイス名をリセットしたり([Preferences] > [Network] タブ > [Use this Device Name] フィールド)、管理者が Cisco Unified CM 管理コンソールでデバイス名をリセットしたりする([Device] メニュー > [Phone Configuration] > [Device Name] フィールド)ことをサポートしていません。フォン プロキシで機能するには、CIPC コンフィギュレーション ファイルの形式を SEP<mac_address>.cnf.xml にする必要があります。デバイス名がこの形式(SEP<mac_address>)に従っていない場合は、CIPC は、フォン プロキシ経由で Cisco UMC からコンフィギュレーション ファイルを取得できず、CIPC が機能しません。

フォン プロキシでは、Cisco VT Advantage を使用して SCCP ビデオ メッセージを送信する IP 電話はサポートされません。これは、SCCP ビデオ メッセージが SRTP キーをサポートしていないためです。

混合モードのクラスタでは、フォン プロキシは、セキュリティ アプライアンス経由で暗号化されたコンフィギュレーション ファイルを IP 電話に送信するために、TFTP を使用する Cisco Unified Call Manager をサポートしません。

CIPC が遠隔地にあるコンピュータにインストールされている場合は、フォン プロキシと CIPC はサポートされません。これらのコンピュータからのコールはインターネットを通過し、セキュリティ アプライアンスで終了して、適応型セキュリティ アプライアンスの背後のネットワーク上にある IP 電話に到達します。セキュリティ アプライアンスの背後にある IP 電話に到達するには、CIPC がインストールされているコンピュータがネットワーク上になければなりません。

1 つの NAT デバイスの背後にある複数の IP 電話は、同じセキュリティ モードを使用するよう設定する必要があります。

フォン プロキシが混合モードのクラスタに対して設定されていて、複数の IP 電話が 1 つの NAT デバイスの背後にあってフォン プロキシから登録している場合は、SIP 電話と SCCP IP 電話はすべて、認証済みまたは暗号化済みとして設定するか、すべて Unified Call Manager でノンセキュアとして設定する必要があります。

たとえば、1 つの NAT デバイスの背後に 4 台の IP 電話(2 台の IP 電話が SIP を使用して設定され、2 台の IP 電話が SCCP を使用して設定されている)がある場合は、Unified Call Manager では次の設定が可能です。

2 台の SIP IP 電話:認証済みモードの IP 電話が 1 台と暗号化済みモードの IP 電話が 1 台、両方とも認証済みモード、または両方とも暗号化済みモード

2 台の SCCP IP 電話:認証済みモードの IP 電話が 1 台と暗号化済みモードの IP 電話が 1 台、両方とも認証済みモード、または両方とも暗号化済みモード

2 台の SIP IP 電話:両方ともノンセキュア モード

2 台の SCCP IP 電話:認証済みモードの IP 電話が 1 台と暗号化済みモードの IP 電話が 1 台、両方とも認証済みモード、両方とも暗号化済みモード

2 台の SIP IP 電話:認証済みモードの IP 電話が 1 台と暗号化済みモードの IP 電話が 1 台、両方とも認証済みモード、両方とも暗号化済みモード

2 台の SCCP IP 電話:両方ともノンセキュア モード

この制限は、アプリケーションのリダイレクト規則(TLS を TCP に変換する規則)が IP 電話について作成される方法によって生じます。

フォン プロキシ設定

この項は、次の内容で構成されています。

「設定の前提条件」

「7960 および 7940 IP 電話をサポートするための要件」

「複数のインターフェイスにおける IP 電話のアドレッシングの要件」

「フォン プロキシでサポートされる Cisco UCM と IP 電話」

「エンド ユーザの電話のプロビジョニング」

「ノンセキュア Cisco UCM クラスタでのフォン プロキシの設定」

「Cisco UCM からの証明書のインポート」

「混合モードの Cisco UCM クラスタでのフォン プロキシの設定」

「Cisco IP Communicator のフォン プロキシ設定」

「UDP ポート転送用に Linksys ルータを設定」

「レート制限 TFTP 要求の概要」

「メディア終端アドレス宛の ICMP トラフィックの概要」

設定の前提条件

フォン プロキシを設定する前に、セキュリティ アプライアンスが次の設定要件を満たしていることを確認してください。

セキュリティ アプライアンスには、次の基準を満たす、メディア終端の IP アドレスが指定されている必要があります。

IP アドレスは、セキュリティ アプライアンスの外部ネットワーク インターフェイスに関連付けられたアドレス範囲内の未使用の IP アドレスである、パブリックにルーティング可能なアドレスです。

IP アドレスは、セキュリティ アプライアンス上のインターフェイスの同一アドレスにはできません。これには、リモート IP 電話の接続先であるセキュリティ アプライアンス上の外部インターフェイスの IP アドレスの使用が含まれます。

IP アドレスは、既存のスタティック NAT プールまたは NAT 規則と重複できません。

IP アドレスは、Cisco UCM または TFTP サーバの IP アドレスと同じにはできません。

ルータまたはゲートウェイの背後にある IP 電話の場合は、電話がメディア終端アドレスに到達できるように、ルータまたはゲートウェイでメディア終端アドレスにルートを追加します。


) 組織のセキュリティ ポリシーで、内部ネットワーク上の IP 電話に外部ネットワークへのルートを指定できないことが指示されている場合は、内部ネットワーク上にある Unified Communications 認識の NAT デバイスを使用することをお勧めします。内部ネットワーク アドレスの範囲内にあるアドレスでメディア終端アドレスを表すことによって、内部 IP 電話を外部ルートに公開する必要がなくなります。


TFTP サーバは、Cisco UCM と同じインターフェイス上に存在している必要があります。

IP アドレスではなく Fully Qualified Domain Name(FQDN; 完全修飾ドメイン名)を Cisco UCM に対して設定している場合は、セキュリティ アプライアンスで DNS lookup を設定してイネーブルにする必要があります。 dns domain-lookup コマンドと、このコマンドを使用した DNS lookup の設定方法については、『 Cisco Security Appliance Command Reference 』を参照してください。

DNS lookup の設定後に、セキュリティ アプライアンスが、設定済みの FQDN で Cisco UCM に ping を実行できることを確認します。

CAPF サービスがイネーブルになっていて、Cisco UCM が Publisher で実行されていない場合に、Publisher が IP アドレスではなく FQDN を使用して設定されているときは、DNS lookup も設定する必要があります。

TFTP 要求を許可するようにアクセス リスト規則を設定する必要があります。

表 27-3 に、セキュリティ アプライアンスで TFTP に対して設定する必要があるアクセス リスト規則をリストします。

 

表 27-3 TFTP のアクセス リスト規則

アドレス
ポート
プロトコル
説明

TFTP サーバ

69

UDP

着信 TFTP を許可する


) 3804 は、CAPF サービスのデフォルト値です。このデフォルト値は、Cisco UCM で変更されている場合は変更する必要があります。NAT が TFTP サーバまたは Cisco UCM に対して設定されている場合は、変換された「グローバル」アドレスをアクセス リストで使用する必要があります。


セキュリティ アプライアンスでのアクセス リストの設定については、「アクセス リストの概要」を参照してください。

フォン プロキシが、既存のファイアウォールの背後に導入されている場合は、フォン プロキシへのシグナリング、TFTP、およびメディア トラフィックを許可するアクセス リスト規則を設定する必要があります。Cisco UCM で NAT が必要な場合は、既存のファイアウォールではなくセキュリティ アプライアンスで設定する必要があります。

表 27-4 に、既存のファイアウォールで設定する必要があるポートをリストします。

 

表 27-4 ポートの設定要求

アドレス
ポート
プロトコル
説明

メディア終端

1024 ~ 65535

UDP

着信 SRTP を許可する

TFTP サーバ

69

UDP

着信 TFTP を許可する

Cisco UCM

2443

TCP

着信セキュア SCCP を許可する

Cisco UCM

5061

TCP

着信セキュア SIP を許可する

CAPF サービス(Cisco UCM 上)

3804

TCP

LSC プロビジョニング用に CAPF サービスを許可する


) TFTP を除くこれらすべてのポートを Cisco UCM で設定できます。これらはデフォルト値であり、Cisco UCM で変更されている場合は変更が必要です。NAT が TFTP サーバまたは Cisco UCM に対して設定されている場合は、変換された「グローバル」アドレスをアクセス リストで使用する必要があります。


NAT が TFTP サーバに対して設定されている場合は、フォン プロキシで tftp-server コマンドを設定する前に、NAT 設定を行う必要があります。

Cisco UCM は内部のプライベート ネットワーク上に配置できますが、パブリックにルーティング可能なアドレスに対する、セキュリティ アプライアンス上の Cisco UCM のスタティック マッピングが必要です。

フォン プロキシでは、次の PAT 設定要件を満たす必要があります。

Skinny 検査のグローバル ポートがデフォルト以外のポートを使用するよう設定されている場合は、ノンセキュア ポートに global_sccp_port+443 を設定する必要があります。

そのため、 global_sccp_port が 7000 の場合は、グローバル セキュア SCCP ポートは 7443 です。フォン プロキシの配置に複数の Cisco UCM があり、インターフェイス IP アドレスまたはグローバル IP アドレスを共有する必要がある場合は、ポートの再設定が必要になる可能性があります。

/* use the default ports for the first CUCM */
static (inside,outside) tcp interface 2000 10.0.0.1 2000
static (inside,outside) tcp interface 2443 10.0.0.1 2443
/* use non-default ports for the 2nd CUCM */
static (inside,outside) tcp interface 7000 10.0.0.2 2000
static (inside,outside) tcp interface 7443 10.0.0.2 2443
 

) ノンセキュア ポートとセキュア ポートの両方の PAT 設定を行う必要があります。


IP 電話が Cisco UCM 上の CAPF と接続する必要がある場合に、Cisco UCM がスタティック PAT(LCS プロビジョニングが必要)を使用して設定されているときは、デフォルトの CAPF ポート 3804 のスタティック PAT を設定する必要があります。

7960 および 7940 IP 電話をサポートするための要件

フォン プロキシで 7960 および 7940 IP 電話をサポートするには、次の要件を満たす必要があります。

MIC とともに事前インストールされないため、これらの IP 電話に LSC をインストールする必要があります。ノンセキュア モードで Cisco UCM に登録する目的で IP 電話のノンセキュア SCCP ポートを開かずにすむように、フォン プロキシで使用する前に各電話に LSC をインストールします。

IP 電話に LSC をインストールする手順については、次のドキュメントを参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/security/7_0_1/secugd/secucapf.html#wp1093518


) IP 電話に別の Cisco UCM クラスタから LSC がすでにインストールされている場合は、別のクラスタから LSC を削除して、現在の Cisco UCM クラスタから LSC をインストールします。


CAPF 証明書をセキュリティ アプライアンスにインポートする必要があります。

セキュリティ アプライアンスで作成される CTL ファイルは、CAPF レコードエントリで作成する必要があります。

電話は、SCCP プロトコルだけを使用するように設定する必要があります。SIP プロトコルは、これらの IP 電話で暗号化をサポートしていないためです。

フォン プロキシによって LSC プロビジョニングを行う場合は、ノンセキュア ポート 2000 で IP 電話を Cisco UCM に登録できるようにする ACL を追加する必要があります。

複数のインターフェイスにおける IP 電話のアドレッシングの要件

IP 電話が複数のインターフェイスにある場合は、フォン プロキシ設定では、CTL ファイルに Cisco UCM の正しい IP アドレスが指定されている必要があります。

IP アドレスを正しく設定する方法については、次の例のトポロジを参照してください。

phones --- (dmz)-----|
|----- ASA PP --- (outside Internet) --- phones
phones --- (inside)--|
 

この例のトポロジでは、次の IP アドレスを設定します。

内部インターフェイスの Cisco UCM は 10.0.0.5 に設定します。

DMZ ネットワークは 192.168.1.0/24 です。

内部ネットワークは 10.0.0.0/24 です。

Cisco UCM は、DMZ > 外部および内部インターフェイス > 外部インターフェイスから異なるグローバル IP アドレスでマップされます。

2 つの異なる IP アドレスが原因で、CTL ファイルでは、Cisco UCM に 2 つのエントリが指定されている必要があります。たとえば、Cisco UCM の static 文は次のとおりです。

static (inside,outside) 128.106.254.2 10.0.0.5
static (inside,dmz) 192.168.1.2 10.0.0.5
 

Cisco UCM の 2 つの CTL ファイル レコード エントリが必要です。

record-entry cucm trustpoint cucm_in_to_out address 128.106.254.2
record-entry cucm trustpoint cucm_in_to_dmz address 192.168.1.2

フォン プロキシでサポートされる Cisco UCM と IP 電話

Cisco Unified Communications Manager

フォン プロキシでは、次のリリースの Cisco Unified Communications Manager がサポートされます。

Cisco Unified CallManager バージョン 4.x

Cisco Unified CallManager バージョン 5.x

Cisco Unified Communications Manager 6.x

Cisco Unified Communications Manager 7.x

Cisco Unified IP Phones

フォン プロキシでは、Cisco Unified IP Phones 7900 シリーズの次の IP 電話がサポートされます。

Cisco Unified IP Phone 7975

Cisco Unified IP Phone 7971

Cisco Unified IP Phone 7970

Cisco Unified IP Phone 7965

Cisco Unified IP Phone 7962

Cisco Unified IP Phone 7961

Cisco Unified IP Phone 7961G-GE

Cisco Unified IP Phone 7960(SCCP プロトコル サポートだけ)

Cisco Unified IP Phone 7945

Cisco Unified IP Phone 7942

Cisco Unified IP Phone 7941

Cisco Unified IP Phone 7941G-GE

Cisco Unified IP Phone 7940(SCCP プロトコル サポートだけ)

Cisco Unified Wireless IP Phone 7921

ソフトフォン用 CIPC(認証済みモードが指定された CIPC バージョンだけ)


) Cisco IP Communicator は、認証済み TLS モードのフォン プロキシ VLAN トラバーサルでサポートされます。


CIPC が遠隔地にあるコンピュータにインストールされている場合は、フォン プロキシと CIPC はサポートされません。これらのコンピュータからのコールはインターネットを通過し、セキュリティ アプライアンスで終了して、適応型セキュリティ アプライアンスの背後のネットワーク上にある IP 電話に到達します。セキュリティ アプライアンスの背後にある IP 電話に到達するには、CIPC がインストールされているコンピュータがネットワーク上になければなりません。

エンド ユーザの電話のプロビジョニング

フォン プロキシは、TFTP とシグナリング トランザクションに関して透過的なプロキシです。Cisco UCM TFTP サーバの NAT が設定されていない場合は、電話は Cisco UCM クラスタ TFTP サーバのアドレスを使用して設定する必要があります。

Cisco UCM TFTP サーバの NAT が設定されている場合は、Cisco UCM TFTP サーバのグローバル アドレスが電話での TFTP サーバのアドレスとして設定されます。

オプション 1(推奨):企業の本社にある IP 電話をエンド ユーザに送信する前にステージングする。

電話はネットワーク内で登録します。IT によって、電話の設定、イメージのダウンロード、および登録に問題がないことを確認します。

Cisco UCM クラスタが混合モードになっていた場合は、電話をエンド ユーザに送信する前に CTL ファイルを消去する必要があります。

このオプションの利点は次のとおりです。

• 電話が Cisco UCM に登録されていて機能しているかどうかがわかるため、ネットワークまたはフォン プロキシの問題のトラブルシューティングと分離が容易になります。

• 電話がブロードバンド接続を介してファームウェアをダウンロードする必要がないため、ユーザ エクスペリエンスが向上します。ブロードバンド接続は低速で、ユーザが長時間待機しなければならないことがあります。

オプション 2:新しい電話をエンド ユーザに送信する。

適切な Cisco UCM と TFTP サーバの IP アドレスを使用して電話で設定を変更するための指示をユーザに出す必要があります。

どちらのオプションでも、NAT 機能を使用して市販のケーブルまたは DSL ルータの背後にリモート IP 電話を設置することがサポートされます。


) TLS ハンドシェイクによってリモート IP 電話を認証する別の方法として、LSC プロビジョニングによる認証を設定することもできます。LSC プロビジョニングを使用して、リモート IP 電話ユーザごとにパスワードを作成して、各ユーザが、リモート IP 電話でそのパスワードを入力して LSC を取得します。

LSC プロビジョニングを使用してリモート IP 電話を認証する場合は最初に IP 電話をノンセキュア モードで登録する必要があるため、シスコでは、エンド ユーザに IP 電話を提供する前に、企業ネットワーク内で LSC プロビジョニングを行うことをお勧めします。そうしないと、IP 電話をノンセキュア モードで登録する場合に、管理者はセキュリティ アプライアンスで SIP と SCCP のノンセキュア シグナリング ポートを開かなければなりません。

「例 5:Publisher での混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバでの LSC プロビジョニング」を参照してください。認証局プロキシ関数(CAPF)を使用したローカルで有効な証明書(LSC)のインストールについては、『Cisco Unified Communications Manager Security Guide』も参照してください。


ノンセキュア Cisco UCM クラスタでのフォン プロキシの設定


ステップ 1 トラストポイントを作成して、IP 電話が信頼する必要があるネットワーク上のエンティティ(Cisco UCM、Cisco UCM と TFTP、TFTP サーバ、CAPF)ごとに証明書を生成します。証明書は、CTL ファイルの作成時に使用されます。

各 Cisco UCM(セカンダリ Cisco UCM を使用する場合はプライマリとセカンダリ)と、ネットワーク上の TFTP サーバ用のトラストポイントを作成する必要があります。Cisco UCM を信頼するには、トラストポイントが電話の CTL ファイルに存在している必要があります。

a. 次のコマンドを入力して、トラストポイントに使用できるキー ペアを作成します。

hostname(config)# crypto key generate rsa label key-pair-label modulus size
 

b. 次のコマンドを入力して、Cisco UCM(プライマリとセカンダリ)ごとにトラストポイントを作成します。

hostname(config)# crypto ca trustpoint trustpoint_name
hostname(config-ca-trustpoint)# enrollment self
hostname(config-ca-trustpoint)# keypair keyname
hostname(config-ca-trustpoint)# exit
hostname(config)# crypto ca enroll trustpoint
 

これらのコマンドを入力すると、自己署名証明書が生成され、公開キーが認証の対象となっているキー ペアが指定されます。これは、ステップ a. で作成したキー ペアです。 crypto ca enroll コマンドを入力すると、CA サーバから証明書が要求され、セキュリティ アプライアンスで証明書が生成されます。

c. 次のコマンドを入力して、TFTP サーバのトラストポイントを作成します。

hostname(config)# crypto ca trustpoint trustpoint_name
hostname(config-ca-trustpoint)# enrollment self
hostname(config-ca-trustpoint)# keypair keyname
hostname(config-ca-trustpoint)# exit
hostname(config)# crypto ca enroll trustpoint
 

) この手順を実行する必要があるのは、TFTP サーバが Cisco UCM とは別のサーバにある場合だけです。この設定の例については、「例 3:別のサーバでの混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバ」を参照してください。


d. サブジェクト名にデバイスのシリアル番号を含めるように求めるプロンプトが表示されたら、シリアル番号を含める場合は Y 、除外する場合は N を入力します。

e. 自己署名証明書を生成するように求めるプロンプトが表示されたら、 Y を入力します。

f. Cisco UCM に保存されている次の証明書をインポートします。これらの証明書は、フォン プロキシ用にセキュリティ アプライアンスで必要です。

Cisco_Manufacturing_CA

CAP-RTP-001

CAP-RTP-002

「Cisco UCM からの証明書のインポート」を参照してください。たとえば、IP 電話の証明書を検証するには、フォン プロキシで CA 製造業者の証明書が必要です。

g. (オプション)LSC プロビジョニングが必要であるか、LSC 対応の IP 電話がある場合は、Cisco UCM から CAPF 証明書をインポートする必要があります。「Cisco UCM からの証明書のインポート」を参照してください。


) Cisco UCM に複数の CAPF 証明書がある場合は、すべてセキュリティ アプライアンスにインポートする必要があります。


ステップ 2 TFTP の使用中に IP 電話に提示される CTL ファイルを作成します。ここでの address は、TFTP サーバまたは Cisco UCM(NAT が設定されている場合)の変換済みアドレスまたはグローバル アドレスでなければなりません。

a. Cisco UCM と TFTP サーバのドメイン名を使用する場合は、セキュリティ アプライアンスで DNS lookup を設定する必要があります。セキュリティ アプライアンス上にある各外部インターフェイスのエントリを DNS サーバに追加します(これらのエントリがすでに存在しない場合)。それぞれのセキュリティ アプライアンス外部 IP アドレスにはルックアップ用に関連付けられている DNS エントリが含まれている必要があります。これらの DNS エントリは、逆ルックアップに対してもイネーブルになっている必要があります。 dns domain-lookup interface_name コマンド( interface_name は、DNS サーバへのルートがあるインターフェイスを指定します)を使用して、セキュリティ アプライアンスで DNS lookup をイネーブルにします。さらに、セキュリティ アプライアンス上の DNS サーバ IP アドレスを定義します。たとえば、 dns name-server 10.2.3.4 (ご使用の DNS サーバの IP アドレス)です。


) 複数のインターフェイスで DNS lookup をイネーブルにするには、dns domain-lookup コマンドを複数回入力します。複数のコマンドを入力すると、セキュリティ アプライアンスは、応答を受信するまで、設定に表示される順序で各インターフェイスを試行します。


b. 次のコマンドを入力して、CTL ファイル インスタンスを作成します。

hostname(config)# ctl-file ctl_name
 

c. 次のコマンドを入力して、TFTP サーバのレコード エントリを作成します。TFTP サーバのグローバルまたはマッピング IP アドレスを使用します。

hostname(config-ctl-file)# record-entry tftp trustpoint trustpoint_name address TFTP_IP_address
 

d. 次のコマンドを入力して、Cisco UCM(プライマリとセカンダリ)ごとにレコード エントリを作成します。Cisco UCM のグローバルまたはマッピング IP アドレスを使用します。

hostname(config-ctl-file)# record-entry cucm trustpoint trustpoint_name address IP_address
 

e. (オプション)LSC プロビジョニングが必要であるか、LSC 対応の IP 電話がある場合は、次のコマンドを入力して、CAPF のレコード エントリを作成します。

hostname(config-ctl-file)# record-entry capf trustpoint trust_point address
 

f. 次のコマンドを入力して、CTL ファイルを作成します。

hostname(config-ctl-file)# no shutdown
 

ファイルの作成時に、フォン プロキシが TFTP ファイルに署名するために使用する内部トラストポイントが作成されます。トラストポイントの名前は _internal_PP_ ctl-instance_filename です。

g. 次のコマンドを入力して、証明書の設定をフラッシュ メモリに保存します。

hostname(config)# copy running-configuration startup-configuration
 

ステップ 3 暗号化されたシグナリングを処理するための TLS プロキシ インスタンスを作成します。

a. 次のコマンドを入力して、TLS プロキシ インスタンスを作成します。

hostname(config)# tls-proxy proxy_name
 

b. サーバのトラストポイントを設定して、 _internal_PP _ctl-instance_filename という名前の内部トラストポイントを参照します。

hostname(config-tlsp)# server trust-point _internal_PP_ctl-instance_filename
 

ステップ 4 フォン プロキシ インスタンスを設定します。

a. CTL ファイル インスタンスを作成します。

hostname(config)# phone-proxy phone_proxy_name
 

b. 次のコマンドを入力して、SRTP と RTP のフォン プロキシで使用されるメディア終端アドレスを設定します。

hostname(config-phone-proxy)# media-termination address ip_address

) • メディア終端アドレスについては、ネットワーク上の別のデバイスによって使用されることがなく、セキュリティ アプライアンス インターフェイスに接続された外部ネットワーク上にある未使用の IP アドレスである、パブリックにルーティング可能な IP アドレスを選択する必要があります。

特に、メディア終端アドレスは、セキュリティ アプライアンス インターフェイスの IP アドレスと同じにはできず、既存のスタティック NAT 規則と重複することはできません。さらに、Cisco UCM または TFTP サーバの IP アドレスと同じにすることもできません。

ルータまたはゲートウェイの背後にある IP 電話の場合は、電話がメディア終端アドレスに到達できるように、ルータまたはゲートウェイでメディア終端アドレスにルートを追加します。


 

c. 実際の内部アドレスを使用して TFTP サーバを作成し、次のコマンドを入力して TFTP サーバがあるインターフェイスを指定します。

hostname(config-phone-proxy)# tftp-server address ip_address interface interface
 

d. 次のコマンドを入力して、ステップ 3 で作成した TLS プロキシ インスタンスを設定します。

hostame(config-phone-proxy)# tls-proxy proxy_name
 

e. 次のコマンドを入力して、ステップ 2 で作成した CTL ファイル インスタンスを設定します。

hostname(config-phone-proxy)# ctl-file ctl_name
 

f. (オプション)稼動環境に、IP 電話がすべての HTTP 要求を送信する先である外部 HTTP 要求がある場合は、次のコマンドを入力して、セキュリティ アプライアンスでプロキシ サーバを設定します。

hostname(config-phone-proxy)# proxy-server address ip_address [listen_port] interface ifc
 

フォン プロキシの使用中に設定できるプロキシ サーバは 1 つだけです。ただし、プロキシ サーバの設定後に IP 電話でコンフィギュレーション ファイルをすでにダウンロードしている場合は、IP 電話が、ファイル内のプロキシ サーバ アドレスが示されたコンフィギュレーション ファイルを取得できるように IP 電話を再開する必要があります。

デフォルトでは、Enterprise パラメータで設定された Phone URL パラメータは URL で FQDN を使用します。HTTP プロキシの DNS lookup によって FQDN が解決されない場合は、IP アドレスを使用するようにパラメータを変更しなければならないことがあります。

g. (オプション)Cisco IP Communicator(CIPC)ソフトフォンが音声とデータ VLAN シナリオで配置されている場合に、CIPC ソフトフォンに強制的に認証済みモードで動作させるには、次のコマンドを入力します。

hostname(config-phone-proxy)# cipc security-mode authenticated
 

CIPC でのフォン プロキシの使用に関するすべての要件については、「Cisco IP Communicator のフォン プロキシ設定」を参照してください。

h. (オプション)設定済みの IP 電話ごとに、Cisco UCM で行った設定を保存するには、次のコマンドを入力します。

hostname(config-phone-proxy)# no disable service-settings
 

デフォルトでは、次の設定は IP 電話でディセーブルになっています。

PC Port

Gratuitous ARP

Voice VLAN access

Web Access

Span to PC Port

ステップ 5 SIP と Skinny 検査を使用してフォン プロキシをイネーブルにします。

a. 次のコマンドを入力して、検査するトラフィックのセキュア Skinny クラスを設定します。

hostname(config)# class-map class_map_name
hostname(config-cmap)# match port tcp eq 2443
 

class_map_name には、Skinny クラス マップの名前を指定します。

b. 次のコマンドを入力して、検査するトラフィックのセキュア SIP クラスを設定します。

hostname(config)# class-map class_map_name
hostname(config-cmap)# match port tcp eq 5061
 

class_map_name には、SIP クラス マップの名前を指定します。

c. 次のコマンドを入力して、ポリシー マップを設定して、トラフィックのクラスにアクションを添付します。

hostname(config)# policy-map name
hostname(config-pmap)# class classmap-name
hostname(config-pmap-c)# inspect skinny phone-proxy pp_name
hostnae(config-pmap)# class classmap-name
hostname(config-pmap-c)# inspect sip phone-proxy pp_name
 

classmap_name には、Skinny クラス マップの名前と SIP クラス マップの名前を指定します。

d. 次のコマンドを入力して、外部インターフェイスでポリシーをイネーブルにします。

hostname(config)# service-policy policymap_name interface intf
 


 

Cisco UCM からの証明書のインポート

フォン プロキシが TLS ハンドシェイクを正常に実行するために使用する TLS プロキシでは、IP 電話(および Cisco UCM で TLS を行う場合は Cisco UCM)からの証明書を検査する必要があります。IP 電話の証明書を検証するには、Cisco UCM に格納される CA 製造業者の証明書が必要です。CA 製造業者の証明書をセキュリティ アプライアンスにインポートするには、次の手順を実行します。


ステップ 1 Cisco UCM の [Operating System Administration] Web ページに移動します。

ステップ 2 [Security] > [Certificate Management] を選択します。


) 旧バージョンの Cisco UCM では、UI と証明書の検索方法が異なります。たとえば、Cisco UCM バージョン 4.x では、証明書はディレクトリ C:\Program Files\Cisco\Certificates にあります。証明書の検索については、Cisco Unified Communications Manager(CallManager)のマニュアルを参照してください。


ステップ 3 [Find] をクリックすると、すべての証明書が表示されます。

ステップ 4 ファイル名 Cisco_Manufacturing_CA を検索します。これは、IP 電話の証明書を検査するために必要な証明書です。.PEM ファイル Cisco_Manufacturing_CA.pem をクリックします。これによって、証明書情報と、証明書をダウンロードするためのオプションが示されたダイアログボックスが表示されます。


) 証明書リストに、ファイル名が Cisco_Manufacturing_CA の証明書が複数ある場合は、証明書 Cisco_Manufacturing_CA.pem(.pem ファイル拡張子がある証明書)を選択してください。


ステップ 5 [Download] をクリックして、ファイルをテキスト ファイルとして保存します。

ステップ 6 次のコマンドを入力して、セキュリティ アプライアンスで Cisco Manufacturing CA のトラストポイントを作成して、端末から登録します。ステップ 4 でダウンロードした証明書を貼り付けるため、端末から登録します。

hostname(config)# crypto ca trustpoint trustpoint_name
hostname(config-ca-trustpoint)# enrollment terminal
 

ステップ 7 次のコマンドを入力して、トラストポイントを認証します。

hostname(config)# crypto ca authenticate trustpoint
 

ステップ 8 「Enter the base 64 encoded CA Certificate」というプロンプトが表示されます。ステップ 4 でダウンロードした .PEM ファイルをコピーして、コマンドラインに貼り付けます。ファイルはすでに base-64 エンコードになっているため、変換は不要です。証明書に問題がない場合は、受け入れるように求めるプロンプト「Do you accept this certificate?[yes/no]」が表示されます。 yes と入力します。


) 証明書をコピーする際には、BEGIN と END を含む行も忘れずにコピーしてください。



ヒント 証明書に問題がある場合は、debug crypto ca コマンドを使用して、PKI のアクティビティ(CA で使用されます)に関するデバッグ メッセージを表示します。


ステップ 9 次の証明書でステップ 1 からステップ 8 を繰り返します。表 27-5 は、セキュリティ アプライアンスで必要な証明書を示しています。

 

表 27-5 フォン プロキシのセキュリティ アプライアンスで必要な証明書

証明書名
証明書を必要とする操作

CallManager

TLS ハンドシェイク中の Cisco UCM の認証。混合モードのクラスタだけで必要です。

Cisco_Manufacturing_CA

製造元でインストールされる証明書(MIC)がある IP 電話の認証。

CAP-RTP-001

MIC がある IP 電話の認証。

CAP-RTP-002

MIC がある IP 電話の認証。

CAPF

LSC がある IP 電話の認証。


 

混合モードの Cisco UCM クラスタでのフォン プロキシの設定

フォン プロキシを混合モードのクラスタで実行するよう設定するときは、次のオプションがあります。

クラスタが混合モードになっている場合は、ユーザは、既存の CTL ファイルを使用してトラストポイントをインストールするオプションを使用できます。

クラスタの CTL ファイルが存在する場合は、CTL ファイルをフラッシュ メモリにコピーして、その CTL ファイルから読み取るようセキュリティ アプライアンスを設定します。CTL ファイルをフラッシュ メモリにコピーする際は、ファイルに CTLFile.tlv という名前を付けないでください。


) 混合モードのクラスタでは、フォン プロキシは、セキュリティ アプライアンス経由で暗号化されたコンフィギュレーション ファイルを IP 電話に送信するために、TFTP を使用する Cisco Unified Call Manager をサポートしません。



ステップ 1 既存の CTL ファイルを使用して、IP 電話が信頼する必要があるネットワーク上のエンティティ(Cisco UCM、Cisco UCM と TFTP、TFTP サーバ、CAPF)ごとにトラストポイントをインストールします。エンティティの正しい IP アドレス(つまり、IP 電話が Cisco UCM または TFTP サーバに使用する IP アドレス)が記載されている既存の CTL ファイルがある場合は、そのファイルを使用して新しい CTL ファイルを作成できます。既存の CTL ファイルのコピーをフラッシュ メモリに格納して、 CTLFile.tlv 以外の名前に変更し、ステップ 2 に進みます。

または

次の手順を実行して、トラストポイントを作成して、IP 電話が信頼する必要があるネットワーク上のエンティティ(Cisco UCM、Cisco UCM と TFTP、TFTP サーバ、CAPF)ごとに証明書を生成します。

a. 次のコマンドを入力して、Cisco UCM(プライマリとセカンダリ)ごとにトラストポイントを作成します。

hostname(config)# crypto key generate rsa label keyname modulus 1024
hostname(config-ca-trustpoint)# enrollment self
hostname(config-ca-trustpoint)# keypair keyname
hostname(config-ca-trustpoint)# exit
hostname(config)# crypto ca enroll trustpoint
 

これらのコマンドを入力すると、自己署名証明書が生成され、公開キーが認証の対象となっているキー ペアが指定されます。これは、ステップ a. で作成したキー ペアです。 crypto ca enroll コマンドを入力すると、CA サーバから証明書が要求され、セキュリティ アプライアンスで証明書が生成されます。

b. 次のコマンドを入力して、TFTP サーバのトラストポイントを作成します。

hostname(config)# crypto ca trustpoint trustpoint_name
hostname(config-ca-trustpoint)# enrollment self
hostname(config-ca-trustpoint)# keypair keyname
hostname(config-ca-trustpoint)# exit
hostname(config)# crypto ca enroll trustpoint
 

) この手順を実行する必要があるのは、TFTP サーバが Cisco UCM とは別のサーバにある場合だけです。この設定の例については、「例 3:別のサーバでの混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバ」を参照してください。


c. サブジェクト名にデバイスのシリアル番号を含めるように求めるプロンプトが表示されたら、シリアル番号を含める場合は Y 、除外する場合は N を入力します。

d. 自己署名証明書を生成するように求めるプロンプトが表示されたら、 Y を入力します。

e. Cisco UCM に保存されている次の証明書をインポートします。これらの証明書は、フォン プロキシ用にセキュリティ アプライアンスで必要です。

CallManager

Cisco_Manufacturing_CA

CAP-RTP-001

CAP-RTP-002

「Cisco UCM からの証明書のインポート」を参照してください。たとえば、IP 電話の証明書を検証するには、フォン プロキシで CA 製造業者の証明書が必要です。

f. (オプション)LSC プロビジョニングが必要であるか、LSC 対応の IP 電話がある場合は、Cisco UCM から CAPF 証明書をインポートする必要があります。「Cisco UCM からの証明書のインポート」を参照してください。


) Cisco UCM に複数の CAPF 証明書がある場合は、すべてセキュリティ アプライアンスにインポートする必要があります。


ステップ 2 TFTP の使用中に電話に提示される CTL ファイルを作成します。ここでの address は、TFTP サーバまたは Cisco UCM(NAT が設定されている場合)の変換済みアドレスまたはグローバル アドレスでなければなりません。

a. Cisco UCM と TFTP サーバのドメイン名を使用する場合は、セキュリティ アプライアンスで DNS lookup を設定する必要があります。セキュリティ アプライアンス上にある各外部インターフェイスのエントリを DNS サーバに追加します(これらのエントリがすでに存在しない場合)。それぞれのセキュリティ アプライアンス外部 IP アドレスにはルックアップ用に関連付けられている DNS エントリが含まれている必要があります。これらの DNS エントリは、逆ルックアップに対してもイネーブルになっている必要があります。 dns domain-lookup interface_name コマンド( interface_name は、DNS サーバへのルートがあるインターフェイスを指定します)を使用して、セキュリティ アプライアンスで DNS lookup をイネーブルにします。さらに、セキュリティ アプライアンス上の DNS サーバ IP アドレスを定義します。たとえば、 dns name-server 10.2.3.4 (ご使用の DNS サーバの IP アドレス)です。


) 複数のインターフェイスで DNS lookup をイネーブルにするには、dns domain-lookup コマンドを複数回入力します。複数のコマンドを入力すると、セキュリティ アプライアンスは、応答を受信するまで、設定に表示される順序で各インターフェイスを試行します。


b. 次のコマンドを入力して、CTL ファイル インスタンスを作成します。

hostname(config)# ctl-file ctl_name
 

c. 既存の CTL ファイルを使用する場合は、次のコマンドを入力して、フラッシュ メモリに格納されている既存の CTL ファイルにすでに存在するトラストポイントを使用します。

hostname(config-ctl-file)# cluster-ctl-file filename_path
 

フラッシュ メモリに保存するときに、 CTLFile.tlv 以外のファイル名(たとえば、 old_ctlfile.tlv )を付けた既存の CTL ファイルを指定します。


) 新しい CTL ファイル インスタンスを作成している場合や、既存の CTL ファイルにさらにエントリを追加する必要がある場合は、この手順の残りの項目を実行します。


d. 次のコマンドを入力して、TFTP サーバのレコード エントリを作成します。

hostname(config-ctl-file)# record-entry tftp trustpoint trustpoint_name address TFTP_IP_address
 

e. 次のコマンドを入力して、Cisco UCM(プライマリとセカンダリ)ごとにレコード エントリを作成します。

hostname(config-ctl-file)# record-entry cucm trustpoint trustpoint_name address IP_address
 

f. (オプション)LSC プロビジョニングが必要であるか、LSC 対応の IP 電話がある場合は、次のコマンドを入力して、CAPF のレコード エントリを作成します。

hostname(config-ctl-file)# record-entry capf trustpoint trustpoint_name address IP_address
 

g. 次のコマンドを入力して、CTL ファイルを作成します。

hostname(config-ctl-file)# no shutdown
 

ファイルの作成時に、フォン プロキシが TFTP ファイルに署名するために使用する内部トラストポイントが作成されます。トラストポイントの名前は _internal_PP_ ctl-instance_filename です。

h. 次のコマンドを入力して、証明書の設定をフラッシュ メモリに保存します。

hostname(config)# copy running-configuration startup-configuration
 

ステップ 3 暗号化されたシグナリングを処理するための TLS プロキシ インスタンスを作成します。

混合モードのクラスタでは、暗号化済みとしてすでに設定されている IP 電話が存在することがあるため、Cisco UCM への TLS が必要です。TLS プロキシの LDC 発行元を設定する必要があります。次のいずれかの手順の詳細については、「暗号化音声検査の TLS プロキシ」を参照してください。

a. 次のコマンドを入力して、必要な RSA キー ペアを作成します。

hostname(config)# crypto key generate rsa label key-pair-label modulus size
hostname(config)# crypto key generate rsa label key-pair-label modulus size
 

ここで、 key-pair-label は、LDC 署名者のキーと IP 電話のキーです。

b. 次のコマンドを入力して、Cisco IP Phone の LDC に署名する内部ローカル CA を作成します。

hostname(config)# crypto ca trustpoint trustpoint_name
hostname(config-ca-trustpoint)# enrollment self
hostname(config-ca-trustpoint)# proxy-ldc-issuer
hostname(config-ca-trustpoint)# fqdn fqdn
hostname(config-ca-trustpoint)# subject-name X.500_name
hostname(config-ca-trustpoint)# keypair keypair
hostname(config)# crypto ca enroll ldc_server
 

ここで、 trustpoint-name fqdn X.500_name keypair 、および trustpoint は LDC 用です。

c. 次のコマンドを入力して、TLS プロキシ インスタンスを作成します。

hostname(config)# tls-proxy proxy_name
hostname(config-tlsp)# server trust-point _internal_PP_ctl-instance_filename
hostname(config-tlsp)# client ldc issuer ca_tp_name
hostname(config-tlsp)# client ldc keypair key_label
hostname(config-tlsp)# client cipher-suite cipher-suite
 

ここで、 ca_tp_name には、クライアント ダイナミック証明書を発行するローカル CA トラストポイントを指定し、 key_label には、クライアント ダイナミック証明書によって使用される RSA キー ペアを指定します。

d. 次のいずれかのアクションを実行して、ローカル CA 証明書をエクスポートし、信頼できる証明書として Cisco Unified CallManager サーバにインストールします。

proxy-ldc-issuer で指定されたトラストポイントがダイナミック証明書の署名者として使用される場合、次のコマンドを使用して証明書をエクスポートします。

hostname(config)# crypto ca export trustpoint identity-certificate
 

埋め込みローカル CA サーバ LOCAL-CA-SERVER の場合、次のコマンドを使用して証明書をエクスポートします。

hostname(config)# show crypto ca server certificates
 

e. 出力をファイルに保存し、Cisco Unified Call Manager に証明書をインポートします。詳細については、Cisco Unified Call Manager のマニュアル( http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cucos/5_0_4/iptpch6.html#wp1040848 )を参照してください。

f. Cisco Unified Call Manager ソフトウェアの Display Certificates 機能を使用して、インストールされた証明書を確認します。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cucos/5_0_4/iptpch6.html#wp1040354

ステップ 4 フォン プロキシ インスタンスを設定します。

a. CTL ファイル インスタンスを作成します。

hostname(config)# phone-proxy phone_proxy_name
 

b. 次のコマンドを入力して、SRTP と RTP のフォン プロキシで使用されるメディア終端アドレスを設定します。

hostname(config-phone-proxy)# media-termination address ip_address

) • メディア終端アドレスについては、ネットワーク上の別のデバイスによって使用されることがなく、セキュリティ アプライアンス インターフェイスに接続された外部ネットワーク上にある未使用の IP アドレスである、パブリックにルーティング可能な IP アドレスを選択する必要があります。

特に、メディア終端アドレスは、セキュリティ アプライアンス インターフェイスの IP アドレスと同じにはできず、既存のスタティック NAT 規則と重複することはできません。さらに、Cisco UCM または TFTP サーバの IP アドレスと同じにすることもできません。

ルータまたはゲートウェイの背後にある IP 電話の場合は、電話がメディア終端アドレスに到達できるように、ルータまたはゲートウェイでメディア終端アドレスにルートを追加します。


 

c. 実際の内部アドレスを使用して TFTP サーバを作成し、次のコマンドを入力して TFTP サーバがあるインターフェイスを指定します。

hostname(config-phone-proxy)# tftp-server address ip_address interface interface
 

d. 次のコマンドを入力して、ステップ 3 で作成した TLS プロキシ インスタンスを設定します。

hostame(config-phone-proxy)# tls-proxy proxy_name
 

e. 次のコマンドを入力して、ステップ 2 で作成した CTL ファイル インスタンスを設定します。

hostname(config-phone-proxy)# ctl-file ctl_name
 

f. デフォルトはノンセキュアであるため、クラスタのモードを混合モードに設定します。

hostname(config-phone-proxy)# cluster-mode mixed
 

g. (オプション)稼動環境に、IP 電話がすべての HTTP 要求を送信する先である外部 HTTP 要求がある場合は、次のコマンドを入力して、セキュリティ アプライアンスでプロキシ サーバを設定します。

proxy-server address ip_address [listen_port] interface ifc
 

フォン プロキシの使用中に設定できるプロキシ サーバは 1 つだけです。ただし、プロキシ サーバの設定後に IP 電話でコンフィギュレーション ファイルをすでにダウンロードしている場合は、IP 電話が、ファイル内のプロキシ サーバ アドレスが示されたコンフィギュレーション ファイルを取得できるように IP 電話を再開する必要があります。

デフォルトでは、Enterprise パラメータで設定された Phone URL パラメータは URL で FQDN を使用します。HTTP プロキシの DNS lookup によって FQDN が解決されない場合は、IP アドレスを使用するようにパラメータを変更しなければならないことがあります。

h. (オプション)Cisco IP Communicator(CIPC)ソフトフォンが音声とデータ VLAN シナリオで配置されている場合に、CIPC ソフトフォンに強制的に認証済みモードで動作させるには、次のコマンドを入力します。

hostname(config-phone-proxy)# cipc security-mode authenticated
 

CIPC でのフォン プロキシの使用に関するすべての要件については、「Cisco IP Communicator のフォン プロキシ設定」を参照してください。

i. (オプション)設定済みの IP 電話ごとに、Cisco UCM で行った設定を保存するには、次のコマンドを入力します。

hostname(config-phone-proxy)# no disable service-settings
 

デフォルトでは、次の設定は IP 電話でディセーブルになっています。

PC Port

Gratuitous ARP

Voice VLAN access

Web Access

Span to PC Port

ステップ 5 SIP と Skinny 検査を使用してフォン プロキシをイネーブルにします。

a. 次のコマンドを入力して、検査するトラフィックのセキュア Skinny クラスを設定します。

hostname(config)# class-map class_map_name
hostname(config-cmap)# match port tcp eq 2443
 

b. 次のコマンドを入力して、検査するトラフィックのセキュア SIP クラスを設定します。

hostname(config)# class-map class_map_name
hostname(config-cmap)# match port tcp eq 5061
 

c. 次のコマンドを入力して、ポリシー マップを設定して、トラフィックのクラスにアクションを添付します。

hostname(config)# policy-map name
hostname(config-pmap)# class classmap-name
hostname(config-pmap-c)# inspect skinny phone-proxy pp_name
hostnae(config-pmap)# class classmap-name
hostname(config-pmap-c)# inspect sip phone-proxy pp_name
 

d. 次のコマンドを入力して、外部インターフェイスでポリシーをイネーブルにします。

hostname(config)# service-policy policymap_name interface intf
 


 

Cisco IP Communicator のフォン プロキシ設定

フォン プロキシを使用して Cisco IP Communicator(CIPC)を設定するには、次の要件を満たす必要があります。

phone-proxy コマンドの下に cipc security-mode authenticated コマンドを含めます。

CIPC がノンセキュア モードで Cisco UCM に登録できるようにする ACL を作成します。

null-sha1 を SSL 暗号化の暗号の 1 つとして設定します。

現在のバージョンの Cisco IP Communicator(CIPC)では認証済みモードがサポートされ、TLS シグナリングが実行されますが、音声の暗号化は実行されません。そのため、フォン プロキシ インスタンスの設定時に次のコマンドを含める必要があります。

cipc security-mode authenticated

CIPC では、LSC が TLS ハンドシェイクを実行する必要があるため、CIPC は、クリアテキストのシグナリングを使用してノンセキュア モードで Cisco UCM に登録する必要があります。CIPC が登録できるようにするには、CIPC がノンセキュア SIP および SCCP シグナリング ポート(5060 と 2000)で Cisco UCM に接続できるようにする ACL を作成します。

CIPC では、TLS ハンドシェイクの実行時に別の暗号が使用されて、null-sha1 暗号と SSL 暗号化が設定されている必要があります。null-shal 暗号を追加するには、 show run all ssl コマンドを使用して ssl encryption コマンドの出力を表示し、 null-shal を SSL 暗号化リストの最後に追加します。


) フォン プロキシは、CIPC とともに使用する場合、エンド ユーザが CIPC でデバイス名をリセットしたり([Preferences] > [Network] タブ > [Use this Device Name] フィールド)、管理者が Cisco Unified CM 管理コンソールでデバイス名をリセットしたりする([Device] メニュー > [Phone Configuration] > [Device Name] フィールド)ことをサポートしていません。フォン プロキシで機能するには、CIPC コンフィギュレーション ファイルの形式を SEP<mac_address>.cnf.xml にする必要があります。デバイス名がこの形式(SEP<mac_address>)に従っていない場合は、CIPC は、フォン プロキシ経由で Cisco UMC からコンフィギュレーション ファイルを取得できず、CIPC が機能しません。


CIPC が遠隔地にあるコンピュータにインストールされている場合は、フォン プロキシと CIPC はサポートされません。これらのコンピュータからのコールはインターネットを通過し、セキュリティ アプライアンスで終了して、適応型セキュリティ アプライアンスの背後のネットワーク上にある IP 電話に到達します。セキュリティ アプライアンスの背後にある IP 電話に到達するには、CIPC がインストールされているコンピュータがネットワーク上になければなりません。

UDP ポート転送用に Linksys ルータを設定

IP 電話が NAT 対応ルータの背後にある場合は、UDP ポートを IP 電話の IP アドレスに転送するようそのルータを設定できます。具体的には、TFTP 要求中に IP 電話で障害が発生し、その障害の原因が着信 TFTP データ パケットをドロップするルータである場合に、UDP ポートの転送用にルータを設定します。ポート 69 で UDP ポートを IP 電話に転送できるようルータを設定します。

明示的な UDP 転送に代わる方法として、一部のケーブル ルータまたは DSL ルータでは、IP 電話を DMZ ホストとして指定する必要があります。ケーブル ルータまたは DSL ルータでは、このホストは、パブリック ネットワークからすべての着信接続を受信する特殊なホストです。

フォン プロキシの設定時に、UDP ポートが明示的に転送される IP 電話と、DMZ ホストとして指定されている IP 電話の間には機能上の差はありません。どちらを選択するかは完全に、エンド ユーザの能力と好みによります。

ルータの設定

ある範囲の UDP ポートを IP 電話に転送するようご使用のファイアウォールとルータを設定する必要があります。これによって、コールの発信または受信時に IP 電話が音声を受信できるようになります。


) ケーブル ルータまたは DSL ルータが異なる場合は、この設定の手順も異なります。さらに、大部分の NAT 対応ルータでは、特定の範囲のポートだけを単一の IP アドレスに転送できます。


ファイアウォールとルータの各ブランドまたはモデルの設定は異なりますが、タスクは同じです。ルータのブランドとモデルに固有の手順については、製造業者の Web サイトにアクセスしてください。

Linksys ルータ


ステップ 1 Web ブラウザから、ルータの管理 Web ページに接続します。Linksys の場合は、これは通常 http://192.168.1.1 のようになります。

ステップ 2 [Applications & Gaming] タブまたは [Port Forwarding] タブ(いずれかルータに表示される方)をクリックします。

ステップ 3 ポート転送のデータが含まれている表を見つけて、次の値が含まれるエントリを追加します。

 

表 27-6 ルータに追加するポート転送の値

アプリケーション
開始
終了
プロトコル
IP アドレス
イネーブル

IP 電話

1024

65535

UDP

電話の IP アドレス

チェック済み

TFTP

69

69

UDP

電話の IP アドレス

チェック済み

ステップ 4 [Save Settings] をクリックします。ポート転送が設定されます。


 

レート制限 TFTP 要求の概要

リモート アクセスのシナリオでは、インターネット経由で接続されている IP 電話は、TFTP 要求を TFTP サーバに送信できるため、TFTP 要求のレート制限を設定することを推奨します。

TFTP 要求のレート制限を設定するには、モジュラ ポリシー フレームワークで police コマンドを設定します。 police コマンドの使用については、『 Cisco Security Appliance Command Reference 』を参照してください。

ポリシングは、設定した最大レート(ビット/秒)を超えるトラフィックが発生しないようにして、1 つのトラフィック フローがリソース全体を占有できないようにする方法です。トラフィックが最大レートを超えると、セキュリティ アプライアンスは超過したトラフィックをドロップします。また、ポリシングは、許可されるトラフィックの最大単一バーストも設定します。

レート制限の設定例

次の例は、 police コマンドとモジュラ ポリシー フレームワークを使用して TFTP 要求のレート制限を設定する方法を説明しています。

最初に、フォン プロキシに必要な適応レートを決定します。適応レートを決定するには、次の式を使用します。

X * Y * 8
 

値は次のとおりです。

X:秒あたりの要求数。

Y:各パケットのサイズ。L2、L3、および L4 とペイロードを含みます。

そのため、300 TFTP 要求/秒のレートが必要な場合は、適応レートは次のように計算されます。

300 requests/second * 80 bytes * 8 = 192000
 

次の設定例は、計算された適応レートが police コマンドで使用される方法を示しています。

access-list tftp extended permit udp any host 192.168.0.1 eq tftp
 
class-map tftpclass
match access-list tftp
 
policy-map tftpmap
class tftpclass
police output 192000
 
service-policy tftpmap interface inside

 

メディア終端アドレス宛の ICMP トラフィックの概要

メディア終端アドレスを ping できるホストを制御するには、 icmp コマンドを使用して、セキュリティ アプライアンス上の外部インターフェイスにアクセス規則を適用します。

外部インターフェイスに適用される ICMP アクセスの規則はすべて、メディア終端アドレス宛のトラフィックに適用されます。

たとえば、メディア終端アドレス宛のホストからの ICMP ping を拒否するには、次のコマンドを入力します。

icmp deny any outside

セキュリティ アプライアンスからのデバッグ情報

ここでは、 debug capture 、および show の各コマンドを使用して、フォン プロキシに関するデバッグ情報を取得する方法について説明します。これらのコマンドの構文の詳細については、『 Cisco Security Appliance Command Reference 』を参照してください。

表 27-7 に、フォン プロキシで使用する debug コマンドをリストします。

 

表 27-7 フォン プロキシで使用するセキュリティ アプライアンスの debug コマンド

処理内容
使用するコマンド
注意

TLS プロキシ検査のエラーとイベント メッセージを表示する。

debug inspect tls-proxy [ events | errors ]

IP 電話がすべての TFTP ファイルを正常にダウンロードしたが、フォン プロキシに対して設定された TLS プロキシとの TLS ハンドシェイクを完了できなかった場合に、このコマンドを使用します。

フォン プロキシに関連する SIP と Skinny 検査のメディア セッションのエラーとイベント メッセージを表示する。

debug phone-proxy media [ events | errors ]

IP 電話で接続失敗または音声の問題が発生している場合に、このコマンドを debug sip コマンドと debug skinny コマンドとともに使用します。

フォン プロキシに関連する SIP と Skinny 検査のシグナリング セッションのエラーとイベント メッセージを表示する。

debug phone-proxy signaling [ events | errors ]

IP 電話が Cisco UCM に登録できない場合、または接続失敗が発生している場合に、このコマンドを debug sip コマンドと debug skinny コマンドとともに使用します。

CTL ファイルの作成とコンフィギュレーション ファイルの解析を含め、TFTP 検査のエラーとイベント メッセージを表示する。

debug phone-proxy tftp [ events | errors ]

 

SIP アプリケーション検査のデバッグ メッセージを表示する。

debug sip

IP 電話で接続問題(たとえば、ネットワーク内に接続できても、ネットワークからコールを発信できない)が発生している場合に、このコマンドを使用します。出力では、4XX または 5XX メッセージの有無を調べます。

SCCP(Skinny)アプリケーション検査のデバッグ メッセージを表示する。

debug skinny

IP 電話で接続問題(たとえば、ネットワーク内に接続できても、ネットワークからコールを発信できない)が発生している場合に、このコマンドを使用します。出力では、4XX または 5XX メッセージの有無を調べます。

表 27-8 に、フォン プロキシで使用する capture コマンドをリストします。パケット スニフィングとネットワーク障害の切り離しを行うためにパケット取得機能をイネーブルにするには、適切なインターフェイス(IP 電話と Cisco UCM)で capture コマンドを使用します。

 

表 27-8 フォン プロキシで使用するセキュリティ アプライアンスの capture コマンド

処理内容
使用するコマンド
注意

セキュリティ アプライアンス インターフェイスでパケットを取得する。

capture capture_name interface interface_name

このコマンドは、パケットで調べなければならない可能性がある問題が発生している場合に使用します。

たとえば、TFTP 障害が発生していて、 debug コマンドからの出力に問題が明確に示されていない場合は、IP 電話があるインターフェイスと、TFTP サーバがあるインターフェイスで capture コマンドを実行して、トランザクションと問題が発生している可能性がある場所を確認します。

内部インターフェイス上のフォン プロキシに接続されているノンセキュア IP 電話がある場合に、TLS プロキシからデータを取得する。

capture capture_name packet-length bytes interface inside buffer buf_size

 

内部インターフェイス上のフォン プロキシに接続されているセキュア IP 電話がある場合に、TLS プロキシから暗号化されたデータを取得する。

capture capture_name type tls-proxy buffer buf_size packet-length bytes interface inside

 

1 つ以上のインターフェイス上の TLS プロキシから暗号化された着信データと発信データを取得する。

capture capture_name type tls-proxy buffer buf_size packet-length bytes interface interface_nam e

シグナリングが失敗する場合は、復号化されたパケットを取得して、SIP および SCCP シグナリング メッセージの内容を確認しなければならない可能性があります。 capture コマンドでは type tls-proxy オプションを使用します。

表 27-9 に、フォン プロキシで使用する show コマンドをリストします。

表 27-9 フォン プロキシで使用するセキュリティ アプライアンスの show コマンド

処理内容
使用するコマンド
注意

アクセラレートされたセキュリティ パスによってドロップされたパケットまたは接続を表示する。

show asp drop

このコマンドは、IP 電話の音声品質の問題や、フォン プロキシのその他のトラフィック問題をトラブルシューティングする場合に使用します。このコマンドの実行に加えて、電話からコース ステータスを取得して、ドロップされたパケットまたはジッタの有無をチェックします。「IP 電話からのデバッグ情報」を参照してください。

特定の分類子ドメインについて、アクセラレートされたセキュリティ パスの分類子の内容を表示する。

show asp table classify domain domain_name

IP 電話が TFTP ファイルをダウンロードしていない場合は、このコマンドを使用して、ドメイン inspect-phone-proxy の分類規則がフォン プロキシ インスタンスの下で設定されている TFTP サーバへのホストに設定されていることをチェックします。

IP 電話が登録に失敗する場合は、このコマンドを使用して、登録できない IP 電話についてドメイン app-redirect の分類規則が設定されていることを確認します。

セキュリティ アプライアンスへの接続またはセキュリティ アプライアンスからの接続と、通過トラフィック接続を表示する。

show conn all

音声の問題が発生している場合は、このコマンドを使用して、IP 電話からメディア終端アドレスへの接続がオープンになっていることを確認します。

コマンドを使用します。

hostname# show conn | include p
 

TFTP 接続の出力には、最後に「p」フラグが付いている必要があります。

UDP out 64.169.58.181:9014 in 192.168.200.101:39420 idle 0:01:51 bytes 522 flags p
 

このコマンドを使用すると、TFTP 接続を検査する「inspect-phone-proxy」を通過している接続がフォン プロキシにあることが示されます。このコマンドを使用すると、p フラグがそこにあるため、TFTP 要求が検査されていることが確認されます。

バッファ内のログとロギング設定を表示する。

show logging

show logging コマンドを入力する前に、 show logging コマンドによって現在のメッセージ バッファと現在の設定が表示されるように、 logging buffered コマンドをイネーブルにします。

このコマンドは、フォン プロキシと IP 電話が正常に TLS ハンドシェイクを実行しているかどうかを判別する場合に使用します。

コマンドを使用すると、パケットが拒否される可能性があるか、変換が失敗する多数の問題をトラブルシューティングするのに役立ちます。

フォン プロキシによって格納される、対応するメディア セッションを表示する。

show phone-proxy media-sessions

このコマンドは、正常に完了したコールからの出力を表示する場合に使用します。さらに、片通話など、IP 電話の音声の問題をトラブルシューティングする場合にも使用します。

データベースに格納されたセキュア モードが可能な IP 電話を表示する。

show phone-proxy secure-phones

問題について、この出力に IP 電話のエントリがあること、およびこの IP 電話のポートがゼロではないこと(Cisco UCM に正常に登録されていることを示します)を確認します。

フォン プロキシによって格納される、対応するシグナリング セッションを表示する。

show phone-proxy signaling-sessions

このコマンドは、メディアまたはシグナリングの障害をトラブルシューティングする場合に使用します。

設定済みのサービス ポリシーを表示する。

show service-policy

このコマンドは、サービス ポリシーの統計情報を表示する場合に使用します。

フォン プロキシに関連するアクティブな TLS プロキシ セッションを表示する。

show tls-proxy sessions

IP 電話が登録に失敗した場合は、このコマンドを使用して、IP 電話が、フォン プロキシに対して設定された TLS プロキシとのハンドシェイクを正常に完了したかどうかを確認します。

IP 電話からのデバッグ情報

IP 電話で次のアクションを実行します。

[Settings] ボタン > [Status] > [Status Messages] を選択し、表示するステータス項目を選択して、IP 電話に関するステータス メッセージを確認します。

[Settings] ボタン > [Status] > [Call Statistic] を選択して、IP 電話からコール統計情報データを収集します。次のようなデータが表示されます。

RxType: G.729 TxType: G.729
RxSize: 20 ms TxSize: 20 ms
RxCnt: 0 TxCnt: 014174
AvgJtr: 10 MaxJtr: 59
RxDisc: 0000 RxLost: 014001
 

[Settings] ボタン > [Security Configuration] を選択し、IP 電話でのセキュリティ設定を確認します。Web アクセス、セキュリティ モード、MIC、LSC、CTL ファイル、信頼リスト、および CAPF の設定が表示されます。[Security mode] の下で、IP 電話が [Encrypted] に設定されていることを確認します。

[Settings] ボタン > [Security Configuration] > [Trust List] を選択して、IP 電話を調べて、電話にインストールされている証明書を判別します。信頼リストで、次のことを確認します。

IP 電話が接続する必要があるエンティティごとにエントリがあることを確認します。プライマリとバックアップの Cisco UCM がある場合は、信頼リストには Cisco UCM ごとのエントリが含まれている必要があります。

IP 電話で LSC が必要な場合は、レコード エントリに CAPF エントリが含まれている必要があります。

エントリごとにリストされる IP アドレスが、IP 電話が到達できるエンティティのマッピング IP アドレスであることを確認します。

Web ブラウザを開き、URL http:// IP_phone_IP address にある IP 電話のコンソール ログにアクセスします。ページにデバイス情報が表示されます。左側のペインの [Device Logs] ログで [Console Logs] をクリックします。

IP 電話の登録の失敗

次のエラーが原因で、IP 電話がフォン プロキシに登録できないことがあります。

「IP 電話のコンソールに TFTP 認証エラーが表示される」

「コンフィギュレーション ファイルの解析エラー」

「コンフィギュレーション ファイルの解析エラー:DNS 応答を取得できない」

「非コンフィギュレーション ファイルの解析エラー」

「Cisco UCM がコンフィギュレーション ファイルの TFTP 要求に応答しない」

「セキュリティ アプライアンスが TFTP データを送信した後で IP 電話が応答しない」

「署名のないファイルを要求している IP 電話のエラー」

「IP 電話が CTL ファイルをダウンロードできない」

「シグナリング接続による IP 電話の登録の失敗」

「SSL ハンドシェイクの失敗」

「証明書の検証エラー」

IP 電話のコンソールに TFTP 認証エラーが表示される

問題 IP 電話に次のステータス メッセージが表示されます。

TFTP Auth Error

ソリューション このステータス メッセージは、IP 電話の CTL ファイルの問題を示している可能性があります。

IP 電話の CTL ファイルの問題を修正するには、次の手順を実行します。


ステップ 1 IP 電話で、[Setting] ボタン > [Security Configuration] > [Trust List] を選択します。ネットワーク上の各エンティティ(プライマリ Cisco UCM、セカンダリ Cisco UCM、TFTP サーバ)が、信頼リストに独自のエントリを指定していること、および IP 電話が各エンティティの IP アドレスに到達できることを確認します。

ステップ 2 セキュリティ アプライアンスから、次のコマンドを入力することで、フォン プロキシの CTL ファイルにネットワーク上のエンティティ(プライマリ Cisco UCM、セカンダリ Cisco UCM、TFTP サーバ)ごとに 1 つのレコード エントリが含まれていることを確認します。

hostname# show running-config all ctl-file [ctl_name]
 

これらの各レコード エントリによって、IP 電話の信頼リストで 1 つのエントリが作成されます。フォン プロキシは、CUCM+TFTP 機能を使用して内部に 1 つのエントリを作成します。

ステップ 3 CTL ファイルで、それぞれの IP アドレスがエンティティのグローバルまたはマッピング IP アドレスであることを確認します。IP 電話が複数のインターフェイスにある場合は、追加のアドレッシング要件が適用されます。「複数のインターフェイスにおける IP 電話のアドレッシングの要件」を参照してください。


 

コンフィギュレーション ファイルの解析エラー

問題 セキュリティ アプライアンスが Cisco UCM からコンフィギュレーション ファイルを受信して、解析を試みると、デバッグ出力( debug phone-proxy tftp errors )に次のエラーが表示されます。

PP: 192.168.10.5/49357 requesting SEP00010002003.cnf.xml.sgn
PP: opened 0x193166
.......
PP: Beginning of element tag is missing, got !
PP: error parsing config file
PP: Error modifying config file, dropping packet
 

ソリューション この問題をトラブルシューティングするには、次のアクションを実行します。


ステップ 1 Web ブラウザに次の URL を入力して、Cisco Unified CM 管理コンソールから IP 電話のコンフィギュレーション ファイルを取得します。

http://<cucm_ip>:6970/<config_file_name>
 

たとえば、Cisco UCM IP アドレスが 128.106.254.2 で、IP 電話のコンフィギュレーション ファイル名が SEP000100020003.cnf.xml の場合は、次のように入力します。

http://128.106.254.2:6970/SEP000100020003.cnf.xml
 

ステップ 2 このファイルを保存して、TAC で事例を開き、このファイルと、セキュリティ アプライアンスで debug phone-proxy tftp コマンドを実行したときの出力を送信します。


 

コンフィギュレーション ファイルの解析エラー:DNS 応答を取得できない

問題 セキュリティ アプライアンスが Cisco UCM からコンフィギュレーション ファイルを受信して、解析を試みると、デバッグ出力( debug phone-proxy tftp errors )に次のエラーが表示されます。

PP: 192.168.10.5/49357 requesting SEP00010002003.cnf.xml.sgn
PP: opened 0x193166
.......
PP: Callback required for parsing config file
PP: Unable to get dns response for id 7
PP: Callback, error modifying config file
 

このエラーは、Cisco UCM が FQDN として設定されていて、フォン プロキシが DNS lookup を行おうとしているが応答の取得に失敗したことを示しています。

ソリューション


ステップ 1 セキュリティ アプライアンスで DNS lookup が設定されていることを確認します。

ステップ 2 DNS lookup が設定されている場合は、セキュリティ アプライアンスから Cisco UCM の FQDN を ping できるかどうかを判別します。

ステップ 3 セキュリティ アプライアンスが Cisco UCM FQDN を ping できない場合は、DNS サーバについて問題が発生しているかどうかを調べます。

ステップ 4 さらに、 name コマンドを使用して、FQDN を使用して名前を IP アドレスに関連付けます。 name コマンドの使用については、『 Cisco Security Appliance Command Reference 』を参照してください。


 

非コンフィギュレーション ファイルの解析エラー

問題 セキュリティ アプライアンスが、Cisco UCM から IP 電話のコンフィギュレーション ファイル以外のファイルを受信し、これを解析しようとします。次のエラーがデバッグ出力( debug phone-proxy tftp )に表示されます。

PP: 192.168.10.5/49357 requesting SK72f64050-7ad5-4b47-9bfa-5e9ad9cd4aa9.xml.sgn
PP: opened 0x193166
.......
PP: Beginning of element tag is missing, got !
PP: error parsing config file
PP: Error modifying config file, dropping packet
 

ソリューション フォン プロキシは、IP 電話のコンフィギュレーション ファイルだけを解析する必要があります。フォン プロキシの TFTP ステートがそのステートから解除されると、フォン プロキシは、IP 電話のコンフィギュレーション ファイル以外のファイルを解析しようとしている場合には検出できず、 debug phone-proxy tftp コマンドからのセキュリティ アプライアンス出力に上のエラーが表示されます。

この問題をトラブルシューティングするには、次のアクションを実行します。


ステップ 1 IP 電話をリブートします。

ステップ 2 セキュリティ アプライアンスで、次のコマンドを入力して、最初の TFTP 要求からエラー情報を取得して、最初のエラーが発生した場所を特定します。

hostname# debug phone-proxy tftp
 

ステップ 3 IP 電話からセキュリティ アプライアンスへのパケットを取得します。パケットは、IP 電話側のインターフェイスと、Cisco UCM 側のインターフェイスで取得してください。「セキュリティ アプライアンスからのデバッグ情報」を参照してください。

ステップ 4 このトラブルシューティング データを保存し、TAC で事例を開いて、この情報を提供します。


 

Cisco UCM がコンフィギュレーション ファイルの TFTP 要求に応答しない

問題 セキュリティ アプライアンスが IP 電話のコンフィギュレーション ファイルについての TFTP 要求を Cisco UCM に転送すると、Cisco UCM が応答せず、デバッグ出力( debug phone-proxy tftp )に次のエラーが表示されます。

PP: 192.168.10.5/49355 requesting SEP001562106AF3.cnf.xml.sgn
PP: opened 0x17ccde
PP: 192.168.10.5/49355 requesting SEP001562106AF3.cnf.xml.sgn
PP: Client outside:192.168.10.5/49355 retransmitting request for Config file SEP001562106AF3.cnf.xml.sgn
PP: opened 0x17ccde
PP: 192.168.10.5/49355 requesting SEP001562106AF3.cnf.xml.sgn
PP: Client outside:192.168.10.5/49355 retransmitting request for Config file SEP001562106AF3.cnf.xml.sgn
PP: opened 0x17ccde
PP: 192.168.10.5/49355 requesting SEP001562106AF3.cnf.xml.sgn
PP: Client outside:192.168.10.5/49355 retransmitting request for Config file SEP001562106AF3.cnf.xml.sgn
PP: opened 0x17ccde
 

ソリューション この問題をトラブルシューティングするには、次のアクションを実行します。


ステップ 1 次のトラブルシューティング アクションを実行して、Cisco UCM が TFTP 要求に応答していない理由を判別します。

PAT が外部インターフェイスに対して設定されている場合は、Cisco UCM を使用して、セキュリティ アプライアンス内部インターフェイスを ping します。これで、IP 電話の IP アドレスがセキュリティ アプライアンス内部インターフェイスの IP アドレスに NAT を使用するようになります。

NAT と PAT が設定されていない場合は、Cisco UCM を使用して IP 電話の IP アドレスを ping します。

ステップ 2 セキュリティ アプライアンスが TFTP 要求を転送していることを確認します。セキュリティ アプライアンスと Cisco UCM 間のパケットをインターフェイスで取得します。「セキュリティ アプライアンスからのデバッグ情報」を参照してください。

 


 

セキュリティ アプライアンスが TFTP データを送信した後で IP 電話が応答しない

問題 セキュリティ アプライアンスが CTL ファイルについての TFTP 要求を IP 電話から受信して、IP 電話にデータを転送すると、電話がデータを確認していない可能性があり、TFTP トランザクションが失敗します。

次のエラーがデバッグ出力( debug phone-proxy tftp )に表示されます。

PP: Client outside:68.207.118.9/33606 retransmitting request for CTL file CTLSEP001DA2B78E91.tlv
PP: opened 0x214b27a
PP: Data Block 1 forwarded from 168.215.146.220/20168 to 68.207.118.9/33606 ingress ifc outside
PP: 68.207.118.9/33606 requesting CTLSEP001DA2B78E91.tlv
PP: Client outside:68.207.118.9/33606 retransmitting request for CTL file CTLSEP001DA2B78E91.tlv
PP: 68.207.118.9/33606 requesting CTLSEP001DA2B78E91.tlv
PP: Client outside:68.207.118.9/33606 retransmitting request for CTL file CTLSEP001DA2B78E91.tlv
 

ソリューション IP 電話が応答していない理由を判別して、問題をトラブルシューティングするには、次のアクションを実行します。


ステップ 1 次のコマンドを入力してセキュリティ アプライアンスが TFTP 要求を転送していることを確認し、セキュリティ アプライアンスと IP 電話間のパケットをインターフェイスで取得します。

hostname# capture out interface outside
 

capture コマンドの使用の詳細については、『 Cisco Security Appliance Command Reference 』を参照してください。

ステップ 2 IP 電話がルータの背後にある場合は、ルータがデータをドロップしている可能性があります。UDP ポート転送がルータでイネーブルになっていることを確認してください。

ステップ 3 ルータが Linksys ルータである場合は、設定要件について、「UDP ポート転送用に Linksys ルータを設定」を参照してください。


 

署名のないファイルを要求している IP 電話のエラー

問題 IP 電話は常に、署名されたファイルを要求する必要があります。そのため、要求される TFTP ファイルには常に .SGN 拡張子が付いています。

IP 電話が署名されたファイルを要求していない場合は、デバッグ出力( debug phone-proxy tftp errors )に次のエラーが表示されます。

Error: phone requesting for unsigned config file
 

ソリューション ほとんどの場合、このエラーは、IP 電話がセキュリティ アプライアンスから CTL ファイルを正常にインストールしていないために発生します。

IP 電話でステータス メッセージを確認して、IP 電話がセキュリティ アプライアンスから CTL ファイルを正常にダウンロードしてインストールしているかどうかを判別します。詳細については、「IP 電話からのデバッグ情報」を参照してください。

IP 電話が CTL ファイルをダウンロードできない

問題 IP 電話のステータス メッセージに、CTL ファイルをダウンロードできず、IP 電話をセキュア(暗号化済み)モードに変換できないことが示されます。

ソリューション IP 電話に既存の CTL ファイルがない場合は、[Settings] ボタン > [Status] > [Status Messages] を選択してステータス メッセージを確認します。IP 電話で CTL ファイルの認証エラーが発生したことを示すステータス メッセージがリストにある場合は、IP 電話のコンソール ログを取得して、TAC 事例を開き、ログを送信してください。

ソリューション このエラーは、IP 電話に既存の CTL ファイルがすでにある場合に IP 電話のステータス メッセージに表示されることがあります。


ステップ 1 IP 電話を調べて、CTL ファイルがすでに存在しているかどうかを確認します。これは、IP 電話が以前に混合モードのクラスタ Cisco UCM に登録した場合に発生することがあります。IP 電話で、[Settings] ボタン > [Security Configuration] > [CTL file] を選択します。

ステップ 2 [Settings] ボタン > [Security Configuration] > [CTL file] > [Select] を選択して、既存の CTL ファイルを消去します。キーパッドの **# を押して、[Erase] を選択します。


 

ソリューション CTL ファイルのダウンロードの問題は、メディア終端の問題が原因になっている可能性があります。フォン プロキシ設定のメディア終端アドレスが正しく設定されているかどうかを判別するには、次のコマンドを入力します。

hostname(config)# show running-config all phone-proxy
!
phone-proxy mypp
media-termination address 10.10.0.25
cipc security-mode authenticated
cluster-mode mixed
disable service-settings
timeout secure-phones 0:05:00
hostname(config)#
 

メディア終端アドレスが正しく設定されていることを確認します。セキュリティ アプライアンスには、次の基準を満たすメディア終端の IP アドレスが必要です。

IP アドレスは、ネットワーク上の別のデバイスによって使用されることがなく、セキュリティ アプライアンス インターフェイスに接続された外部ネットワーク上にある未使用の IP アドレスである、パブリックにルーティング可能な IP アドレスです。

IP アドレスは、セキュリティ アプライアンス インターフェイスの IP アドレスと同じにはできません。

IP アドレスは、既存のスタティック NAT 規則と重複できません。

IP アドレスは、Cisco UCM または TFTP サーバの IP アドレスと同じにはできません。

ルータまたはゲートウェイの背後にある IP 電話の場合は、電話がメディア終端アドレスに到達できるように、ルータまたはゲートウェイでメディア終端アドレスにルートを追加します。

シグナリング接続による IP 電話の登録の失敗

問題 IP 電話が、フォン プロキシとの TLS ハンドシェイクと、TFTP を使用したファイルのダウンロードを実行できません。

ソリューション


ステップ 1 フォン プロキシと IP 電話間の TLS ハンドシェイクが行われているかどうかを判別して、次のことを実行します。

a. 次のコマンドを使用して、ロギングをイネーブルにします。

hostname(config)# logging buffered debugging
 

b. logging buffered コマンドによって取得された syslog からの出力を確認するには、次のコマンドを入力します。

hostname# show logging
 

syslog には、IP 電話がいつ TLS ハンドシェイクを試行したか、IP 電話がコンフィギュレーション ファイルをダウンロードした後に何が発生したかを示す情報が含まれています。

ステップ 2 TLS プロキシがフォン プロキシに対して正しく設定されていることかどうかを判別します。

a. 次のコマンドを入力して、現在実行中の TLS プロキシ設定をすべて表示します。

hostname# show running-config tls-proxy
tls-proxy proxy
server trust-point _internal_PP_<ctl_file_instance_name>
client ldc issuer ldc_signer
client ldc key-pair phone_common
no client cipher-suite
hostname#
 

b. (手順 a. に示すように)出力の tls-proxy コマンドの下に server trust-point コマンドが含まれていることを確認します

server trust-point コマンドがない場合は、フォン プロキシ設定で TLS プロキシを変更します。

「ノンセキュア Cisco UCM クラスタでのフォン プロキシの設定」ステップ 3、または 「混合モードの Cisco UCM クラスタでのフォン プロキシの設定」ステップ 3 を参照してください。

フォン プロキシの TLS プロキシ設定にこのコマンドがないと、TLS ハンドシェイクが失敗します。

ステップ 3 TLS が正常に完了するように、必要な証明書がすべてセキュリティ アプライアンスにインポートされていることを確認します。

a. 次のコマンドを入力して、セキュリティ アプライアンスにインストールされている証明書を確認します。

hostname# show running-config crypto
 

さらに、IP 電話にインストールされている証明書を確認します。IP 電話を調べて MIC がインストールされているかどうかを確認する方法については、「IP 電話からのデバッグ情報」を参照してください。

b. インストールされている証明書のリストに、フォン プロキシで必要な証明書がすべて含まれていることを確認します。

詳細については、 表 27-5 フォン プロキシのセキュリティ アプライアンスで必要な証明書 を参照してください。

c. 欠落している証明書をセキュリティ アプライアンスにインポートします。「Cisco UCM からの証明書のインポート」も参照してください。

ステップ 4 上の手順で問題を解決できない場合は、次のアクションを実行して、シスコ サポートの追加のトラブルシューティング情報を取得してください。

a. フォン プロキシの追加のデバッグ情報を取得するには、次のコマンドを入力します。

hostname# debug inspect tls-proxy error
hostname# show running-config ssl
hostname(config) show tls-proxy tls_name session host host_addr detail
 

b. パケット スニフィングとネットワーク障害の切り離しを行うためにパケット取得機能をイネーブルにするには、内部インターフェイスと外部インターフェイス(IP 電話と Cisco UCM)で capture コマンドをイネーブルにします。詳細については、『 Cisco Security Appliance Command Reference 』を参照してください。


 

問題 TLS ハンドシェイクは正常に完了しても、シグナリング接続で障害が発生します。

ソリューション 次のアクションを実行してください。

次のコマンドを使用して、SIP および Skinny シグナリングが正常に行われているかどうかを確認します。

debug sip

debug skinny

TLS ハンドシェイクが失敗し、次の syslog が表示される場合は、SSL 暗号化方式が正しく設定されていない可能性があります。

%ASA-6-725001: Starting SSL handshake with client dmz:171.169.0.2/53097 for TLSv1 session.
%ASA-7-725010: Device supports the following 1 cipher(s).
%ASA-7-725011: Cipher[1] : RC4-SHA
%ASA-7-725008: SSL client dmz:171.169.0.2/53097 proposes the following 2 cipher(s).
%ASA-7-725011: Cipher[1] : AES256-SHA
%ASA-7-725011: Cipher[2] : AES128-SHA
%ASA-7-725014: SSL lib error. Function: SSL3_GET_CLIENT_HELLO Reason: no shared cipher
%ASA-6-725006: Device failed SSL handshake with dmz client:171.169.0.2/53097
 

暗号を正しく設定するには、次の手順を実行します。


ステップ 1 フォン プロキシで使用されている暗号を確認するには、次のコマンドを入力します。

hostname# show run all ssl
 

ステップ 2 必要な暗号を追加するには、次のコマンドを入力します。

hostname(config)# ssl encryption
 

デフォルトでは、すべてのアルゴリズムは次の順序で使用可能です。

[3des-sha1] [des-sha1] [rc4-md5] [その他]

ssl encryption コマンドを使用した暗号の設定の詳細については、『 Cisco Security Appliance Command Reference 』を参照してください。


 

SSL ハンドシェイクの失敗

問題 フォン プロキシが機能していません。最初のトラブルシューティングでは、セキュリティ アプライアンス syslog で次のエラーが対象とされませんでした。

%ASA-7-725014: SSL lib error. Function: SSL3_READ_BYTES Reason: ssl handshake failure
%ASA-7-725014: SSL lib error. Function: SSL3_GET_CLIENT_CERTIFICATE Reason: no certificate returned
%ASA-6-725006: Device failed SSL handshake with outside client:72.146.123.158/30519
%ASA-3-717009: Certificate validation failed. No suitable trustpoints found to validate certificate serial number: 62D06172000000143FCC, subject name: cn=CP-7962G-SEP002155554502,ou=EVVBU,o=Cisco Systems Inc.
%ASA-3-717027: Certificate chain failed validation. No suitable trustpoint was found to validate chain.

ソリューション

TLS が正常に完了するように、必要な証明書がすべてセキュリティ アプライアンスにインポートされていることを確認します。


ステップ 1 次のコマンドを入力して、セキュリティ アプライアンスにインストールされている証明書を確認します。

hostname# show running-config crypto
 

さらに、IP 電話にインストールされている証明書を確認します。IP 電話を調べて MIC がインストールされているかどうかを確認する方法については、「IP 電話からのデバッグ情報」を参照してください。

ステップ 2 インストールされている証明書のリストに、フォン プロキシで必要な証明書がすべて含まれていることを確認します。

詳細については、 表 27-5 フォン プロキシのセキュリティ アプライアンスで必要な証明書 を参照してください。

ステップ 3 欠落している証明書をセキュリティ アプライアンスにインポートします。「Cisco UCM からの証明書のインポート」も参照してください。


 

問題 フォン プロキシが機能していません。最初のトラブルシューティングでは、セキュリティ アプライアンス syslog で次のエラーが対象とされませんでした。

%ASA-6-725001: Starting SSL handshake with client dmz:171.169.0.2/53097 for TLSv1 session.
%ASA-7-725010: Device supports the following 1 cipher(s).
%ASA-7-725011: Cipher[1] : RC4-SHA
%ASA-7-725008: SSL client dmz:171.169.0.2/53097 proposes the following 2 cipher(s).
%ASA-7-725011: Cipher[1] : AES256-SHA
%ASA-7-725011: Cipher[2] : AES128-SHA
%ASA-7-725014: SSL lib error. Function: SSL3_GET_CLIENT_HELLO Reason: no shared cipher
%ASA-6-725006: Device failed SSL handshake with dmz client:171.169.0.2/53097
 

ソリューション SSL 暗号化方式が正しく設定されていない可能性があります。次の手順を実行して、正しい暗号を設定します。


ステップ 1 フォン プロキシで使用されている暗号を確認するには、次のコマンドを入力します。

hostname# show run all ssl
 

ステップ 2 必要な暗号を追加するには、次のコマンドを入力します。

hostname(config)# ssl encryption
 

デフォルトでは、すべてのアルゴリズムは次の順序で使用可能です。

[3des-sha1] [des-sha1] [rc4-md5] [その他]

ssl encryption コマンドを使用した暗号の設定の詳細については、『 Cisco Security Appliance Command Reference 』を参照してください。


 

証明書の検証エラー

問題 セキュリティ アプライアンス ログのエラーは、証明書の検証エラーが発生したことを示しています。

show logging asdm コマンドを入力すると、次のエラーが表示されます。

3|Jun 19 2008 17:23:54|717009: Certificate validation failed. No suitable trustpoints found to validate
certificate serial number: 348FD2760000000E6E27, subject name: cn=CP-7961G-SEP001819A89CC3,ou=EVVBU,o=Cisco Systems Inc.

ソリューション

IP 電話によって指定された MIC をフォン プロキシが認証するには、シスコ作成の CA(MIC)証明書がセキュリティ アプライアンスにインポートされている必要があります。

TLS が正常に完了するように、必要な証明書がすべてセキュリティ アプライアンスにインポートされていることを確認します。


ステップ 1 次のコマンドを入力して、セキュリティ アプライアンスにインストールされている証明書を確認します。

hostname# show running-config crypto
 

さらに、IP 電話にインストールされている証明書を確認します。証明書情報が [Security Configuration] メニューに表示されます。IP 電話を調べて MIC がインストールされているかどうかを判別する方法については、「IP 電話からのデバッグ情報」を参照してください。

ステップ 2 インストールされている証明書のリストに、フォン プロキシで必要な証明書がすべて含まれていることを確認します。

詳細については、 表 27-5 フォン プロキシのセキュリティ アプライアンスで必要な証明書 を参照してください。

ステップ 3 欠落している証明書をセキュリティ アプライアンスにインポートします。「Cisco UCM からの証明書のインポート」も参照してください。


 

メディア終端アドレスのエラー

問題 media-termination address コマンドを入力すると、次のエラーが表示されます。

hostname(config-phone-proxy)# media-termination address ip_address
ERROR: Failed to apply IP address to interface Virtual254, as the network overlaps with interface GigabitEthernet0/0. Two interfaces cannot be in the same subnet.
ERROR: Failed to set IP address for the Virtual interface
ERROR: Could not bring up Phone proxy media termination interface
ERROR: Failed to find the HWIDB for the Virtual interface

ソリューション フォン プロキシ設定のメディア終端アドレスが正しく設定されているかどうかを判別するには、次のコマンドを入力します。

hostname(config)# show running-config all phone-proxy
asa2(config)# show running-config all phone-proxy
!
phone-proxy mypp
media-termination address 10.10.0.25
cipc security-mode authenticated
cluster-mode mixed
disable service-settings
timeout secure-phones 0:05:00
hostname(config)#
 

メディア終端アドレスが正しく設定されていることを確認します。セキュリティ アプライアンスには、次の基準を満たすメディア終端の IP アドレスが必要です。

IP アドレスは、ネットワーク上の別のデバイスによって使用されることがなく、セキュリティ アプライアンス インターフェイスに接続された外部ネットワーク上にある未使用の IP アドレスである、パブリックにルーティング可能な IP アドレスです。

IP アドレスは、セキュリティ アプライアンス インターフェイスの IP アドレスと同じにはできません。

IP アドレスは、既存のスタティック NAT 規則と重複できません。

IP アドレスは、Cisco UCM または TFTP サーバの IP アドレスと同じにはできません。

ルータまたはゲートウェイの背後にある IP 電話の場合は、電話がメディア終端アドレスに到達できるように、ルータまたはゲートウェイでメディア終端アドレスにルートを追加します。

IP 電話の音声の問題

フォン プロキシを介した IP 電話への接続時に、次の音声エラーが発生することがあります。

音声コールのメディアの失敗

問題 コール シグナリングが完了しても、片通話であるか音声がありません。

ソリューション

片通話または音声なしの問題は、メディア終端の問題が原因になっている可能性があります。フォン プロキシ設定のメディア終端アドレスが正しく設定されているかどうかを判別するには、次のコマンドを入力します。

hostname(config)# show running-config all phone-proxy
asa2(config)# show running-config all phone-proxy
!
phone-proxy mypp
media-termination address 10.10.0.25
cipc security-mode authenticated
cluster-mode mixed
disable service-settings
timeout secure-phones 0:05:00
hostname(config)#
 

メディア終端アドレスが正しく設定されていることを確認します。セキュリティ アプライアンスには、次の基準を満たすメディア終端の IP アドレスが必要です。

IP アドレスは、ネットワーク上の別のデバイスによって使用されることがなく、セキュリティ アプライアンス インターフェイスに接続された外部ネットワーク上にある未使用の IP アドレスである、パブリックにルーティング可能な IP アドレスです。

IP アドレスは、セキュリティ アプライアンス インターフェイスの IP アドレスと同じにはできません。

IP アドレスは、既存のスタティック NAT 規則と重複できません。

IP アドレスは、Cisco UCM または TFTP サーバの IP アドレスと同じにはできません。

ルータまたはゲートウェイの背後にある IP 電話の場合は、電話がメディア終端アドレスに到達できるように、ルータまたはゲートウェイでメディア終端アドレスにルートを追加します。

メディア終端アドレスが要件を満たしている場合は、すべての IP 電話が IP アドレスに到達できるかどうかを判別します。

IP アドレスが正しく設定されていて、すべての IP 電話によって到達可能である場合は、IP 電話でコール統計情報を調べて(「IP 電話からのデバッグ情報」を参照)、IP 電話に Rcvr パケットと Sender パケットがあるかどうか、または Rcvr Lost パケットまたは Discarded パケットがあるかどうかを判別します。

SAST キーの保存

ハードウェア障害が原因で回復が必要な場合や、交換が必要な場合に備えて、セキュリティ アプライアンス上の Site Administrator Security Token(SAST)キーを保存できます。次の手順は、SAST キーを回復して、新しいハードウェアで使用する方法を示しています。

SAST キーは、 show crypto key mypubkey rsa コマンドを使用して確認できます。SAST キーは、 _internal_ ctl-file_name _SAST_ X というラベルの付いたトラストポイントに関連付けられます。ここで、 ctl-file-name は設定された CTL ファイル インスタンスの名前で、 X は 0 ~ N-1 の範囲の整数(N は CTL ファイルに対して設定された SAST の数で、デフォルトは 2)です。


ステップ 1 セキュリティ アプライアンスで、 crypto ca export コマンドを使用して、すべての SAST キーを PKCS-12 形式でエクスポートします。

hostname(config)# crypto ca export _internal_ctl-file_name_SAST_X pkcs12 passphrase
 
hostname(config)# Exported pkcs12 follows:
MIIGZwIBAzCCBiEGCSqGSIb3DQEHAaCCBhIEggYOMIIGCjCCBgYGCSqGSIb3DQEH
 
[snip]
 
MIIGZwIBAzCCBiEGCSqGSIb3DQEHAaCCBhIEggYOMIIGCjCCBgYGCSqGSIb3DQEH
---End - This line not part of the pkcs12---
 
hostname(config)# crypto ca export _internal_ctl-file_name_SAST_X pkcs12 passphrase
 
hostname(config)# Exported pkcs12 follows:
MIIGZwIBAzCCBiEGCSqGSIb3DQEHAaCCBhIEggYOMIIGCjCCBgYGCSqGSIb3DQEH
 
[snip]
 
mGF/hfDDNAICBAA=
 
---End - This line not part of the pkcs12---
hostname(config)#

) この出力をセキュアな場所に保存します。


ステップ 2 SAST キーを新しいセキュリティ アプライアンスにインポートします。

a. SAST キーをインポートするには、次のコマンドを入力します。

hostname(config)# crypto ca import trustpoint pkcs12 passphrase
 

ここで、 trustpoint _internal_ ctl-file_name _SAST_ X で、 ctl-file-name は、設定された CTL ファイル インスタンスの名前で、 X は、セキュリティ アプライアンスから何をエクスポートしたかに応じて 0 ~ 4 の範囲の整数です。

b. ステップ 1 で保存した PKCS-12 出力を使用して、次のコマンドを入力し、プロンプトが表示されたら出力を貼り付けます。

hostname(config)# crypto ca import _internal_ctl-file_name_SAST_X pkcs12 passphrase
 
hostname(config)# Enter the base 64 encoded pkcs12.
hostname(config)# End with the word "quit" on a line by itself:
MIIGZwIBAzCCBiEGCSqGSIb3DQEHAaCCBhIEggYOMIIGCjCCBgYGCSqGSIb3DQEH
 
[snip]
 
muMiZ6eClQICBAA=
hostname(config)# quit
INFO: Import PKCS12 operation completed successfully
hostname(config)# crypto ca import _internal_ctl-file_name_SAST_X pkcs12 passphrase
 
hostname(config)# Enter the base 64 encoded pkcs12.
hostname(config)# End with the word "quit" on a line by itself:
MIIGZwIBAzCCBiEGCSqGSIb3DQEHAaCCBhIEggYOMIIGCjCCBgYGCSqGSIb3DQEH
 
[snip]
 
mGF/hfDDNAICBAA=
hostname(config)# quit
INFO: Import PKCS12 operation completed successfully
hostname(config)#
 

ステップ 3 次のコマンドを入力して、ステップ 2 で作成した SAST トラストポイントで使用したものと同じ名前を使用して、新しいセキュリティ アプライアンスで CTL ファイル インスタンスを作成します。Cisco UMC(プライマリとセカンダリ)ごとにトラストポイントを作成します。

hostname(config)# ctl-file ctl_name
hostname(config-ctl-file)# record-entry cucm trustpoint trust_point address address
hostname(config-ctl-file)# record-entry capf trustpoint trust_point address address
hostname(config-ctl-file)# no shutdown
 


 

暗号化音声検査の TLS プロキシ

この項では、暗号化音声検査の TLS プロキシについて説明します。次の項目を取り上げます。

「概要」

「TLS プロキシの設定」

「TLS プロキシのデバッグ」

「CTL クライアント」

概要

暗号化音声検査を使用すると、セキュリティ アプライアンスは、音声シグナリング トラフィックの復号化、検査、変更(必要に応じて NAT フィックスアップの実行など)、および再暗号化を行う一方で、Skinny および SIP プロトコルに対する既存の Voice over IP(VoIP)検査機能はすべて維持します。音声シグナリングが復号化されると、プレーンテキストのシグナリング メッセージが既存の検査エンジンに渡されます。

セキュリティ アプライアンスは、Cisco IP Phone と Cisco Unified CallManager の間の TLS プロキシとして機能します。プロキシは、電話と Cisco Unified CallManager の間の音声通話に対しては透過的です。Cisco IP Phone は、登録の前に Cisco Unified CallManager から 証明書信頼リストをダウンロードします。証明書信頼リストには、TFTP サーバや Cisco Unified CallManager サーバなど、電話が信頼すべきデバイスの ID(証明書)が含まれています。サーバ プロキシをサポートするには、CTL ファイルに、セキュリティ アプライアンスが Cisco Unified CallManager 用に作成した証明書が含まれている必要があります。セキュリティ アプライアンスが Cisco IP Phone に代わってコールをプロキシするには、セキュリティ アプライアンス上にある、認証局によって発行され、Cisco Unified CallManager が確認可能な証明書(電話のローカル ダイナミック証明書)を提示する必要があります。

TLS プロキシは、Cisco Unified CallManager Release 5.1 以降でサポートされています。ユーザは Cisco Unified CallManager のセキュリティ機能について詳しく知っておく必要があります。Cisco Unified CallManager のセキュリティの背景と詳細な説明については、次の Cisco Unified CallManager のマニュアルを参照してください。

TLS プロキシは、暗号化レイヤに適用されるため、アプリケーション レイヤ プロトコル検査を設定する必要があります。ユーザは ASA セキュリティ アプライアンスの検査機能、特に Skinny 検査と SIP 検査について詳しく知っておく必要があります。展開トポロジとコンフィギュレーションの詳細については、『 Cisco Security Appliance Command Line Configuration Guide 』を参照してください。

TLS プロキシの設定

図 27-2 のセキュリティ アプライアンスは、Cisco IP Phone と Cisco Unified CallManager の対話で、クライアントとサーバの両方のプロキシとして機能します。

図 27-2 TLS プロキシ フロー

TLS プロキシを設定する前に、次の前提条件を満たす必要があります。

TLS プロキシを設定する前に、セキュリティ アプライアンスの時刻を設定する必要があります。手動で時刻を設定し、時刻を表示するには、clock set コマンドと show clock コマンドを使用します。セキュリティ アプライアンスでは Cisco Unified CallManager クラスタと同じ NTP サーバを使用することをお勧めします。セキュリティ アプライアンスと Cisco Unified CallManager サーバの間で時刻が同期していないと、証明書確認が失敗し、その結果、TLS ハンドシェイクが失敗する場合があります。

Cisco Unified CallManager と相互運用するには、3DES-AES ライセンスが必要です。AES は、Cisco Unified CallManager と Cisco IP Phone で使用されるデフォルトの暗号です。

セキュリティ アプライアンスに TLS プロキシを設定するには、次の手順を実行します。


ステップ 1 (オプション)次のコマンドを使用してセキュリティ アプライアンスがサポートする最大 TLS プロキシ セッション数を設定します。次に例を示します。

hostname(config)# tls-proxy maximum-sessions 1200
 

) tls-proxy maximum-sessions コマンドは、TLS プロキシのような暗号化アプリケーション用に予約されているメモリ サイズを制御します。暗号化メモリは、システムのブート時に予約されます。設定した最大セッション数が現在予約されているものよりも大きい場合、コンフィギュレーションを有効にするためにセキュリティ アプライアンスのリブートが必要になることもあります。


ステップ 2 Cisco UCM に保存されている次の証明書をインポートします。これらの証明書は、フォン プロキシ用にセキュリティ アプライアンスで必要です。たとえば、IP 電話の証明書を検証するには、フォン プロキシで CA 製造業者の証明書が必要です。「Cisco UCM からの証明書のインポート」を参照してください。

CallManager

Cisco_Manufacturing_CA

CAP-RTP-001

CAP-RTP-002

(オプション)CAPF:LSC プロビジョニングが必要であるか、LSC 対応の IP 電話がある場合に、CAPF 証明書をインポートします。


) Cisco UCM に複数の CAPF 証明書がある場合は、すべてセキュリティ アプライアンスにインポートする必要があります。


ステップ 3 次のコマンドを使用して必要な RSA キー ペアを作成します。次に例を示します。

hostname(config)# crypto key generate rsa label ccm_proxy_key modulus 1024
hostname(config)# crypto key generate rsa label ldc_signer_key modulus 1024
hostname(config)# crypto key generate rsa label phone_common modulus 1024
 

役割ごとに異なるキー ペアを使用することをお勧めします。

ステップ 4 次のコマンドを使用して Cisco Unified CallManager クラスタのプロキシ証明書を作成します。次に例を示します。

hostname(config)# ! for self-signed CCM proxy certificate
hostname(config)# crypto ca trustpoint ccm_proxy
hostname(config-ca-trustpoint)# enrollment self
hostname(config-ca-trustpoint)# fqdn none
hostname(config-ca-trustpoint)# subject-name cn=EJW-SV-1-Proxy
hostname(config-ca-trustpoint)# keypair ccm_proxy_key
hostname(config)# crypto ca enroll ccm_proxy
 

Cisco Unified CallManager プロキシ証明書は、自己署名の場合と、第三者 CA 発行の場合があります。証明書は CTL クライアントにエクスポートされます。


) Cisco IP Phone では、CTL ファイルを参照して証明書を確認するために、X.509v3 証明書に特定のフィールドが存在している必要があります。そのため、プロキシ証明書トラストポイントの subject-name エントリを設定する必要があります。このサブジェクト名は、CN、OU、O の各フィールドを順に連結して構成する必要があります。CN フィールドは必須で、それ以外はオプションです。

連結したフィールド(存在する場合)はそれぞれセミコロンで区切られ、次のいずれかの形式になります。

CN=xxx;OU=yyy;O=zzz
CN=xxx;OU=yyy
CN=xxx;O=zzz
CN=xxx


ステップ 5 次のコマンドを使用して Cisco IP Phone の LDC に署名する内部ローカル CA を作成します。次に例を示します。

hostname(config)# ! for the internal local LDC issuer
hostname(config)# crypto ca trustpoint ldc-server
hostname(config-ca-trustpoint)# enrollment self
hostname(config-ca-trustpoint)# proxy-ldc-issuer
hostname(config-ca-trustpoint)# fqdn my-ldc-ca.exmaple.com
hostname(config-ca-trustpoint)# subject-name cn=FW-LDC-SIGNER-172_23_45_200
hostname(config-ca-trustpoint)# keypair ldc-signer-key
hostname(config)# crypto ca enroll ldc-server
 

このローカル CA は、proxy-ldc-issuer がイネーブルな標準の自己署名トラストポイントとして作成されます。LDC を発行するには、セキュリティ アプライアンス上の埋め込みローカル CA である LOCAL-CA-SERVER を使用することもできます。

ステップ 6 次のコマンドを使用して、CTL クライアントからの接続に備えて CTL プロバイダー インスタンスを作成します。次に例を示します。

hostname(config)# ctl-provider my_ctl
hostname(config-ctl-provider)# client interface inside address 172.23.45.1
hostname(config-ctl-provider)# client username CCMAdministrator password XXXXXX encrypted
hostname(config-ctl-provider)# export certificate ccm_proxy
hostname(config-ctl-provider)# ctl install
 

このユーザ名とパスワードは、Cisco Unified CallManager の管理用ユーザ名とパスワードと同じでなければなりません。export コマンドのトラストポイント名は、Cisco Unified CallManager サーバのプロキシ証明書です。

CTL プロバイダーのデフォルトの受信ポート番号は TCP 2444 です。これは、Cisco Unified CallManager のデフォルトの CTL ポートです。Cisco Unified CallManager クラスタが異なるポートを使用している場合は、service port コマンドを使用してポート番号を変更します。

ステップ 7 次のコマンドを使用して TLS プロキシ インスタンスを作成します。次に例を示します。

hostname(config)# tls-proxy my_proxy
hostname(config-tlsp)# server trust-point ccm_proxy
hostname(config-tlsp)# client ldc issuer ldc_server
hostname(config-tlsp)# client ldc key-pair phone_common
hostname(config-tlsp)# client cipher-suite aes128-sha1 aes256-sha1
 

server コマンドでは、元の TLS サーバのプロキシ パラメータを設定します。つまり、TLS ハンドシェイク時、または元の TLS クライアントと対話するときに、セキュリティ アプライアンスがサーバとして機能できるようにするパラメータです。client コマンドでは、元の TLS クライアントのプロキシ パラメータを設定します。つまり、TLS ハンドシェイク時、または元の TLS サーバと対話するときに、セキュリティ アプライアンスがクライアントとして機能できるようにするパラメータです。

ステップ 8 次のコマンドを使用して、Skinny または SIP 検査での Cisco IP Phone と Cisco Unified CallManager の TLS プロキシをイネーブルにします。次に例を示します。

hostname(config)# class-map sec_skinny
hostname(config-cmap)# match port tcp eq 2443
 
hostname(config)# policy-map type inspect skinny skinny_inspect
hostname(config-pmap)# parameters
hostname(config-pmap-p)# ! Skinny inspection parameters
 
hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect skinny skinny_inspect
hostname(config-pmap)# class sec_skinny
hostname(config-pmap-c)# inspect skinny skinny_inspect tls-proxy my_proxy
 
hostname(config)# service-policy global_policy global
 

ステップ 9 ローカル CA 証明書(ldc_server)をエクスポートし、信頼できる証明書として Cisco Unified CallManager サーバにインストールします。

a. proxy-ldc-issuer で指定されたトラストポイントがダイナミック証明書の署名者として使用される場合、次のコマンドを使用して証明書をエクスポートします。次に例を示します。

hostname(config)# crypto ca export ldc_server identity-certificate
 

b. 埋め込みローカル CA サーバ LOCAL-CA-SERVER の場合、次のコマンドを使用して証明書をエクスポートします。次に例を示します。

hostname(config)# show crypto ca server certificate
 

出力をファイルに保存し、Cisco Unified CallManager に証明書をインポートします。詳細については、Cisco Unified CallManager のマニュアル( http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_0/iptp_adm/504/iptpch6.htm#wp1040848 )を参照してください。

この手順の後、次の Cisco Unified CallManager GUI の Display Certificates 機能を使用して、インストールされた証明書を確認することもできます。

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_0/iptp_adm/504/iptpch6.htm#wp1040354

ステップ 10 CTL クライアント アプリケーションを実行してサーバ プロキシ証明書(ccm_proxy)を CTL ファイルに追加し、その CTL ファイルをセキュリティ アプライアンスにインストールします。CTL クライアントの設定方法と使用方法については、次の Cisco Unified CallManager のマニュアルを参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_1/nci/p08/secuauth.htm


) セキュリティ アプライアンスと相互運用するためには、Cisco Unified CallManager Release 5.1 と一緒にリリースされた CTL クライアントが必要です。TLS プロキシ サポートの詳細については、「CTL クライアント」を参照してください。



 

TLS プロキシのデバッグ

TLS プロキシ接続の問題をデバッグするために、SSL の syslog とともに TLS プロキシのデバッグ フラグをイネーブルにする場合があります。たとえば、TLS プロキシ関連のデバッグと syslog 出力だけをイネーブルにするには、次のコマンドを入力します。

hostname(config)# debug inspect tls-proxy events
hostname(config)# debug inspect tls-proxy errors
hostname(config)# logging enable
hostname(config)# logging timestamp
hostname(config)# logging list loglist message 711001
hostname(config)# logging list loglist message 725001-725014
hostname(config)# logging list loglist message 717001-717038
hostname(config)# logging buffer-size 1000000
hostname(config)# logging buffered loglist
hostname(config)# logging debug-trace
 

次の出力例では、SIP 電話用に TLS プロキシ セッションのセットアップが完了したことが示されています。

hostname(config)# show log
 
Apr 17 2007 23:13:47: %ASA-6-725001: Starting SSL handshake with client outside:133.9.0.218/49159 for TLSv1 session.
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Set up proxy for Client outside:133.9.0.218/49159 <-> Server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Using trust point 'local_ccm' with the Client, RT proxy cbae1538
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Waiting for SSL handshake from Client outside:133.9.0.218/49159.
Apr 17 2007 23:13:47: %ASA-7-725010: Device supports the following 4 cipher(s).
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : RC4-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[3] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[4] : DES-CBC3-SHA
Apr 17 2007 23:13:47: %ASA-7-725008: SSL client outside:133.9.0.218/49159 proposes the following 2 cipher(s).
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725012: Device chooses cipher : AES128-SHA for the SSL session with client outside:133.9.0.218/49159
Apr 17 2007 23:13:47: %ASA-7-725014: SSL lib error. Function: SSL23_READ Reason: ssl handshake failure
Apr 17 2007 23:13:47: %ASA-7-717025: Validating certificate chain containing 1 certificate(s).
Apr 17 2007 23:13:47: %ASA-7-717029: Identified client certificate within certificate chain. serial number: 01, subject name: cn=SEP0017593F50A8.
Apr 17 2007 23:13:47: %ASA-7-717030: Found a suitable trustpoint _internal_ejw-sv-2_cn=CAPF-08a91c01 to validate certificate.
Apr 17 2007 23:13:47: %ASA-6-717022: Certificate was successfully validated. serial number: 01, subject name: cn=SEP0017593F50A8.
Apr 17 2007 23:13:47: %ASA-6-717028: Certificate chain was successfully validated with warning, revocation status was not checked.
Apr 17 2007 23:13:47: %ASA-6-725002: Device completed SSL handshake with client outside:133.9.0.218/49159
Apr 17 2007 23:13:47: %ASA-6-725001: Starting SSL handshake with server inside:195.168.2.201/5061 for TLSv1 session.
Apr 17 2007 23:13:47: %ASA-7-725009: Device proposes the following 2 cipher(s) to server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Generating LDC for client 'cn=SEP0017593F50A8', key-pair 'phone_common', issuer 'LOCAL-CA-SERVER', RT proxy cbae1538
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Started SSL handshake with Server
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Data channel ready for the Client
Apr 17 2007 23:13:47: %ASA-7-725013: SSL Server inside:195.168.2.201/5061 choose cipher : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-717025: Validating certificate chain containing 1 certificate(s).
Apr 17 2007 23:13:47: %ASA-7-717029: Identified client certificate within certificate chain. serial number: 76022D3D9314743A, subject name: cn=EJW-SV-2.inside.com.
Apr 17 2007 23:13:47: %ASA-6-717022: Certificate was successfully validated. Certificate is resident and trusted, serial number: 76022D3D9314743A, subject name: cn=EJW-SV-2.inside.com.
Apr 17 2007 23:13:47: %ASA-6-717028: Certificate chain was successfully validated with revocation status check.
Apr 17 2007 23:13:47: %ASA-6-725002: Device completed SSL handshake with server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Data channel ready for the Server
 

アクティブな TLS プロキシ セッションをチェックするには、show tls-proxy コマンドにさまざまなオプションを指定して使用します。次にいくつかの出力例を示します。

hostname(config-tlsp)# show tls-proxy
Maximum number of sessions: 1200
 
TLS-Proxy 'sip_proxy': ref_cnt 1, seq# 3
Server proxy:
Trust-point: local_ccm
Client proxy:
Local dynamic certificate issuer: LOCAL-CA-SERVER
Local dynamic certificate key-pair: phone_common
Cipher suite: aes128-sha1 aes256-sha1
Run-time proxies:
Proxy 0xcbae1538: Class-map: sip_ssl, Inspect: sip
Active sess 1, most sess 3, byte 3456043
 
TLS-Proxy 'proxy': ref_cnt 1, seq# 1
Server proxy:
Trust-point: local_ccm
Client proxy:
Local dynamic certificate issuer: ldc_signer
Local dynamic certificate key-pair: phone_common
Cipher-suite: <unconfigured>
Run-time proxies:
Proxy 0xcbadf720: Class-map: skinny_ssl, Inspect: skinny
Active sess 1, most sess 1, byte 42916
 
hostname(config-tlsp)# show tls-proxy session count
2 in use, 4 most used
 
hostname(config-tlsp)# show tls-proxy session
2 in use, 4 most used
outside 133.9.0.211:50437 inside 195.168.2.200:2443 P:0xcbadf720(proxy) S:0xcbc48a08 byte 42940
outside 133.9.0.218:49159 inside 195.168.2.201:5061 P:0xcbae1538(sip_proxy) S:0xcbad5120 byte 8786
 
hostname(config-tlsp)# show tls-proxy session detail
2 in use, 4 most used
outside 133.9.0.211:50437 inside 195.168.2.200:2443 P:0xcbadf720(proxy) S:0xcbc48a08 byte 42940
Client: State SSLOK Cipher AES128-SHA Ch 0xca55e498 TxQSize 0 LastTxLeft 0 Flags 0x1
Server: State SSLOK Cipher AES128-SHA Ch 0xca55e478 TxQSize 0 LastTxLeft 0 Flags 0x9
Local Dynamic Certificate
Status: Available
Certificate Serial Number: 29
Certificate Usage: General Purpose
Public Key Type: RSA (1024 bits)
Issuer Name:
cn=TLS-Proxy-Signer
Subject Name:
cn=SEP0002B9EB0AAD
o=Cisco Systems Inc
c=US
Validity Date:
start date: 09:25:41 PDT Apr 16 2007
end date: 09:25:41 PDT Apr 15 2008
Associated Trustpoints:
 
outside 133.9.0.218:49159 inside 195.168.2.201:5061 P:0xcbae1538(sip_proxy) S:0xcbad5120 byte 8786
Client: State SSLOK Cipher AES128-SHA Ch 0xca55e398 TxQSize 0 LastTxLeft 0 Flags 0x1
Server: State SSLOK Cipher AES128-SHA Ch 0xca55e378 TxQSize 0 LastTxLeft 0 Flags 0x9
Local Dynamic Certificate
Status: Available
Certificate Serial Number: 2b
Certificate Usage: General Purpose
Public Key Type: RSA (1024 bits)
Issuer Name:
cn=F1-ASA.default.domain.invalid
Subject Name:
cn=SEP0017593F50A8
Validity Date:
start date: 23:13:47 PDT Apr 16 2007
end date: 23:13:47 PDT Apr 15 2008
Associated Trustpoints:
 

CTL クライアント

Cisco Unified CallManager Release 5.1 以降で提供される CTL クライアント アプリケーションは、CTL ファイルで TLS プロキシ サーバ(ファイアウォール)をサポートします。図 27-3 から図 27-6 は、CTL クライアントでサポートされる TLS プロキシ機能を示しています。

図 27-3 CTL クライアントの TLS プロキシ機能:ファイアウォールの追加

 

図 27-3 のように、TLS プロキシとしてのセキュリティ アプライアンスで構成される CTL エントリを追加できます。

 

図 27-4 CTL クライアントの TLS プロキシ機能:ASA の IP アドレスまたはドメイン名

 

図 27-4 のように、CTL クライアントにセキュリティ アプライアンスの IP アドレスまたはドメイン名を入力できます。

図 27-5 CTL クライアントの TLS プロキシ機能:ASA の CTL エントリ

 

図 27-5 は、TLS プロキシとしてのセキュリティ アプライアンスの CTL エントリが追加されたことを示しています。CTL エントリは、CTL クライアントがセキュリティ アプライアンスの CTL プロバイダー サービスに接続してプロキシ証明書を取得した後に追加されます。

 

図 27-6 CTL クライアントの TLS プロキシ機能:ASA にインストールされている CTL ファイル

 

セキュリティ アプライアンスでは、CTL ファイルをそのままフラッシュ メモリに保存することはなく、CTL ファイルを解析して適切なトラストポイントをインストールします。図 27-6 は、インストールが正常に完了したことを示しています。

Cisco Unified Mobility と MMP 検査エンジン

この項は、次の内容で構成されています。

「モビリティ プロキシの概要」

「Cisco Unified Mobility のセキュリティ アプライアンスの設定」

「Cisco Unified Mobility のデバッグ」

モビリティ プロキシの概要

Cisco Unified Mobility ソリューションで Cisco UMA をサポートするために、モビリティ プロキシ(TLS プロキシとして実装)には次の機能が組み込まれています。

クライアントとのハンドシェイク中にクライアント認証を許可しない機能。

サーバにインポートされた PKCS-12 証明書をプロキシ証明書として許可する。

セキュリティ アプライアンスには、Cisco UMA Mobile Multiplexing Protocol(MMP)を検証するための検査エンジンが組み込まれています。

MMP は、Cisco UMA クライアントとサーバ間でデータ エンティティを送信するためのデータ転送プロトコルです。図 27-7 に示すように、MMP は、コネクション型プロトコル(基盤となる転送)の上位で実行する必要があり、TLS などのセキュアな転送プロトコルの上位で実行することを前提としています。HTTP プロトコルが大規模ファイルのアップロードおよびダウンロードで使用される場合と同様に、Orative Markup Language(OML)プロトコルは、データ同期の目的で MMP の上位で実行されることが前提となっています。

図 27-7 MMP スタック

 

TCP および TLS のデフォルト ポートは 5443 です。埋め込み NAT またはセカンダリ接続はありません。

Cisco UMA クライアントとサーバの通信は、TLS を通じてプロキシ処理できます。TLS は、データを復号化し、MMP の検査モジュールにこのデータを渡して、エンドポイントに転送する前にデータを再暗号化します。MMP の検査モジュールは、MMP ヘッダーの整合性を検査して、OML と HTTP を適切なハンドラに渡します。MMP ヘッダーおよびデータに対し、セキュリティ アプライアンスは、次のアクションを行います。

クライアントの MMP ヘッダーの形式が正しいことを検証する。不正な形式のヘッダーが検出されると、TCP セッションは終了されます。

クライアントからサーバへの MMP ヘッダーが規定の長さを超過していないかを検証する。MMP ヘッダー長が 4096 を超えると、TCP セッションは終了されます。

クライアントからサーバの MMP コンテンツが規定の長さを超過していないかを検証する。エンティティのコンテンツの長さが 4096 を超えると、TCP セッションは終了されます。


) 4096 は、MMP の実装で現在使用されている値です。


MMP ヘッダーとエンティティは複数のパケットに分割できるため、セキュリティ アプライアンスはデータをバッファリングして一貫性が保たれていることを検査します。ストリーム API(SAPI)は、保留中の検査を行うためにデータ バッファリングを処理します。MMP ヘッダー テキストは、大文字小文字を区別せずに扱われ、ヘッダー テキストと値の間にはスペースが存在します。TCP 接続のステートをモニタリングすることで、MMP ステートの再要求が実行されます。

モビリティ プロキシの導入シナリオ

図 27-8図 27-9 に、Cisco Unified Mobility ソリューションで使用される TLS プロキシの 2 つの導入シナリオを示します。シナリオ 1(推奨される導入アーキテクチャ)では、セキュリティ アプライアンスは、ファイアウォールと TLS プロキシの両方として機能します。シナリオ 2 では、セキュリティ アプライアンスは TLS プロキシとしてだけ機能し、既存のファイアウォールとともに動作します。どちらのシナリオでも、クライアントはインターネットから接続します。

シナリオ 1 の導入では、セキュリティ アプライアンスは Cisco UMA クライアントと Cisco UMA サーバ間にあります。Cisco UMA クライアントは、それぞれのスマートフォンにダウンロードされる実行可能プログラムです。Cisco UMA クライアント アプリケーションは、企業の Cisco UMA サーバへのデータ接続(TLS 接続)を確立します。セキュリティ アプライアンスは接続を代行受信し、クライアントが Cisco UMA サーバに送信するデータを検査します。


) Cisco Unified Mobility ソリューションの TLS プロキシでは、クライアント認証はサポートされません。これは、Cisco UMA クライアントが証明書を提示できないためです。TLS ハンドシェイク中に認証をディセーブルにするには、次のコマンドを使用できます。
hostname(config)# tls-proxy my_proxy
hostname(config-tlsp)# no server authenticate-client


図 27-8 モビリティ プロキシと MMP 検査を使用するファイアウォールとしてのセキュリティ アプライアンス

 

図 27-8 では、セキュリティ アプライアンスは、Cisco UMA サーバ 10.1.1.2 の IP アドレスを 192.0.2.140 に変換することによって、スタティック NAT を実行します。

図 27-9 は、セキュリティ アプライアンスが TLS プロキシとしてだけ機能し、企業ファイアウォールとして機能しない導入シナリオ 2 を示します。このシナリオでは、セキュリティ アプライアンスと企業ファイアウォールは、NAT を実行しています。企業ファイアウォールは、インターネットから企業の Cisco UMA サーバに接続する必要があるクライアントを予測できません。そのため、この導入をサポートするには、次のアクションを実行できます。

宛先 IP アドレス 192.0.2.41 を 172.16.27.41 に変換する着信トラフィックの NAT 規則を設定します。

企業ファイアウォールがワイルドカード ピンホールを開く必要がないよう、すべてのパケットの送信元 IP アドレスを変換する、着信トラフィックのインターフェイス PAT 規則を設定します。Cisco UMA サーバは、送信元 IP アドレスが 192.0.12.183 のパケットを受信します。

hostname(config)# nat (outside) 1 0.0.0.0 0.0.0.0 outside
hostname(config)# global (inside) 1 192.0.2.183 netmask 255.255.255.255

) このインターフェイス PAT 規則は、別の送信元ポートを使用することによって、セキュリティ アプライアンスの外部インターフェイスでの Cisco UMA クライアントの IP アドレスを、内部インターフェイスでの単一の IP アドレスに統合します。このアクションの実行は、多くの場合「外部 PAT」と呼ばれます。Cisco Unified Mobility の TLS プロキシが、フォン プロキシ、Cisco Unified Presence、またはアプリケーション検査を行うその他の機能を備えたセキュリティ アプライアンスの同じインターフェイスでイネーブルになっている場合は、「外部 PAT」は推奨されません。埋め込みのアドレス変換が必要な場合は、「外部 PAT」はアプリケーション検査で完全にはサポートされません。


図 27-9 Cisco UMC および Cisco UMA アーキテクチャ:シナリオ 2:モビリティ プロキシとしてだけのセキュリティ アプライアンス

 

NAT と PAT を使用するモビリティ プロキシ

どちらのシナリオ(図 27-8図 27-9)でも、NAT を使用して、Cisco UMA サーバのプライベート アドレスを非表示にできます。

シナリオ 2(図 27-9)では、ファイアウォールが着信トラフィックのワイルドカード ピンホールを開く必要がないように、PAT を使用して、すべてのクライアント トラフィックを 1 つの送信元 IP に統合できます。

hostname(config)# access-list cumc extended permit tcp any host 172.16.27.41 eq 5443
 

および

hostname(config)# access-list cumc extended permit tcp host 192.0.2.183 host 172.16.27.41 eq 5443

Cisco UMA 配置の信頼関係の確立

Cisco UMC クライアントとセキュリティ アプライアンス間の信頼関係を確立するために、セキュリティ アプライアンスは Cisco UMA サーバ証明書とキー ペアを使用するか、Cisco UMA サーバの FQDN を使用して証明書を取得します(証明書の偽装)。セキュリティ アプライアンスと Cisco UMA サーバ間では、セキュリティ アプライアンスと Cisco UMA サーバは、自己署名証明書か、ローカル認証局によって発行された証明書を使用します。

図 27-10 に、Cisco UMA サーバ証明書をセキュリティ アプライアンスにインポートする方法を示します。Cisco UMA サーバがすでにサードパーティの CA に登録されている場合は、秘密キーのある証明書をセキュリティ アプライアンスにインポートできます。その後、セキュリティ アプライアンスには、Cisco UMA サーバの完全な証明書が付与されます。Cisco UMA クライアントが Cisco UMA サーバに接続すると、セキュリティ アプライアンスはハンドシェイクを代行受信し、Cisco UMA サーバ証明書を使用してクライアントとのハンドシェイクを実行します。セキュリティ アプライアンスは、サーバとのハンドシェイクも実行します。

図 27-10 セキュリティ アプライアンスが Cisco UMA を表す方法:秘密キーの共有

 

 

図 27-11 に、信頼関係を確立するための別の方法を示します。配置の各コンポーネントは新たにインストールされたため、図 27-11 は新規の配置を示しています。セキュリティ アプライアンスは、セキュリティ アプライアンスが Cisco UMA サーバであるかのように、Cisco UMA サーバの FQDN を使用してサードパーティの CA に登録します。Cisco UMA クライアントがセキュリティ アプライアンスに接続すると、セキュリティ アプライアンスは、Cisco UMA サーバの FQDN がある証明書を提示します。Cisco UMA クライアントは、Cisco UMA サーバと通信していると考えます。

図 27-11 セキュリティ アプライアンスが Cisco UMA を表す方法:証明書の偽装

 

セキュリティ アプライアンスと Cisco UMA サーバ間の信頼関係は、自己署名証明書を使用して確立できます。セキュリティ アプライアンスの ID 証明書がエクスポートされ、次に Cisco UMA サーバのトラストストアにアップロードされます。トラストポイントを作成して、 crypto ca authenticate コマンドを使用することによって、Cisco UMA サーバ証明書がダウンロードされ、次にセキュリティ アプライアンス トラストストアにアップロードされます。

Cisco Unified Mobility のセキュリティ アプライアンスの設定

図 27-8図 27-9 に示すように、セキュリティ アプライアンスが TLS プロキシと MMP の検査を実行するよう設定するには、次の手順を実行します。セキュリティ アプライアンスと Cisco UMA サーバ間で自己署名証明書が使用されることが想定されています。


ステップ 1 次のコマンドを入力して、Cisco UMA サーバのスタティック NAT を作成します。

hostname(config)# static (real_ifc,mapped_ifc) mapped_ip real_ip netmask mask
 

ステップ 2 Cisco UMA サーバ証明書と PKCS-12 形式のキー ペアをエクスポートします。これをセキュリティ アプライアンスにインポートします。証明書は、Cisco UMA クライアントとのハンドシェイク中に使用されます。

hostname(config)# crypto ca import trustpoint pkcs12 passphrase
[paste base 64 encoded pkcs12]
hostname(config)# quit
 

ステップ 3 Cisco UMA サーバの自己署名証明書をセキュリティ アプライアンス トラストストアにインストールします。この手順は、セキュリティ アプライアンスがセキュリティ アプライアンス プロキシと Cisco UMA サーバ間のハンドシェイク中に Cisco UMA サーバを認証するために必要です。

hostname(config)# crypto ca trustpoint trustpoint_name
hostname(config-ca-trustpoint)# enrollment terminal
hostname(config-ca-trustpoint)# exit
hostname(config)# crypto ca authenticate trustpoint
hostname(config)# Enter the base 64 encoded CA certificate.
hostname(config)# End with a blank line or the word "quit" on a line by itself
[ certificate data omitted ]
hostname(config)# quit
 

ステップ 4 Cisco UMA サーバに接続されている Cisco UMA クライアントの TLS プロキシ インスタンスを作成します。

hostname(config)# tls-proxy proxy_name
hostname(config-tlsp)# server trust-point proxy_name
hostname(config-tlsp)# client trust-point proxy_name
hostname(config-tlsp)# no server authenticate-client
hostname(config-tlsp)# client cipher-suite cipher_suite
 

ステップ 5 TLS プロキシで MMP 検査をイネーブルにします。

hostname(config)# class-map class_map_name
hostname(config-cmap)# match port tcp eq port
hostname(config-cmap)# exit
hostname(config)# policy-map name
hostname(config-pmap)# class name
hostname(config-pmap)# inspect mmp tls-proxy proxy_name
hostname(config-pmap)# exit
hostname(config)# service-policy policy_map_name global
 


 

Cisco Unified Mobility のデバッグ

モビリティ プロキシは、IP テレフォニーと同じ方法でデバッグできます。TLS プロキシ接続の問題をデバッグするために、SSL の syslog とともに TLS プロキシのデバッグ フラグをイネーブルにできます。

たとえば、TLS プロキシ関連のデバッグと syslog 出力だけをイネーブルにするには、次のコマンドを入力します。

hostname# debug inspect tls-proxy events
hostname# debug inspect tls-proxy errors
hostname# config terminal
hostname(config)# logging enable
hostname(config)# logging timestamp
hostname(config)# logging list loglist message 711001
hostname(config)# logging list loglist message 725001-725014
hostname(config)# logging list loglist message 717001-717038
hostname(config)# logging buffer-size 1000000
hostname(config)# logging buffered loglist
hostname(config)# logging debug-trace
 

TLS プロキシのデバッグ手法と出力例については、 「暗号化音声検査の TLS プロキシ」 を参照してください。

MMP 検査エンジンのデバッグを行うために debug mmp コマンドをイネーブルにします。

MMP:: received 60 bytes from outside:1.1.1.1/2000 to inside:2.2.2.2/5443
MMP:: version OLWP-2.0
MMP:: forward 60/60 bytes from outside:1.1.1.1/2000 to inside:2.2.2.2/5443
MMP:: received 100 bytes from inside:2.2.2.2/5443 to outside:1.1.1.1/2000
MMP:: session-id: ABCD_1234
MMP:: status: 201
MMP:: forward 100/100 bytes from inside:2.2.2.2/5443 to outside 1.1.1.1/2000
MMP:: received 80 bytes from outside:1.1.1.1/2000 to inside:2.2.2.2/5443
MMP:: content-type: http/1.1
MMP:: content-length: 40
 

次のコマンドを入力して、TLS プロキシによって未加工データと復号化されたデータを取得することもできます。

hostname# capture mycap interface outside (capturing raw packets)
hostname# capture mycap-dec type tls-proxy interface outside (capturing decrypted data)
hostname# show capture capture_name
hostname# copy /pcap capture:capture_name tftp://tftp_location
 

Cisco Unified Presence

この項は、次の内容で構成されています。

「Cisco Unified Presence のアーキテクチャ」

「Cisco Unified Presence のプレゼンス フェデレーション プロキシの設定」

「Cisco Unified Presence のセキュリティ アプライアンスのデバッグ」

Cisco Unified Presence のアーキテクチャ

図 27-12 は、プレゼンス フェデレーション プロキシ(TLS プロキシとして実装)としてのセキュリティ アプライアンスがある Cisco Unified Presence と LCS フェデレーション シナリオを示しています。TLS 接続がある 2 つのエンティティは、企業 X の「ルーティング プロキシ」(専用の Cisco UP)と、企業 Y の Microsoft アクセス プロキシです。ただし、配置はこのシナリオに限定されているわけではありません。任意の Cisco UP または Cisco UP クラスタをセキュリティ アプライアンスの左側に配置でき、リモート エンティティは任意のサーバ(LCS、OCS、または別の Cisco UP)にすることができます。

次のアーキテクチャは、TLS 接続で SIP(またはセキュリティ アプライアンスで検査された他のプロトコル)を使用する 2 つのサーバに共通です。

エンティティ X:企業 X における Cisco UP とルーティング プロキシ

エンティティ Y:企業 Y における LCS と OCS の Microsoft のアクセス プロキシとエッジ サーバ

図 27-12 一般的な Cisco Unified Presence と LCS フェデレーション シナリオ

 

上のアーキテクチャでは、セキュリティ アプライアンスはファイアウォール、NAT、および TLS プロキシとして機能します。これは推奨されるアーキテクチャです。ただし、セキュリティ アプライアンスは、単独で NAT と TLS プロキシとしても機能でき、既存のファイアウォールと連動します。

いずれかのサーバは、TLS ハンドシェイクを開始できます(クライアントだけが TLS ハンドシェイクを開始する IP テレフォニーまたは Cisco Unified Mobility とは異なります)。双方向の TLS プロキシの規則と設定があります。各企業は、セキュリティ アプライアンスを TLS プロキシとして使用できます。

図 27-12 では、NAT または PAT を使用して、エンティティ X のプライベート アドレスを非表示にできます。この状況では、外部サーバ(エンティティ Y)が開始した接続または TLS ハンドシェイク(着信)に対してスタティック NAT または PAT を設定する必要があります。通常、パブリック ポートは 5061 にする必要があります。着信接続を受け入れる Cisco UP では、次のスタティック PAT コマンドが必要です。

hostname(config)# static (inside,outside) tcp 192.0.2.1 5061 10.0.0.2 5061 netmask 255.255.255.255
 

(SIP SUBSCRIBE を送信することによって)外部サーバへの接続を開始する可能性がある Cisco UP ごとに、次のスタティック PAT を設定する必要があります。

アドレスが 10.0.0.2 の Cisco UP では、次のコマンドを入力します。

hostname(config)# static (inside,outside) tcp 192.0.2.1 5062 10.0.0.2 5062 netmask 255.255.255.255
hostname(config)# static (inside,outside) udp 192.0.2.1 5070 10.0.0.2 5070 netmask 255.255.255.255
hostname(config)# static (inside,outside) tcp 192.0.2.1 5060 10.0.0.2 5060 netmask 255.255.255.255
 

アドレスが 10.0.0.3 の別の Cisco UP では、45062 または 45070 などの異なる PAT ポート セットを使用する必要があります。

hostname(config)# static (inside,outside) tcp 192.0.2.1 45061 10.0.0.3 5061 netmask 255.255.255.255
hostname(config)# static (inside,outside) tcp 192.0.2.1 45062 10.0.0.3 5062 netmask 255.255.255.255
hostname(config)# static (inside,outside) udp 192.0.2.1 45070 10.0.0.3 5070 netmask 255.255.255.255
hostname(config)# static (inside,outside) tcp 192.0.2.1 5070 10.0.0.2 5070 netmask 255.255.255.255
hostname(config)# static (inside,outside) tcp 192.0.2.1 45060 10.0.0.3 5060 netmask 255.255.255.255
 

残りの発信接続または TLS ハンドシェイクにはダイナミック NAT または PAT を使用できます。セキュリティ アプライアンス SIP 検査エンジンは、必要な変換(フィックスアップ)を行います。

hostname(config)# global (outside) 102 192.0.2.1 netmask 255.255.255.255
hostname(config)# nat (inside) 102 0.0.0.0 0.0.0.0
 

図 27-13 は、セキュリティ アプライアンスでプレゼンス フェデレーション プロキシを介してエンティティ Y に接続されているエンティティ X のシナリオの要約を示しています。プロキシは、エンティティ X と同じ管理ドメイン内にあります。エンティティ Y には、プロキシとして別のセキュリティ アプライアンスがありますが、これは簡素化のために省略されています。

図 27-13 2 つのサーバ エンティティ間のプレゼンス フェデレーション プロキシ シナリオの要約

 

 

セキュリティ アプライアンスが証明書を保持している場合にエンティティ X のドメイン名を正しく解決するために、エンティティ X の NAT を実行するようセキュリティ アプライアンスを設定できます。ドメイン名は、セキュリティ アプライアンスがプロキシ サービスを提供するエンティティ X のパブリック アドレスとして解決されます。

プレゼンス フェデレーションでの信頼関係の確立

企業内では、自己署名証明書を使用して信頼関係を設定するか、内部 CA で設定することができます。

企業間または管理ドメイン間で信頼関係を確立することが、フェデレーションの鍵となります。企業間では、信頼できるサードパーティの CA(VeriSign など)を使用する必要があります。セキュリティ アプライアンスは、Cisco UP の FQDN を使用して証明書を取得します(証明書の偽装)。

TLS ハンドシェイクでは、2 つのエンティティは、信頼できるサードパーティの認証局に対する証明書チェーンによってピア証明書を検証できます。どちらのエンティティも CA に登録します。TLS プロキシとしてのセキュリティ アプライアンスは、両方のエンティティによって信頼されている必要があります。セキュリティ アプライアンスは、常にいずれかの企業に関連付けられています。その企業(図 27-12 では企業 X)内で、エンティティとセキュリティ アプライアンスは、ローカル CA または自己署名証明書を使用して相互に認証できます。

セキュリティ アプライアンスとリモート エンティティ(エンティティ Y)間の信頼関係を確立するには、セキュリティ アプライアンスは、エンティティ X(Cisco UP)の代わりに CA に登録できます。登録要求では、エンティティ X の ID(ドメイン名)が使用されます。

図 27-14 に、信頼関係の確立方法を示します。セキュリティ アプライアンスは、セキュリティ アプライアンスが Cisco UP であるかのように、Cisco UP の FQDN を使用してサードパーティの CA に登録します。

図 27-14 セキュリティ アプライアンスが Cisco Unified Presence を表す方法:証明書の偽装

 

Cisco UP とセキュリティ アプライアンス間のセキュリティ証明書の交換に関する概要

セキュリティ アプライアンスによって使用される証明書のキー ペア( cup_proxy_key など)を生成して、TLS ハンドシェイクでセキュリティ アプライアンスによって Cisco UP に送信される自己署名証明書( cup_proxy など)を識別するためのトラストポイントを設定する必要があります。

セキュリティ アプライアンスが Cisco UP 証明書を信頼するには、Cisco UP からの証明書( cert_from_cup など)を識別するトラストポイントを作成して、登録タイプに端末を指定して、Cisco UP から受け取った証明書を端末に貼り付けることを示す必要があります。

Cisco Unified Presence のプレゼンス フェデレーション プロキシの設定

ローカル ドメイン内にある単一の Cisco UP が存在し、Cisco UP とセキュリティ アプライアンス間で自己署名証明書が使用される Cisco Unified Presence と LCS フェデレーション シナリオ(図 27-12 に示したシナリオと似たもの)を、TLS プロキシとしてセキュリティ アプライアンスを使用して設定するには、次の手順を実行します。


ステップ 1 Cisco UP が含まれているローカル ドメインの次のスタティック NAT を作成します。

Cisco UP が含まれているローカル ドメインへの着信接続の場合は、次のコマンドを入力して、スタティック PAT を作成します。

hostname(config)# static (real_ifc,mapped_ifc) tcp mapped_ip mapped_port netmask mask
 

) (SIP SUBSCRIBE を送信することによって)外部サーバへの接続を開始する可能性がある Cisco UP ごとに、異なる PAT ポート セットを使用してスタティック PAT も設定する必要があります。


発信接続または TLS ハンドシェイクの場合は、ダイナミック NAT または PAT を使用します。セキュリティ アプライアンス SIP 検査エンジンは、必要な変換(フィックスアップ)を行います。

hostname(config)# global (mapped_ifc) nat_id mapped_ip netmask mask
hostname(config)# nat (real_ifc) nat_id real_ip mask
 

ステップ 2 次のコマンドを入力して、必要な RSA キー ペアを作成します。

hostname(config)# crypto key generate rsa label key-pair-label modulus size
 

キー ペアは、Cisco UP(リモート エンティティのプロキシ)が含まれているローカル ドメインに提示される自己署名証明書によって使用されます。

ステップ 3 次のコマンドを入力して、リモート エンティティのプロキシ証明書(自己署名証明書)を作成します。

hostname(config)# crypto ca trustpoint trustpoint_name
hostname(config-ca-trustpoint)# enrollment self
hostname(config-ca-trustpoint)# fqdn none
hostname(config-ca-trustpoint)# subject-name X.500_name
hostname(config-ca-trustpoint)# keypair keyname
hostname(config-ca-trustpoint)# exit
hostname(config)# crypto ca enroll trustpoint
 

証明書は、ローカル エンティティのトラストストアにインストールします。ローカル エンティティによって信頼されているローカル CA に証明書を登録することもできます。

ステップ 4 ステップ 3 で作成したセキュリティ アプライアンスの自己署名証明書をエクスポートして、信頼できる証明書としてローカル エンティティにインストールします。これは、ローカル エンティティがセキュリティ アプライアンスを認証するために必要なステップです。

次のコマンドを入力して、セキュリティ アプライアンスの自己署名(ID)証明書をエクスポートします。

hostname(config)# crypto ca export trustpoint identity-certificate
 

ステップ 5 次のコマンドを入力して、ローカル エンティティの証明書をエクスポートして、セキュリティ アプライアンスにインストールします。これは、ハンドシェイク中にセキュリティ アプライアンスがローカル エンティティを認証するために必要なステップです。ローカル エンティティが自己署名証明書を使用する場合は、その自己署名証明書をインストールする必要があります。ローカル エンティティが CA によって発行された証明書を使用する場合は、CA 証明書をインストールする必要があります。次の設定は、自己署名証明書を使用するためのコマンドを示しています。

hostname(config)# crypto ca trustpoint trustpoint_name
hostname(config-ca-trustpoint)# enrollment terminal
hostname(config-ca-trustpoint)# exit
hostname(config)# crypto ca authenticate trustpoint
hostname(config)# Enter the base 64 encoded CA certificate.
hostname(config)# End with a blank line or the word "quit" on a line by itself
[ certificate data omitted ]
hostname(config)# quit
 

ステップ 6 リモート エンティティによって信頼されているプロキシ証明書をセキュリティ アプライアンスで作成するには、信頼できる CA から証明書を取得します。信頼できる CA からの証明書の取得については、「証明書の設定」を参照してください。

ステップ 7 次のコマンドを入力して、リモート エンティティの証明書に署名する CA 証明書をセキュリティ アプライアンスにインストールします。これは、セキュリティ アプライアンスがリモート エンティティを認証するために必要な手順です。

hostname(config)# crypto ca trustpoint trustpoint_name
hostname(config-ca-trustpoint)# enrollment terminal
hostname(config-ca-trustpoint)# exit
hostname(config)# crypto ca authenticate trustpoint
hostname(config)# Enter the base 64 encoded CA certificate.
hostname(config)# End with a blank line or the word "quit" on a line by itself
[ certificate data omitted ]
hostname(config)# quit
 

ステップ 8 ローカル エンティティが開始した接続とリモート エンティティが作成した接続ごとに TLS プロキシ インスタンスを作成します。TLS 接続を開始するエンティティには、「TLS クライアント」の役割が割り当てられています。TLS プロキシでは、「クライアント」と「サーバ」プロキシが厳密に定義されているため、いずれかのエンティティが接続を開始する可能性がある場合は、2 つの TLS プロキシ インスタンスを定義する必要があります。

! Local entity to remote entity
hostname(config)# tls-proxy proxy_name
hostname(config-tlsp)# server trust-point proxy_name
hostname(config-tlsp)# client trust-point proxy_trustpoint
hostname(config-tlsp)# client cipher-suite cipher_suite
 

ここで、 server trust-point コマンドの proxy_name はリモート エンティティ プロキシ名で、 client trust-point コマンドの proxy_trustpoint はローカル エンティティ プロキシです。

! Remote entity to local entity
hostname(config)# tls-proxy proxy_name
hostname(config-tlsp)# server trust-point proxy_name
hostname(config-tlsp)# client trust-point proxy_trustpoint
hostname(config-tlsp)# client cipher-suite cipher_suite
 

ここで、 server trust-point コマンドの proxy_name はローカル エンティティ プロキシ名で、 client trust-point コマンドの proxy_trustpoint はリモート エンティティ プロキシです。

ステップ 9 次のコマンドを入力して、SIP 検査の TLS プロキシをイネーブルにして、接続を開始する可能性がある両方のエンティティについてポリシーを定義します。

hostname(config)# access-list id extended permit tcp host src_ip host dest_ip eq port
hostname(config)# class-map class_map_name
hostname(config-cmap)# match access-list access_list_name
hostname(config-cmap)# exit
hostname(config)# policy-map type inspect sip policy_map_name
hostname(config-pmap)# parameters
! SIP inspection parameters
hostname(config-pmap)# exit
hostname(config)# policy-map name
hostname(config-pmap)# class name
hostname(config-pmap)# inspect sip sip_map tls-proxy proxy_name
hostname(config-pmap)# exit
hostname(config)# service-policy policy_map_name global
 

ここで、 policy-map コマンドの name は、グローバル ポリシー マップの名前です。


 

Cisco Unified Presence のセキュリティ アプライアンスのデバッグ

デバッグは、IP テレフォニーの TLS プロキシのデバッグと似ています。TLS プロキシ接続の問題をデバッグするために、SSL の syslog とともに TLS プロキシのデバッグ フラグをイネーブルにできます。

たとえば、TLS プロキシ関連のデバッグと syslog 出力だけをイネーブルにするには、次のコマンドを入力します。

hostname(config)# debug inspect tls-proxy events
hostname(config)# debug inspect tls-proxy errors
hostname(config)# logging enable
hostname(config)# logging timestamp
hostname(config)# logging list loglist message 711001
hostname(config)# logging list loglist message 725001-725014
hostname(config)# logging list loglist message 717001-717038
hostname(config)# logging buffer-size 1000000
hostname(config)# logging buffered loglist
hostname(config)# logging debug-trace
 

TLS プロキシのデバッグ手法と出力例については、 「暗号化音声検査の TLS プロキシ」 を参照してください。

SIP 検査エンジンのデバッグを行うために debug sip コマンドをイネーブルにします。『 Cisco Security Appliance Command Reference 』を参照してください。

さらに、次のコマンドを入力して、TLS プロキシによって未加工データと復号化されたデータを取得することもできます。

hostname# capture mycap interface outside (capturing raw packets)
hostname# capture mycap-dec type tls-proxy interface outside (capturing decrypted data)
hostname# show capture capture_name
hostname# copy /pcap capture:capture_name tftp://tftp_location

Cisco Unified Communications プロキシ機能の設定例

この項は、次の内容で構成されています。

「フォン プロキシの設定例」

「Cisco Unified Mobility の設定例」

「Cisco Unified Presence 設定例」

例 1:Publisher でのノンセキュア Cisco UCM クラスタ、Cisco UCM、および TFTP サーバ

図 27-15 に、次のトポロジを使用したノンセキュア Cisco UCM クラスタの設定例を示します。

図 27-15 Publisher でのノンセキュア Cisco UCM クラスタ、Cisco UCM、および TFTP サーバ

 

 

static (inside,outside) 10.10.0.26 192.0.2.101
access-list pp extended permit udp any host 10.10.0.26 eq 69
access-group pp in interface outside
crypto key generate rsa label cucmtftp_kp modulus 1024
crypto ca trustpoint cucm_tftp_server
enrollment self
keypair cucmtftp_kp
crypto ca enroll cucm_tftp_server
ctl-file myctl
record-entry cucm-tftp trustpoint cucm_tftp_server address 10.10.0.26
no shutdown
tls-proxy mytls
server trust-point _internal_PP_myctl
phone-proxy mypp
media-termination address 192.0.2.25
tftp-server address 192.0.2.101 interface inside
tls-proxy mytls
ctl-file myctl
class-map sec_sccp
match port tcp 2443
class-map sec_sip
match port tcp eq 5061
policy-map pp_policy
class sec_sccp
inspect skinny phone-proxy mypp
class sec_sip
inspect sip phone-proxy mypp
service-policy pp_policy interface outside

例 2:Publisher での混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバ

図 27-16 に、次のトポロジを使用した混合モードの Cisco UCM クラスタの設定例を示します。

図 27-16 Publisher での混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバ

 

static (inside,outside) 10.10.0.26 192.0.2.101
access-list pp extended permit udp any host 10.10.0.26 eq 69
access-group pp in interface outside
crypto key generate rsa label cucmtftp_kp modulus 1024
crypto ca trustpoint cucm_tftp_server
enrollment self
keypair cucmtftp_kp
crypto ca enroll cucm_tftp_server
ctl-file myctl
record-entry cucm-tftp trustpoint cucm_tftp_server address 10.10.0.26
no shutdown
crypto key generate rsa label ldc_signer_key modulus 1024
crypto key generate rsa label phone_common modulus 1024
crypto ca trustpoint ldc_server
enrollment self
proxy_ldc_issuer
fqdn my-ldc-ca.exmaple.com
subject-name cn=FW_LDC_SIGNER_172_23_45_200
keypair ldc_signer_key
crypto ca enroll ldc_server
tls-proxy my_proxy
server trust-point _internal_PP_myctl
client ldc issuer ldc_server
client ldc keypair phone_common
client cipher-suite aes128-sha1 aes256-sha1
phone-proxy mypp
media-termination address 10.10.0.25
tftp-server address 192.0.2.101 interface inside
tls-proxy mytls
ctl-file myctl
cluster-mode mixed
class-map sec_sccp
match port tcp 2443
class-map sec_sip
match port tcp eq 5061
policy-map pp_policy
class sec_sccp
inspect skinny phone-proxy mypp
class sec_sip
inspect sip phone-proxy mypp
service-policy pp_policy interface outside

例 3:別のサーバでの混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバ

図 27-17 に、次のトポロジを使用した混合モードの Cisco UCM クラスタの設定例を示します。このトポロジでは、TFTP サーバは、Cisco UCM とは別のサーバ上にあります。

この例では、TFTP サーバのスタティック インターフェイス PAT は、セキュリティ アプライアンスの外部インターフェイス IP アドレスのように表示されるよう設定されています。

図 27-17 別のサーバでの混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバ

 

static (inside,outside) 10.10.0.26 192.0.2.105
static (inside,outside) udp interface 69 192.0.2.101 69
access-list pp extended permit udp any host 10.10.0.24 eq 69
access-group pp in interface outside
crypto key generate rsa label cucm_kp modulus 1024
crypto ca trustpoint cucm
enrollment self
keypair cucm_kp
crypto ca enroll cucm
crypto key generate rsa label tftp_kp modulus 1024
crypto ca trustpoint tftp_server
enrollment self
keypair tftp_kp
crypto ca enroll tftp_server
ctl-file myctl
record-entry cucm trustpoint cucm_server address 10.10.0.26
no shutdown
crypto key generate rsa label ldc_signer_key modulus 1024
crypto key generate rsa label phone_common modulus 1024
crypto ca trustpoint ldc_server
enrollment self
proxy_ldc_issuer
fqdn my-ldc-ca.exmaple.com
subject-name cn=FW_LDC_SIGNER_172_23_45_200
keypair ldc_signer_key
crypto ca enroll ldc_server
tls-proxy my_proxy
server trust-point _internal_PP_myctl
client ldc issuer ldc_server
client ldc keypair phone_common
client cipher-suite aes128-sha1 aes256-sha1
phone-proxy mypp
media-termination address 10.10.0.25
tftp-server address 192.0.2.101 interface inside
tls-proxy mytls
ctl-file myctl
cluster-mode mixed
class-map sec_sccp
match port tcp 2443
class-map sec_sip
match port tcp eq 5061
policy-map pp_policy
class sec_sccp
inspect skinny phone-proxy mypp
class sec_sip
inspect sip phone-proxy mypp
service-policy pp_policy interface outside

例 4:別のサーバでの混合モードの Cisco UCM クラスタ、プライマリ Cisco UCM、セカンダリ、および TFTP サーバ

図 27-18 に、次のトポロジを使用した混合モードの Cisco UCM クラスタの設定例を示します。このトポロジでは、TFTP サーバは、プライマリおよびセカンダリの Cisco UCM とは別のサーバ上にあります。

この例では、TFTP サーバのスタティック インターフェイス PAT は、セキュリティ アプライアンスの外部インターフェイス IP アドレスのように表示されるよう設定されています。

図 27-18 別のサーバでの混合モードの Cisco UCM クラスタ、プライマリ Cisco UCM、セカンダリ Cisco UCM、および TFTP サーバ

 

 

static (inside,outside) 10.10.0.27 192.0.2.105
static (inside,outside) 10.10.0.26 192.0.2.106
static (inside,outside) udp interface 69 192.0.2.101 69
access-list pp extended permit udp any host 10.10.0.24 eq 69
access-group pp in interface outside
crypto key generate rsa label cluster_kp modulus 1024
crypto ca trustpoint pri_cucm
enrollment self
keypair cluster_kp
crypto ca enroll pri_cucm
crypto ca trustpoint sec_cucm
enrollment self
serial-number
keypair cluster_kp
crypto ca enroll sec_cucm
crypto ca trustpoint tftp_server
enrollment self
fqdn my_tftp.example.com
keypair cluster_kp
crypto ca enroll tftp_server
ctl-file myctl
record-entry tftp trustpoint tftp_server address 10.10.0.24
record-entry cucm trustpoint pri_cucm_server address 10.10.0.27
record-entry cucm trustpoint sec_cucm_server address 10.10.0.2
no shutdown
crypto key generate rsa label ldc_signer_key modulus 1024
crypto key generate rsa label phone_common modulus 1024
crypto ca trustpoint ldc_server
enrollment self
proxy_ldc_issuer
fqdn my-ldc-ca.exmaple.com
subject-name cn=FW_LDC_SIGNER_172_23_45_200
keypair ldc_signer_key
crypto ca enroll ldc_server
tls-proxy my_proxy
server trust-point _internal_PP_myctl
client ldc issuer ldc_server
client ldc keypair phone_common
client cipher-suite aes128-sha1 aes256-sha1
phone-proxy mypp
media-termination address 10.10.0.25
tftp-server address 192.0.2.101 interface inside
tls-proxy mytls
ctl-file myctl
cluster-mode mixed
class-map sec_sccp
match port tcp 2443
class-map sec_sip
match port tcp eq 5061
policy-map pp_policy
class sec_sccp
inspect skinny phone-proxy mypp
class sec_sip
inspect sip phone-proxy mypp
service-policy pp_policy interface outside

例 5:Publisher での混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバでの LSC プロビジョニング

図 27-19 に、次のトポロジを使用した、LSC プロビジョニングが必要な混合モードの Cisco UCM クラスタの設定例を示します。


) リモートの IP 電話の LSC プロビジョニングを行うことは推奨されません。これは、IP 電話を最初に登録しなければならず、ノンセキュア モードで登録する必要があるためです。IP 電話をノンセキュア モードで登録する場合に、管理者がセキュリティ アプライアンスで SIP と SCCP のノンセキュア シグナリング ポートを開かなければなりません。可能な場合は、LSC プロビジョニングは、エンド ユーザに IP 電話を提供する前に企業ネットワーク内で行う必要があります。


この例では、LSC プロビジョニングのために SIP、SCCP、および CAPF ポートのノンセキュア ポートを開いて、IP 電話が TFTP サーバに接続して、IP 電話をノンセキュア モードで接続できるようにするアクセス リストを作成します。

さらに、Cisco UCM 証明書管理ソフトウェアから CAPF 証明書をコピーして貼り付けることで、CAPF トラストポイントを作成します。

図 27-19 Publisher での混合モードの Cisco UCM クラスタ、Cisco UCM、および TFTP サーバでの LSC プロビジョニング

 

static (inside,outside) 10.10.0.26 192.0.2.105
static (inside,outside) udp interface 69 192.0.2.101 69
access-list pp extended permit udp any host 10.10.0.24 eq 69
access-list pp extended permit tcp any host 10.10.0.26 eq 2000
access-list pp extended permit tcp any host 10.10.0.26 eq 5060
access-list pp extended permit tcp any host 10.10.0.26 eq 3804
access-group pp in interface outside
crypto key generate rsa label cluster_kp modulus 1024
crypto ca trustpoint cucm
enrollment self
keypair cluster_kp
crypto ca enroll cucm
crypto ca trustpoint tftp_server
enrollment self
serial-number
keypair cluster_kp
crypto ca enroll tftp_server
crypto ca trustpoint capf
enroll terminal
crypto ca authenticate capf
ctl-file myctl
record-entry cucm trustpoint cucm_server address 10.10.0.26
record-entry capf trustpoint capf address 10.10.0.26
no shutdown
crypto key generate rsa label ldc_signer_key modulus 1024
crypto key generate rsa label phone_common modulus 1024
crypto ca trustpoint ldc_server
enrollment self
proxy_ldc_issuer
fqdn my-ldc-ca.exmaple.com
subject-name cn=FW_LDC_SIGNER_172_23_45_200
keypair ldc_signer_key
crypto ca enroll ldc_server
tls-proxy my_proxy
server trust-point _internal_PP_myctl
client ldc issuer ldc_server
client ldc keypair phone_common
client cipher-suite aes128-sha1 aes256-sha1
phone-proxy mypp
media-termination address 10.10.0.25
tftp-server address 192.0.2.101 interface inside
tls-proxy mytls
ctl-file myctl
cluster-mode mixed
class-map sec_sccp
match port tcp 2443
class-map sec_sip
match port tcp eq 5061
policy-map pp_policy
class sec_sccp
inspect skinny phone-proxy mypp
class sec_sip
inspect sip phone-proxy mypp
service-policy pp_policy interface outside

例 6:VLAN トランスバーサル

図 27-20 に、Cisco IP Communicator(CIPC)ソフトフォンが音声とデータ VLAN シナリオで配置されている場合に、CIPC ソフトフォンに強制的に認証済みモードで動作させるための設定例を示します。VLAN トランスバーサルは、データ VLAN 上の CIPC ソフトフォンと音声 VLAN 上のハード フォン間で必要です。

この例では、Cisco UCM クラスタのモードはノンセキュアです。

この例では、LSC プロビジョニングのために SIP、SCCP、および CAPF ポートのノンセキュア ポートを開いて、IP 電話が TFTP サーバに接続して、IP 電話をノンセキュア モードで接続できるようにするアクセス リストを作成します。

この例では、それぞれの CIPC が音声 VLAN 内の IP アドレス スペースにマップされるように、PAT を使用して CIPC の NAT を設定します。

さらに、Cisco UCM 証明書管理ソフトウェアから CAPF 証明書をコピーして貼り付けることで、CAPF トラストポイントを作成します。


) Cisco IP Communicator では認証済みモードだけがサポートされ、暗号化済みモードはサポートされません。そのため、CIPC ソフトフォンから流れる暗号化済みの音声トラフィック(SRTP)はありません。


CIPC が遠隔地にあるコンピュータにインストールされている場合は、フォン プロキシと CIPC はサポートされません。これらのコンピュータからのコールはインターネットを通過し、セキュリティ アプライアンスで終了して、適応型セキュリティ アプライアンスの背後のネットワーク上にある IP 電話に到達します。セキュリティ アプライアンスの背後にある IP 電話に到達するには、CIPC がインストールされているコンピュータがネットワーク上になければなりません。

図 27-20 データ VLAN 上の CIPC ソフトフォンと音声 VLAN 上のハード フォン間の VLAN トランスバーサル

 

 

static (voice,data) 10.130.50.5 192.0.2.101
nat (data) 101 10.130.50.0 255.255.255.0 outside
global (voice) 101 192.0.2.10
access-list pp extended permit udp any host 10.130.50.5 eq 69
access-list pp extended permit tcp any host 10.130.50.5 eq 2000
access-list pp extended permit tcp any host 10.130.50.5 eq 5060
access-list pp extended permit tcp any host 10.130.50.5 eq 3804
access-group pp in interface data
crypto ca generate rsa label cucmtftp_kp modulus 1024
crypto ca trustpoint cucm_tftp_server
enrollment self
keypair cucmtftp_kp
crypto ca enroll cucm_tftp_server
crypto ca trustpoint capf
enrollment terminal
crypto ca authenticate capf
ctl-file myctl
record-entry cucm-tftp trustpoint cucm_tftp_server address 10.130.50.5
record-entry capf trustpoint capf address 10.130.50.5
no shutdown
tls-proxy mytls
server trust-point _internal_PP_myctl
phone-proxy mypp
media-termination address 10.130.50.2
tftp-server address 10.10.0.20 interface inside
tls-proxy mytls
ctl-file myctl
cipc security-mode authenticated
class-map sec_sccp
match port tcp eq 2443
class-map sec_sip
match port tcp eq 5061
policy-map pp_policy
class sec_sccp
inspect skinny phone-proxy mypp
class sec_sip
inspect sip phone-proxy mypp
service-policy pp_policy interface data

Cisco Unified Mobility の設定例

この項は、次の内容で構成されています。

「例 1:Cisco UMC と Cisco UMA のアーキテクチャ:TLS プロキシと MMP 検査を備えたファイアウォールとしてのセキュリティ アプライアンス」

「例 2:Cisco UMC および Cisco UMA アーキテクチャ:TLS プロキシとしてだけのセキュリティ アプライアンス」

ここでは、Cisco Unified Mobility ソリューションで使用される TLS プロキシの 2 つの導入シナリオ(セキュリティ アプライアンスがファイアウォールと TLS プロキシの両方として機能するシナリオ 1 と、セキュリティ アプライアンスが TLS プロキシとしてだけ機能するシナリオ 2)に適用される設定例について説明します。どちらのシナリオでも、クライアントはインターネットから接続します。

例では、Cisco UMA サーバ証明書と PKCS-12 形式のキー ペアをエクスポートして、セキュリティ アプライアンスにインポートします。証明書は、Cisco UMA クライアントとのハンドシェイク中に使用されます。

セキュリティ アプライアンス プロキシと Cisco UMA サーバ間のハンドシェイク中にセキュリティ アプライアンスが Cisco UMA サーバを認証するには、Cisco UMA サーバの自己署名証明書をセキュリティ アプライアンスのトラストストアにインストールする必要があります。Cisco UMA サーバに接続されている Cisco UMA クライアントの TLS プロキシ インスタンスを作成します。最後に、TLS プロキシで MMP 検査をイネーブルにする必要があります。

例 1:Cisco UMC と Cisco UMA のアーキテクチャ:TLS プロキシと MMP 検査を備えたファイアウォールとしてのセキュリティ アプライアンス

図 27-21(シナリオ 1:推奨されるアーキテクチャ)に示すように、セキュリティ アプライアンスはファイアウォールと TLS プロキシの両方として機能します。シナリオ 1 の導入では、セキュリティ アプライアンスは Cisco UMA クライアントと Cisco UMA サーバ間にあります。このシナリオでは、セキュリティ アプライアンスは、Cisco UMA サーバ 10.1.1.2 の IP アドレスを 192.0.2.140 に変換することによって、スタティック NAT を実行します。

図 27-21 Cisco UMC と Cisco UMA のアーキテクチャ:シナリオ 1:TLS プロキシと MMP 検査を備えたファイアウォールとしてのセキュリティ アプライアンス

 

static (inside,outside) 192.0.2.140 10.1.1.2 netmask 255.255.255.255
crypto ca import cuma_proxy pkcs12 sample_passphrase
<cut-paste base 64 encoded pkcs12 here>
quit
! for CUMA server’s self-signed certificate
crypto ca trustpoint cuma_server
enrollment terminal
crypto ca authenticate cuma_server
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
MIIDRTCCAu+gAwIBAgIQKVcqP/KW74VP0NZzL+JbRTANBgkqhkiG9w0BAQUFADCB
[ certificate data omitted ]
/7QEM8izy0EOTSErKu7Nd76jwf5e4qttkQ==
quit
tls-proxy cuma_proxy
server trust-point cuma_proxy
no server authenticate-client
client cipher-suite aes128-sha1 aes256-sha1
class-map cuma_proxy
match port tcp eq 5443
policy-map global_policy
class cuma_proxy
inspect mmp tls-proxy cuma_proxy
service-policy global_policy global

例 2:Cisco UMC および Cisco UMA アーキテクチャ:TLS プロキシとしてだけのセキュリティ アプライアンス

図 27-22(シナリオ 2)に示すように、セキュリティ アプライアンスは TLS プロキシとしてだけ機能し、既存のファイアウォールとともに動作します。セキュリティ アプライアンスと企業ファイアウォールは、NAT を実行しています。企業ファイアウォールは、インターネットから企業の Cisco UMA サーバに接続する必要があるクライアントを予測できません。そのため、この導入をサポートするには、次のアクションを実行できます。

宛先 IP アドレス 192.0.2.41 を 172.16.27.41 に変換する着信トラフィックの NAT 規則を設定します。

企業ファイアウォールがワイルドカード ピンホールを開く必要がないよう、すべてのパケットの送信元 IP アドレスを変換する、着信トラフィックのインターフェイス PAT 規則を設定します。Cisco UMA サーバは、送信元 IP アドレスが 67.11.12.183 のパケットを受信します。

hostname(config)# nat (outside) 1 0.0.0.0 0.0.0.0 outside
hostname(config)# global (inside) 1 10.1.1.2 netmask 255.255.255.255

図 27-22 Cisco UMC および Cisco UMA アーキテクチャ:シナリオ 2:TLS プロキシとしてだけのセキュリティ アプライアンス

 

static (inside,outside) 192.0.2.41 172.16.27.41 netmask 255.255.255.255
nat (outside) 1 0.0.0.0 0.0.0.0 outside
global (inside) 1 10.1.1.2 netmask 255.255.255.255
crypto ca import cuma_proxy pkcs12 sample_passphrase
<cut-paste base 64 encoded pkcs12 here>
quit
! for CUMA server’s self-signed certificate
crypto ca trustpoint cuma_server
enrollment terminal
crypto ca authenticate cuma_server
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
MIIDRTCCAu+gAwIBAgIQKVcqP/KW74VP0NZzL+JbRTANBgkqhkiG9w0BAQUFADCB
[ certificate data omitted ]
/7QEM8izy0EOTSErKu7Nd76jwf5e4qttkQ==
quit
tls-proxy cuma_proxy
server trust-point cuma_proxy
no server authenticate-client
client cipher-suite aes128-sha1 aes256-sha1
class-map cuma_proxy
match port tcp eq 5443
policy-map global_policy
class cuma_proxy
inspect mmp tls-proxy cuma_proxy
service-policy global_policy global

Cisco Unified Presence 設定例

次の例は、図 27-23 に示すように、セキュリティ アプライアンスが Cisco Unified Presence の TLS プロキシを実行するために必要な設定を示しています。単一の Cisco UP(エンティティ X)がローカル ドメイン内にあり、自己署名証明書がエンティティ X と ASA 間で使用されることが想定されています。

(SIP SUBSCRIBE を送信することによって)外部サーバへの接続を開始する可能性がある Cisco UP ごとにスタティック PAT も設定する必要があり、アドレス(この例では 10.0.0.3)を持つ別の Cisco UP がある場合は、異なる PAT ポート セット(45062 や 45070 など)を使用する必要があります。発信接続または TLS ハンドシェイクにはダイナミック NAT または PAT を使用できます。セキュリティ アプライアンス SIP 検査エンジンは、必要な変換(フィックスアップ)を行います。

必要な RSA キー ペアを作成すると、キー ペアは、エンティティ X(エンティティ Y のプロキシ)に提示される自己署名証明書によって使用されます。エンティティ Y のプロキシ証明書を作成すると、その証明書はエンティティ X のトラストストアにインストールされます。これは、エンティティ X によって信頼されているローカル CA に登録することもできます。

エンティティ X がセキュリティ アプライアンスを認証するには、セキュリティ アプライアンスの自己署名証明書(ent_y_proxy)をエクスポートして、これを信頼できる証明書としてエンティティ X にインストールする必要があります。セキュリティ アプライアンスがエンティティ X とのハンドシェイク中に X を認証するには、エンティティ X の証明書をエクスポートして、セキュリティ アプライアンスにインストールする必要があります。エンティティ X が自己署名証明書を使用する場合は、その自己署名証明書をインストールする必要があります。エンティティ X が CA によって発行された証明書を使用する場合は、CA の証明書をインストールする必要があります。

信頼できる CA からの証明書の取得については、「証明書の設定」を参照してください。

セキュリティ アプライアンスがエンティティ Y を認証するには、エンティティ Y の証明書に署名する CA 証明書をセキュリティ アプライアンスにインストールする必要があります。

エンティティ X とエンティティ Y の TLS プロキシ インスタンスの作成時に、TLS 接続を開始するエンティティには、「TLS クライアント」の役割が割り当てられます。TLS プロキシでは、「クライアント」と「サーバ」プロキシが厳密に定義されているため、いずれかのエンティティが接続を開始する可能性がある場合は、2 つの TLS プロキシ インスタンスを定義する必要があります。

SIP 検査の TLS プロキシをイネーブルにする場合は、接続を開始する可能性がある両方のエンティティについてポリシーを定義する必要があります。

図 27-23 一般的な Cisco Unified Presence と LCS フェデレーション シナリオ

 

static (inside,outside) tcp 192.0.2.1 5061 10.0.0.2 5061 netmask 255.255.255.255
static (inside,outside) tcp 192.0.2.1 5062 10.0.0.2 5062 netmask 255.255.255.255
static (inside,outside) udp 192.0.2.1 5070 10.0.0.2 5070 netmask 255.255.255.255
static (inside,outside) tcp 192.0.2.1 45062 10.0.0.3 5062 netmask 255.255.255.255
static (inside,outside) udp 192.0.2.1 45070 10.0.0.3 5070 netmask 255.255.255.255
global (outside) 102 192.0.2.1 netmask 255.255.255.255
nat (inside) 102 0.0.0.0 0.0.0.0
crypto key generate rsa label ent_y_proxy_key modulus 1024
! for self-signed Entity Y proxy certificate
crypto ca trustpoint ent_y_proxy
enrollment self
fqdn none
subject-name cn=Ent-Y-Proxy
keypair ent_y_proxy_key
crypto ca enroll ent_y_proxy
crypto ca export ent_y_proxy identity-certificate
! for Entity X’s self-signed certificate
crypto ca trustpoint ent_x_cert
enrollment terminal
crypto ca authenticate ent_x_cert
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
[ certificate data omitted ]
quit
! for Entity Y’s CA certificate
crypto ca trustpoint ent_y_ca
enrollment terminal
crypto ca authenticate ent_y_ca
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
MIIDRTCCAu+gAwIBAgIQKVcqP/KW74VP0NZzL+JbRTANBgkqhkiG9w0BAQUFADCB
[ certificate data omitted ]
/7QEM8izy0EOTSErKu7Nd76jwf5e4qttkQ==
quit
! Entity X to Entity Y
tls-proxy ent_x_to_y
server trust-point ent_y_proxy
client trust-point ent_x_proxy
client cipher-suite aes128-sha1 aes256-sha1 3des-sha1 null-sha1
! Entity Y to Entity X
tls-proxy ent_y_to_x
server trust-point ent_x_proxy
client trust-point ent_y_proxy
client cipher-suite aes128-sha1 aes256-sha1 3des-sha1 null-sha1
access-list ent_x_to_y extended permit tcp host 10.0.0.2 host 192.0.2.254 eq 5061
access-list ent_y_to_x extended permit tcp host 192.0.2.254 host 192.0.2.1 eq 5061
class-map ent_x_to_y
match access-list ent_x_to_y
class-map ent_y_to_x
match access-list ent_y_to_x
policy-map type inspect sip sip_inspect
parameters
! SIP inspection parameters
policy-map global_policy
class ent_x_to_y
inspect sip sip_inspect tls-proxy ent_x_to_y
class ent_y_to_x
inspect sip sip_inspect tls-proxy ent_y_to_x
service-policy global_policy global