Lync Server 2013 でのモビリティの技術要件

  • [アーティクル]

 

トピック最終更新日時: 2014-07-24

Some information in this topic pertains to Cumulative Updates for Lync Server 2013: February 2013.

モバイル ユーザーは、特別な計画を必要とするさまざまなモバイル アプリケーション シナリオに遭遇します。 たとえば、3G ネットワーク経由で接続することで、仕事から離れている間にモバイル アプリケーションの使用を開始し、職場に到着したときに企業のWi-Fi ネットワークに切り替えてから、建物を出るときに 3G に切り替える場合があります。 このようなネットワーク遷移をサポートし、一貫したユーザー エクスペリエンスを保証するために、環境を計画する必要があります。 このセクションでは、モバイル アプリケーションとモビリティ リソースの自動検出をサポートするために必要なインフラストラクチャ要件について説明します。

注意

モバイル アプリケーションは他の Lync Server 2013 サービスにも接続できますが、すべてのモバイル アプリケーション Web 要求を同じ外部 Web 完全修飾ドメイン名 (FQDN) に送信する要件は、Lync Server 2013 モビリティ サービスにのみ適用されます。 他のモビリティ サービスでは、この構成は必要ありません。

ハードウェア ロード バランサーでの Cookie アフィニティの要件は大幅に減り、Lync Server 2013 で提供される Lync Mobile を使用している場合は、伝送制御プロトコル (TCP) アフィニティを置き換えます。 Cookie アフィニティは引き続き使用できますが、Web サービスでは必要なくなりました。

大事な

すべてのモビリティ サービス トラフィックは、発信元ポイントが内部または外部である場所に関係なく、リバース プロキシを通過します。 単一のリバース プロキシまたはリバース プロキシのファーム、またはリバース プロキシ機能を提供しているデバイスの場合、内部トラフィックがインターフェイス経由で送信され、同じインターフェイスですぐにイングレスしようとすると、問題が発生する可能性があります。 これは、多くの場合、TCP パケットスプーフィングまたは単なるスプーフィングと呼ばれるセキュリティ規則違反につながります。 モビリティを機能させるには、ヘア ピン留め (パケットまたは一連のパケットのエグレスと即時イングレス) を許可する必要があります。 この問題を解決する 1 つの方法は、ファイアウォールとは別のリバース プロキシを使用することです (セキュリティ上、スプーフィング防止規則は常にファイアウォールに適用する必要があります)。 ヘアピンは、ファイアウォール外部インターフェイスの代わりにリバース プロキシの外部インターフェイスで発生する可能性があります。 ファイアウォールでスプーフィングを検出し、リバース プロキシでルールを緩和することで、モビリティに必要なヘアピンを許可します。
可能であれば、ドメイン ネーム システム (DNS) ホストまたは CNAME レコードを使用して、ヘアピンの動作 (ファイアウォールではなく) のリバース プロキシを定義します。

Lync Server 2013 では、Lync 2010 Mobile および Lync 2013 モバイル クライアントのモビリティ サービスがサポートされています。 どちらのクライアントも、Lync Server 2013 自動検出サービスを使用してそのモビリティ エントリ ポイントを見つけますが、使用するモビリティ サービスは異なります。 Lync 2010 Mobile では、Lync Server 2010 の累積的な更新プログラム (2011 年 11 月) で導入された 、Mcx と呼ばれるモビリティ サービスが使用されます。 Lync 2013 モバイル クライアントは、ユニファイド コミュニケーション Web API ( UCWA) をモビリティ サービス プロバイダーとして使用します。

内部および外部の DNS 構成

Mobility Services Mcx (Lync Server 2010 の累積的な更新プログラムで導入: 2011 年 11 月) と UCWA (Lync Server 2013 の累積更新で導入: 2013 年 2 月) も同様に DNS を使用します。

自動検出を使用する場合、モバイル デバイスは DNS を使用してリソースを検索します。 DNS 参照中に、最初に内部 DNS レコード (lyncdiscoverinternal) に関連付けられている FQDN への接続が試行されます。<内部ドメイン名>)。 内部 DNS レコードを使用して接続できない場合は、外部 DNS レコード (lyncdiscover) を使用して接続が試行されます。<sipdomain>)。 ネットワークの内部にあるモバイル デバイスは内部の自動検出サービス URL に接続し、ネットワークの外部にあるモバイル デバイスは外部の自動検出サービス URL に接続します。 外部自動検出要求はリバース プロキシを経由します。 Lync Server 2013 自動検出サービスは、モビリティ サービス (Mcx および UCWA) URL を含む、ユーザーのホーム プールのすべての Web サービス URL を返します。 ただし、内部モビリティ サービス URL と外部モビリティ サービス URL の両方が外部 Web サービス FQDN に関連付けられます。 そのため、モバイル デバイスがネットワークの内部か外部かに関係なく、デバイスは常にリバース プロキシを介して Lync Server 2013 Mobility Service に外部に接続します。

注意

デプロイは、内部と外部で使用するために複数の異なる名前空間で構成できることを理解することが重要です。 SIP ドメイン名が内部展開ドメイン名と異なる場合があります。 たとえば、SIP ドメインが contoso.com されている場合もあれば、内部展開 が contoso.net される場合があります。 Lync Server にログインするユーザーは、次のような john@contoso.comSIP ドメイン名を使用します。 外部 Web サービス (トポロジ ビルダーで 外部 Web サービスとして定義) に対処する場合、DNS で定義されているように、ドメイン名と SIP ドメイン名は一貫性があります。 内部 Web サービス (トポロジ ビルダーで内部 Web サービスとして定義) に対処する場合、 内部 Web サービスの既定の名前は、フロント エンド サーバー、フロント エンド プール、ディレクター、またはディレクター プールの FQDN になります。 内部 Web サービス名をオーバーライドするオプションがあります。 内部 Web サービスには内部ドメイン名 (SIP ドメイン名ではなく) を使用し、オーバーライドされた名前を反映するように DNS ホスト A (または IPv6 の場合は AAAA) レコードを定義する必要があります。 たとえば、既定の内部 Web サービス FQDN を pool01.contoso.net できます。 オーバーライドされた内部 Web サービス FQDN を webpool.contoso.net できます。 この方法で Web サービスを定義すると、サービスの内部および外部のロケールが確実に観察され、それを使用しているユーザーのローカル性が確認されなくなります。
ただし、Web サービスはトポロジ ビルダーで定義され、内部 Web サービス名をオーバーライドできるため、結果として生成される Web サービス名、検証する証明書、およびそれを定義する DNS レコードが一貫性がある限り、必要な SIP ドメイン名を含む任意のドメイン名を使用して内部 Web サービスを定義できます。 最終的に、IP アドレスへの名前の解決は、DNS ホスト レコードと一貫性のある名前空間によって決まります。
このトピックと例では、トポロジと DNS 定義を示すために内部ドメイン名を使用します。

次の図は、内部および外部の DNS 構成を使用する場合のモビリティ サービスと自動検出サービスに対するモバイル アプリケーション Web 要求のフローを示しています。

自動検出を使用したフローのMobility Service

cdb96424-96f2-4abf-88d7-1d32d1010ffd

注意

この図は、一般的な Web サービスを示しています。 Mobility という名前の仮想ディレクトリには、モビリティ サービス Mcx または UCWA が示されています。 Lync Server 2013 の累積更新を適用していない場合:2013 年 2 月、内部および外部の Web サービスで仮想ディレクトリ Ucwa が定義されている場合とない場合があります。 仮想ディレクトリ自動検出があり、仮想ディレクトリ Mcx が存在する可能性があります。
自動検出とサービスの検出は、デプロイしたモビリティ サービス テクノロジに関係なく、同じように機能します。

企業ネットワークの内部と外部の両方からモバイル ユーザーをサポートするには、内部および外部の Web FQDN がいくつかの前提条件を満たしている必要があります。 さらに、実装する機能によっては、他の要件を満たす必要がある場合があります。

  • 自動検出用の新しい DNS、CNAME、または A (ホスト (IPv6 の場合は AAAA) レコード。

  • 新しいファイアウォール ルール - Wi-Fi ネットワーク経由でプッシュ通知をサポートする場合。

  • 自動検出のために、内部サーバー証明書とリバース プロキシ証明書のサブジェクト代替名。

  • フロントエンド サーバー ハードウェア ロード バランサーの構成は、ソースアフィニティを変更します。

モビリティ サービスと自動検出サービスをサポートするには、トポロジが次の要件を満たしている必要があります。

  • フロントエンド プールの内部 Web FQDN は、フロントエンド プールの外部 Web FQDN とは異なる必要があります。

  • 内部 Web FQDN は、企業ネットワーク内からのみ解決してアクセスできる必要があります。

  • 外部 Web FQDN は、インターネットに対してのみ解決し、インターネットからアクセスできる必要があります。

  • 企業ネットワーク内にいるユーザーの場合は、モビリティ サービスの URL を外部 Web FQDN にアドレス指定する必要があります。 この要件はモビリティ サービスに対して行われ、この URL にのみ適用されます。

  • 企業ネットワークの外部にいるユーザーの場合、要求はフロントエンド プールまたはディレクターの外部 Web FQDN に移動する必要があります。

自動検出をサポートしている場合は、SIP ドメインごとに次の DNS レコードを作成する必要があります。

  • 組織のネットワーク内から接続するモバイル ユーザーをサポートする内部 DNS レコード。

  • インターネットから接続するモバイル ユーザーをサポートする外部またはパブリックの DNS レコード。

内部自動検出 URL は、ネットワークの外部からアドレス指定できないようにする必要があります。 外部の自動検出 URL は、ネットワーク内からアドレス指定できません。 ただし、外部 URL に対してこの要件を満たすことができない場合は、内部 URL が常に最初に試行されるため、モバイル クライアントの機能は影響を受けない可能性があります。

DNS レコードには、CNAME レコードまたは A (ホスト、IPv6 の場合は AAAA) レコードを指定できます。

注意

モバイル デバイス クライアントは、異なるドメインからの複数の Secure Sockets Layer (SSL) 証明書をサポートしていません。 そのため、異なるドメインへの CNAME リダイレクトは HTTPS 経由ではサポートされません。 たとえば、director.contoso.net のアドレスにリダイレクトする lyncdiscover.contoso.com の DNS CNAME レコードは、HTTPS 経由ではサポートされません。 このようなトポロジでは、モバイル デバイス クライアントが最初の要求に HTTP を使用して、CNAME リダイレクトが HTTP 経由で解決されるようにする必要があります。 その後の要求では HTTPS が使用されます。 このシナリオをサポートするには、ポート 80 (HTTP) の Web 発行規則を使用してリバース プロキシを構成する必要があります。 詳細については、「 Lync Server 2013 でのモビリティ用リバース プロキシの構成」の「ポート 80 の Web 公開規則を作成するには」を参照してください。
同じドメインへの CNAME リダイレクトは、HTTPS 経由でサポートされています。 この場合、宛先ドメインの証明書は送信元ドメインを対象とします。

シナリオに必要な DNS レコードの詳細については、「 DNS の概要 - Lync Server 2013 の自動検出」を参照してください。

ポートとファイアウォールの要件

プッシュ通知をサポートし、Apple モバイル デバイスがWi-Fi ネットワーク経由でプッシュ通知を受信する場合は、エンタープライズ Wi-Fi ネットワークでポート 5223 を開く必要もあります。 ポート 5223 は、Apple Push Notification Service (APNS) によって使用される送信 TCP ポートです。 モバイル デバイスが接続を開始します。 詳細については、以下を参照してください http://support.apple.com/kb/TS1629 。

警告

Lync 2013 Mobile クライアントを使用する Apple デバイスでは、プッシュ通知は必要ありません。

ユーザーが存続可能ブランチ アプライアンス (SBA) にホームされている場合は、次のポートが必要であることに注意してください。

  • UcwaSipExternalListeningPort にはポート 5088 が必要です

  • UcwaSipPrimaryListeningPort にはポート 5089 が必要です

自動検出のポートとプロトコルの要件の詳細とガイダンスについては、「 ポートの概要 - Lync Server 2013 の自動検出」を参照してください。

証明書の要件

Lync モバイル クライアントの自動検出をサポートしている場合は、モバイル クライアントからのセキュリティで保護された接続をサポートするために、証明書のサブジェクトの別名リストを変更する必要があります。 自動検出サービスを実行するフロント エンド サーバーとディレクターごとに、このセクションで説明するサブジェクト代替名エントリを追加して、新しい証明書を要求して割り当てる必要があります。 推奨される方法は、リバース プロキシの証明書のサブジェクトの別名リストも変更することです。 組織内のすべての SIP ドメインにサブジェクトの別名エントリを追加する必要があります。

通常、内部証明機関を使用して証明書を再発行するのは簡単なプロセスですが、リバース プロキシで使用されるパブリック証明書に複数のサブジェクトの別名エントリを追加すると、コストがかかる場合があります。 多くの SIP ドメインがあり、サブジェクト代替名の追加が非常に高価な場合は、HTTPS (既定の構成) を使用してポート 443 ではなく、HTTP を使用してポート 80 経由で最初の自動検出サービス要求を行うようにリバース プロキシを構成できます。 その後、要求はディレクターまたはフロント エンド プールのポート 8080 にリダイレクトされます。 ポート 80 で最初の自動検出サービス要求を発行する場合、要求では HTTPS ではなく HTTP が使用されるため、リバース プロキシの証明書を変更する必要はありません。 この方法はサポートされていますが、お勧めしません。

インターネット インフォメーション サービス (IIS) の要件

モビリティには、IIS 7.5、IIS 8.0、または IIS 8.5 を使用することをお勧めします。 Mobility Service インストーラーは、パフォーマンスを向上させるために ASP.NET にフラグを設定します。 IIS 7.5 は Windows Server 2008 R2 に既定でインストールされ、IIS 8.0 はWindows Server 2012にインストールされ、IIS 8.5 は Windows Server 2012 R2 にインストールされます。 Mobility Service インストーラーは、ASP.NET 設定を自動的に変更します。

ロード バランサー機器の要件

フロントエンド プールをサポートしているハードウェア ロード バランサーでは、Web サービス トラフィック用の外部 Web Services 仮想 IP (VIP) をソース用に構成する必要があります。 ソース アフィニティは、セッション状態を維持するために、1 つのクライアントからの複数の接続が 1 つのサーバーに送信されるようにするのに役立ちます。 アフィニティ要件の詳細については、「 Lync Server 2013 の負荷分散要件」を参照してください。

内部Wi-Fi ネットワーク経由でのみ Lync モバイル クライアントをサポートする予定の場合は、外部 Web サービス VIP の説明に従って、ソース用の内部 Web サービス VIPS を構成する必要があります。 このような場合は、ハードウェア ロード バランサー上の内部 Web サービス VIP に対して、source_addr (または TCP) アフィニティを使用する必要があります。 詳細については、「 Lync Server 2013 の負荷分散要件」を参照してください。

リバース プロキシの要件

Lync モバイル クライアントの自動検出をサポートしている場合は、次のように現在の発行規則を更新する必要があります。

  • リバース プロキシ証明書のサブジェクトの別名リストを更新し、最初の自動検出サービス要求に HTTPS を使用する場合は、lyncdiscover の Web 発行規則を更新する必要があります。<sipdomain>。 通常、これはフロントエンド プールの外部 Web サービス URL の公開規則と組み合わされます。

  • リバース プロキシ証明書のサブジェクトの別名の一覧を更新する必要がないように、最初の自動検出サービス要求に HTTP を使用する場合は、ポート HTTP/TCP 80 の新しい Web 発行規則を作成する必要があります (存在しない場合)。 HTTP/TCP 80 の規則が既に存在する場合は、そのルールを更新して lyncdiscover を含めることができます。<sipdomain> エントリ。