Office 365 向け ExpressRoute の実装

重要:  この記事は機械翻訳されています。機械翻訳についての「免責事項」をお読みください。この記事の英語版を参照するには、ここをクリックしてください。

Office 365 向け ExpressRoute は、インターネットに接続する多数の Office 365 サービスへの代替ルーティング パスを提供します。Office 365 向け ExpressRoute のアーキテクチャは、Office 365 サービスのパブリック IP プレフィックスのアドバタイズに基づいています。これらは既に、今後 IP プレフィックスをネットワークに再配布するために、インターネットを経由して、プロビジョニングされた ExpressRoute 回線にアクセスできます。ExpressRoute を使用すると、多数の Office 365 サービスに対して、インターネットおよび ExpressRoute を介した複数の異なるルーティング パスを効果的に有効化できます。ネットワーク上のルーティングのこの状態は、内部ネットワーク トポロジを設計する方法の大幅な変更を意味する場合があります。

状態:完全なガイド v2

Office 365 向け ExpressRoute を実装する場合、コア ネットワークにルートを挿入する専用回線とインターネットの両方を介したルーティングを使用可能にするというネットワークの複雑さに対応するために、慎重に計画する必要があります。ユーザーやそのチームが、このガイドで説明する詳細な計画とテストを実行しない場合、ExpressRoute 回線を有効にしたときに Office 365 サービスへの接続が断続的に途切れたり、完全に失われたりする危険性が高くなります。

実装を成功させるには、インフラストラクチャ要件の分析、ネットワークの詳細な評価と設計の実施、段階的かつ制御された方法によるロールアウトの慎重な計画、検証およびテストの詳細な計画を行う必要があります。大規模な分散環境の場合、実装期間が数か月に及ぶのは珍しいことではありません。このガイドは、事前の実装計画に役立つように設計されています。

大規模な展開を成功させるには、計画に 6 か月かかる場合があり、多くの場合、ネットワーク、ファイアウォール、プロキシ サーバーの管理者、Office 365 管理者、セキュリティ、エンドユーザー サポート、プロジェクト管理など、組織内のさまざまな分野からチーム メンバーを集めたり、経営陣の支援を受けたりすることも必要となります。計画プロセスに投資すると、展開の失敗によって発生する可能性のあるダウンタイムや複雑で費用のかかるトラブルシューティングを軽減できます。

この実装ガイドでは、事前に次の条件が満たされていることを前提とします。

  1. ネットワーク評価を行って、ExpressRoute が推奨および承認されているかどうかを確認した。

  2. ExpressRoute ネットワーク サービス プロバイダーを選択した。詳細については、「ExpressRoute パートナーとピアリングの場所」を参照してください。

  3. 開封済み、 ExpressRoute ドキュメントを理解しており、内部ネットワークが ExpressRoute 前提条件の端に一致します。

  4. チームが読み取りのすべての一般向けのガイダンスとhttps://aka.ms/expressrouteoffice365https://aka.ms/ertドキュメント、チャンネルの 9 など、重要な技術的な詳細の理解するためのOffice 365 のトレーニング向け Azure ExpressRouteシリーズ。

    • SaaS サービスとインターネットの依存関係。

    • 非対称ルートを回避し、複雑なルーティングを処理する方法。

    • 境界のセキュリティ、空き時間情報、およびアプリケーション レベル コントロールを組み込む方法です。

要件の収集から開始する

まず、組織で採用予定の機能とサービスを確認します。さまざまな Office 365 サービスのどの機能を使用するか、それらの機能を使用するユーザーをネットワーク上のどこでホストするかを決定する必要があります。シナリオをカタログ化して、各シナリオで必要とされるネットワーク属性を追加する必要があります。たとえば、受信および送信のネットワーク トラフィック フロー、Office 365 エンドポイントが ExpressRoute を介して使用可能かどうかなどの属性が必要です。

組織の要件を収集するには、次の手順を実行します。

  • 組織で使用している Office 365 サービス用の受信および送信のネットワーク トラフィックをカタログ化します。さまざまな Office 365 シナリオで必要とされるフローについては、Office 365 の URL および IP アドレス範囲のページを参照してください。

  • 内部 WAN のバックボーンとトポロジ、サテライト サイトの接続性、エンドユーザーの接続性、ネットワーク境界の送信ポイントへのルーティング、およびプロキシ サービスの詳細を示した、既存のネットワーク トポロジに関するドキュメントを収集します。

    • Office 365 サービスとその他の Microsoft サービスが接続するネットワークのインターネット接続パスと提案された ExpressRoute 接続パスの両方を示したネットワーク ダイアグラムで、受信サービスのエンドポイントを特定します。

    • すべての地理的なユーザーの場所を特定します。また、現在インターネット送信ポイントのある場所および ExpressRoute ピアリングの場所への送信ポイントとして提案されている場所との間の WAN 接続も特定します。

    • すべてのエッジ デバイス (プロキシ、ファイアウォールなど) を特定し、インターネットおよび ExpressRoute を経由したフローに対するそれらの関係をカタログ化します。

    • エンド ユーザーが Office 365 にアクセスするために、インターネットと ExpressRoute の両方のフローに直接ルーティングするか、または間接的なアプリケーション プロキシを使用するかを文書化します。

  • テナントの場所と Meet-Me の場所をネットワーク ダイアグラムに追加します。

  • 主要なユーザーの場所から Office 365 までのネットワーク パフォーマンスと遅延時間の特性について、想定される値と観測される値を推定します。Office 365 は、グローバルで分散された一連のサービスであり、ユーザーは、テナントの場所とは異なる可能性のある場所に接続することに留意してください。このため、ExpressRoute 接続およびインターネット接続を介した、ユーザーと Microsoft のグローバル ネットワークの最も近いエッジとの間の待機時間を測定し、最適化することをお勧めします。この作業では、ネットワーク評価で得られた結果を役立てることができます。

  • 新しい ExpressRoute 接続を使用する場合に満たす必要がある会社のネットワーク セキュリティ要件と高可用性要件の一覧を作成します。たとえば、インターネット送信または ExpressRoute 回線で障害が発生した場合に、ユーザーが Office 365 に継続してアクセスできるようにするにはどうすればよいかなどがあります。

  • Office 365 ネットワーク受信および送信フロー ドキュメントにはインターネット パスが使用され、ExpressRoute を使用します。ユーザーの地理的な場所と、社内ネットワーク トポロジの詳細の詳細を他のユーザーが 1 つの場所から別のプランがあります。

ルーティングやその他のネットワークの複雑さを最小限に抑えるのみを使用する ExpressRoute for Office 365 専用の接続、またはネットワークの評価結果として、規制要件が原因で上に移動するために必要なネットワーク トラフィックの流れをお勧めします。さらに、導入プロジェクトのまったく異なるの段階として ExpressRoute ルーティングとアプローチ送受信ネットワーク トラフィック フローの範囲をステージすることをお勧めします。Office 365 の ExpressRoute を展開するだけでユーザーが開始送信ネットワーク トラフィック フローをそのまま残りますが、インターネット経由で受信ネットワーク トラフィック フローは、トポロジの複雑さと非対称ルーティングさまざまな機能のご紹介のリスクの増加を制御することができます。

ネットワーク トラフィック カタログには、社内ネットワークと Microsoft 間で必要がありますすべての受信および送信ネットワーク接続のリストが含まれます。

  • 送信ネットワークのトラフィック フローは、接続がオンプレミス環境 (内部クライアントまたは内部サーバーなど) から開始され、Microsoft サービスを接続先とするシナリオです。これらの接続は、Office 365 に直接接続することも、間接的に接続することも (プロキシ サーバー、ファイアウォール、または Office 365 へのパス上にあるその他のネットワーク デバイスを経由する場合など) できます。

  • 受信ネットワーク トラフィック フローは、接続を Microsoft クラウドから開始し、オンプレミスのホストを接続先とするシナリオです。これらの接続は通常、ファイアウォールや、外部から送信されるフローについて顧客のセキュリティ ポリシーで必要とされているその他のセキュリティ インフラストラクチャを経由する必要があります。

受信トラフィックを送信するサービスを決定するには、記事「Office 365 向け ExpressRoute でのルーティング」の「ルーティング対称性の確保」セクションを参照してください。また、残りの接続情報を決定するには、参照記事「Office 365 のエンドポイント」の「ExpressRoute for Office 365」とマークされた列を参照してください。

送信接続を必要とする各サービスについては、ネットワーク ルーティング、プロキシ構成、パケット検査、必要な帯域幅など、サービスに関する計画された接続について説明する必要があります。

受信接続を必要とする各サービスについては、いくつかの追加情報が必要です。Microsoft クラウド内のサーバーは、オンプレミスのネットワークとの接続を確立します。接続が正しく確立されるように、この接続のすべての側面について説明する必要があります。たとえば、これらの受信接続を承諾するサービスのパブリック DNS エントリ、CIDR 形式の IPv4 IP アドレス、含まれる ISP 機器、これらの接続の受信 NAT またはソース NAT の処理方法などがあります。

受信接続の場合、インターネットまたは ExpressRoute のどちらを経由するかに関係なく、それらの接続を再確認して、非対称ルーティングが発生していないことを確かめる必要があります。Office 365 サービスが受信接続を開始するオンプレミスのエンドポイントを他の Microsoft サービスや Microsoft 以外のサービスからもアクセスすることが必要になる場合があります。Office 365 向けに、ExpressRoute を介したこれらのサービスへのルーティングを有効にしても、他のシナリオが中断されないようにすることが重要です。多くの場合、顧客は、ExpressRoute を有効にした後も Microsoft からの受信フローの対称性を確保するために、顧客の内部ネットワーク固有の変更を実装することが必要になります。

次に、必要な詳細のレベルについてサンプルを示します。この例では、Exchange ハイブリッドが ExpressRoute を介してオンプレミス システムにルーティングします。

接続プロパティ

ネットワーク トラフィックの方向

受信

サービス

Exchange ハイブリッド

パブリック Office 365 エンドポイント (接続元)

Exchange Online (IP アドレス)

パブリック オンプレミス エンドポイント (接続先)

5.5.5.5

パブリック (インターネット) DNS エントリ

Autodiscover.contoso.com

このオンプレミスのエンドポイントを他の (Office 365 以外の) Microsoft サービスで使用するか

いいえ

このオンプレミスのエンドポイントをインターネット上のユーザーまたはシステムで使用するか

はい

パブリック エンドポイントを経由して公開される内部システム

Exchange Server クライアント アクセスの役割 (オンプレミス) 192.168.101、192.168.102、 192.168.103

パブリック エンドポイントの IP アドバタイズメント

インターネット:5.5.0.0/16

ExpressRoute に: 5.5.5.0/24

セキュリティ/境界の制御

インターネット パス:DeviceID_002

ExpressRoute パス: DeviceID_003

高可用性

アクティブ/アクティブ (2 か所での地理的冗長性)

ExpressRoute 回線 – シカゴとダラス

パス対称性の制御

方法: ソース NAT

インターネット パス: ソース NAT 192.168.5.5 への接続を受信します。

ExpressRoute パス: ソース NAT への接続 192.168.1.0 シカゴと 192.168.2.0 (ダラス)

次に、送信専用サービスについてサンプルを示します。

接続プロパティ

ネットワーク トラフィックの方向

送信

サービス

SharePoint Online

オンプレミスのエンドポイント (接続元)

ユーザー ワークステーション

パブリック Office 365 エンドポイント (接続先)

SharePoint Online (IP アドレス)

パブリック (インターネット) DNS エントリ

*.sharepoint.com (およびその他の FQDN)

CDN 参照

cdn.sharepointonline.com (およびその他のFQDN) – CDN プロバイダーが保守している IP アドレス

IP アドバタイズメントと使用中の NAT

インターネット パス/ソース NAT:1.1.1.0/24

ExpressRoute パス/ソース NAT: 1.1.2.0/24 (シカゴ) と 1.1.3.0/24 (ダラス)

接続方法

インターネット: レイヤー 7 プロキシ (.pac ファイル) 経由

ExpressRoute: 直接ルーティング (プロキシなし)

セキュリティ/境界の制御

インターネット パス:DeviceID_002

ExpressRoute パス: DeviceID_003

高可用性

インターネット パス: 冗長なインターネットの出口

ExpressRoute パス: アクティブ/' ホット ポテト ' ルーティング 2 地域冗長な ExpressRoute 回路 – シカゴとダラス間

パス対称性の制御

方法: ソースのすべての接続 NAT

サービスとそれらに関連付けられたネットワーク トラフィック フローを理解した後、これらの新しい接続要件を取り込んで、Office 365 向け ExpressRoute を使用するために行う変更を示したネットワーク ダイアグラムを作成することができます。ダイアグラムには、次のものを含める必要があります。

  1. Office 365 やその他のサービスにアクセスするすべてのユーザーの場所。

  2. インターネットおよび ExpressRoute のすべての送信ポイント。

  3. ネットワーク内外で接続を管理するすべての送信および受信デバイス (ルーター、ファイアウォール、アプリケーション プロキシ サーバー、侵入検出/防止装置など)。

  4. すべての受信トラフィックの内部の接続先 (ADFS Web アプリケーション プロキシ サーバーからの接続を承諾する内部 ADFS サーバーなど)。

  5. アドバタイズされるすべての IP サブネットのカタログ

  6. ユーザーが Office 365 にアクセスする各場所の特定と、ExpressRoute に使用する Meet-Me の場所の一覧。

  7. 内部ネットワーク トポロジの場所と部分。ExpressRoute から得られた Microsoft IP のプレフィックスは、承諾され、フィルタリングされた後、ここにアドバタイズされます。

  8. ネットワーク トポロジは、各ネットワーク セグメントの地理的な場所と、それが ExpressRoute またはインターネット、あるいはその両方を介して Microsoft ネットワークに接続する方法を示す必要があります。

次の図は、ユーザーが Office 365 への受信および送信ルーティングのアドバタイズメントに従って Office 365 を使用する各場所を示しています。

ExpressRoute 地域別 Meet-Me

送信トラフィックの場合、ユーザーは次の 3 つの方法のいずれかにより、Office 365 にアクセスします。

  1. 北米にある Meet-Me の場所 (カリフォルニアのユーザーの場合)

  2. 香港にある Meet-Me の場所を経由 (香港のユーザーの場合)

  3. インターネット経由 (ユーザー数が少なく、ExpressRoute 回線がプロビジョニングされていないバングラデシュの場合)

地域別発信方向接続の図

同様に、Office 365 からの受信ネットワーク トラフィックも、次の 3 つの方法のいずれかで返されます。

  1. 北米にある Meet-Me の場所 (カリフォルニアのユーザーの場合)

  2. 香港にある Meet-Me の場所を経由 (香港のユーザーの場合)

  3. インターネット経由 (ユーザー数が少なく、ExpressRoute 回線がプロビジョニングされていないバングラデシュの場合)

地域別着信方向接続の図

Meet-Me の場所 (ExpressRoute 回線がユーザーのネットワークを Microsoft ネットワークに接続する物理的な場所) の選択は、ユーザーが Office 365 にアクセスする場所の影響を受けます。SaaS 製品である Office 365 は、IaaS または PaaS 地域モデルで Azure と同じように動作しません。代わりに、Office 365 は分散された一連のコラボレーション サービスで、ユーザーは、複数のデータセンターおよび地域にまたがるエンドポイントに接続することが必要になる場合があり、これらは、ユーザーのテナントがホストされる場所や地域と必ずしも同じ場所にあるとは限りません。

これは、Office 365 向け ExpressRoute の Meet-Me の場所を選択する際に考慮する必要がある最も重要な事項は、組織内のユーザーの接続元となる場所であることを意味します。Office 365 への最適な接続に関する一般的な推奨事項は、Office 365 サービスに対するユーザー要求が、最短のネットワーク パスを介して Microsoft ネットワークに渡されるようにルーティングを実装することです。多くの場合、これは "ホット ポテト" ルーティングとも呼ばれます。たとえば、ほとんどの Office 365 ユーザーが 1 つまたは 2 つの場所に存在する場合、これらのユーザーの場所に最も近い Meet-Me の場所を選択すると、最適な設計が作成されます。会社が多数の異なる地域に多数のユーザーを有している場合、複数の ExpressRoute 回線と複数の Meet-Me の場所の設置について検討することをお勧めします。一部のユーザーの場所については、Microsoft ネットワークおよび Office 365 への最短/最適なパスが内部 WAN と ExpressRoute のMeet-Me ポイントを経由しないでインターネットを経由する場合があります。

多くの場合、地域内には、相対的にユーザーに近い場所として選択できる Meet-Me の場所は複数あります。次の表に記入して、決定の指針としてご使用ください。

カリフォルニアとニューヨークに予定されている ExpressRoute Meet-Me の場所

場所

ユーザー数

Microsoft ネットワークへの想定される接続待機時間 (インターネット送信を経由する場合)

Microsoft ネットワークへの想定される接続待機時間 (ExpressRoute を経由する場合)

ロサンゼルス

10,000

~ 15 ミリ秒

~ 10 ミリ秒 (シリコン バレー経由)

ワシントン DC

15,000

~ 20 ミリ秒

~ 10 ミリ秒 (ニューヨーク経由)

ダラス

5,000

~ 15 ミリ秒

~ 40 ミリ秒 (ニューヨーク経由)

Office 365 の地域、ExpressRoute ネットワーク サービス プロバイダーの Meet-Me の場所、地域別のユーザー数を示すグローバル ネットワーク アーキテクチャを作成したら、それを使用して、最適化を実行できる場合を識別することができます。これは、Meet-Me の場所を取得するためにトラフィックを離れたルーティングするグローバル ヘアピン ネットワーク接続を示す場合もあります。グローバル ネットワーク上でヘアピンが検出された場合、続行する前にそれを修復する必要があります。ヘアピンを回避するには、別の Meet-Me の場所を探すか、インターネット ブレークアウトの送信ポイントを使用します。

最初の図は、北米に 2 つの物理的な場所を持つ顧客の例を示しています。オフィスの場所、Office 365 テナントの場所、ExpressRoute Meet-Me の場所に関するいくつかの選択肢が示されています。この例では、顧客は、次の 2 つの原則に従って (この順序で)、Meet-Meの場所を選択しました。

  1. 組織内のユーザーに最も近い場所。

  2. Office 365 がホストされている Microsoft のデータ センターへの類似性の最も近いします。

ExpressRoute US 地域 Meet-Me

2 番目の図は、この概念を多少拡張して、多国籍企業の顧客が同様の情報と意思決定に対処する場合の例を示しています。この顧客はバングラデシュに小さなオフィスを設置しており、そこでは、わずか 10 名のユーザーで構成される小規模なチームが、その地域での勢力拡大に専念しています。チェンナイには、Meet-Me の場所があり、Office 365 がホストされている Microsoft のデータセンターもあるので、Meet-Me の場所は状況にかなっています。ただし、10 名のユーザーのために回線を増設するのは、費用の負担が大きすぎます。ネットワークについて検討する場合、ネットワークを介してネットワーク トラフィックを送信する際の待機時間が、別の ExpressRoute 回線を取得するために資金を費やすよりも効果的であるかどうかを判断する必要があります。

代替方法として、最初の図と次の再作成した図で示すとおり、バングラデシュの 10 名のユーザーは、内部ネットワークでルーティングするよりも、インターネットを介して Microsoft ネットワークにネットワーク トラフィックを送信する方が高いパフォーマンスを実現できます。

地域別発信方向接続の図

Office 365 向け ExpressRoute の実装計画を作成する

実装計画には、ExpressRoute の構成に関する技術的な詳細と、ネットワーク上の他のすべてのインフラストラクチャを構成する方法の詳細を含める必要があります。たとえば、次のようなものがあります。

  • ExpressRoute とインターネットの間で分割するサービスを計画します。

  • 帯域幅、セキュリティ、高可用性、フェールオーバーを計画します。

  • さまざまな場所に適したルーティング パスの最適化など、受信および送信のルーティングを設計します。

  • ExpressRoute ルートをどの程度までネットワークにアドバタイズするかを決定します。また、クライアントがインターネットまたは ExpressRoute を選択するメカニズム (たとえば、直接ルーティング、アプリケーション プロキシなど) も決定します。

  • DNS レコードの変更内容を計画します (Sender Policy Framework のエントリなど)。

  • 計画を策定する NAT 送受信ソース NAT. を含む

  • 初期の展開では、すべての受信サービス (受信メールやハイブリッド接続など) にインターネットを使用することを推奨します。

  • エンドユーザー クライアント LAN ルーティング、 PAC/WPAD ファイルを構成するなど、既定のルート、プロキシ サーバー、および BGP ルーティング広告を計画します。

  • 境界ルーティング (プロキシ サーバー、ファイアウォール、クラウド プロキシなど) を計画します。

Office 365 の主要なワークロードごとに必要な帯域幅の計画を作成します。Exchange Online、SharePoint Online、Skype for Business Online の帯域幅要件を個別に概算します。出発点として、Exchange Online および Skype for Business 用に提供している帯域幅の計算ツールを使用することができます。ただし、組織の帯域幅のニーズを完全に把握するには、ユーザーのプロファイルと場所の代表的なサンプルを使用したパイロット テストを実施する必要があります。

インターネットと ExpressRoute の各送信場所におけるセキュリティの処理方法を計画に追加します。Office 365 へのすべての ExpressRoute 接続は、パブリック ピアリングを使用し、その場合でも、外部ネットワークへの接続に関する会社のセキュリティ ポリシーに従って保護する必要があることを忘れないでください。

どのユーザーがどの種類のサービス停止の影響を受けるかの詳細、およびユーザーが最も簡単な方法でフル稼働できる方法の詳細を計画に追加します。

ジッター、遅延、輻輳、ヘッドルームに関する Skype for Business の要件を含む帯域幅要件の計画

Skype for Business Online にはさらに、記事「Media Quality and Network Connectivity Performance in Skype for Business Online (Skype for Business Online におけるメディア品質とネットワーク接続パフォーマンス)」で説明されている固有の追加ネットワーク要件があります。

Office 365 向け ExpressRoute のネットワーク計画」のセクション「Azure ExpressRoute の帯域幅計画」を参照してください。

パイロット ユーザーとの帯域幅評価を実施する場合、Microsoft のガイド「基準計画とパフォーマンスの履歴を使用して、office 365 パフォーマンスのチューニング」を使用することができます。

高可用性要件の計画

ニーズに対応する高可用性の計画を作成し、更新されたネットワーク トポロジ ダイアグラムに取り込みます。「Office 365 向け ExpressRoute のネットワーク計画」のセクション「Azure ExpressRoute の高可用性とフェールオーバー」を参照してください。

ネットワークのセキュリティ要件を計画します。

ネットワークのセキュリティ要件を満たす計画を作成し、更新されたネットワーク トポロジ ダイアグラムに取り込みます。「Office 365 向け ExpressRoute のネットワーク計画」のセクション「Office 365 向け Azure ExpressRoute シナリオにセキュリティ制御を適用する」を参照してください。

Office 365 向け ExpressRoute には、送信ネットワーク要件があり、これは十分に知られていない可能性があります。具体的には、Office 365 に対してユーザーおよびネットワークを表し、Microsoft への送信ネットワーク接続のソース エンドポイントとして動作する IP アドレスは、次に説明する特定の要件を満たす必要があります。

  1. エンドポイントは、パブリック IP アドレスである必要があり、会社または ExpressRoute 接続を提供する通信業者に登録されます。

  2. エンドポイントは、Microsoft にアドバタイズされ、ExpressRoute により検証/承諾される必要があります。

  3. エンドポイントは、同じまたはより優先されるルーティング メトリックを使ってインターネットにアドバタイズすることはできません。

  4. エンドポイントは、ExpressRoute 経由で構成されていない Microsoft サービスへの接続に使用することはできません。

ネットワーク設計がこれらの要件を満たさない場合、ルートのブラック ホールまたは非対称のルーティングのために、ユーザーは、Office 365 サービスおよび他の Microsoft サービスに接続できない危険性が高くなります。これは、Microsoft サービス要求は ExpressRoute 経由でルーティングするが、応答はインターネット経由でルーティングされる場合、またはその反対の場合に発生し、応答は、ファイアウォールなどのステートフル ネットワーク デバイスによりドロップされます。

前述の要件を満たすために使用できる最も一般的な方法は、ソース NAT を使用することです。ソース NAT はネットワークの一部として実装されるか、ExpressRoute 通信業者により提供されます。ソース NAT を使用すると、ExpressRoute からのインターネット接続の詳細とプライベート IP アドレスを抽象化し、適切な IP ルート アドバタイズメントと組み合わせることにより、パスの対称性を確保する簡単なメカニズムを提供することができます。ExpressRoute のピアリング場所に固有のステートフル ネットワーク デバイスを使用する場合、パスの対称性を確保するために、ExpressRoute ピアリングごとに個別の NAT プールを実装する必要があります。

詳細については、「ExpressRoute NAT の要件」を参照してください。

送信接続の変更をネットワーク トポロジ ダイアグラムに追加します。

エンタープライズ Office 365 の展開の多くは、何らかの形式の Office 365 からオンプレミス サービス (Exchange、SharePoint、Skype for Business のハイブリッド シナリオ、メールボックスの移行、ADFS インフラストラクチャを使用する認証など) への受信接続を前提とします。ExpressRoute で、オンプレミスのネットワークと Microsoft の間で送信接続用の追加のルーティング パスを有効にした場合、受信接続は、これらのフローに引き続きインターネットを使用する予定であっても、非対称のルーティングにより不測の影響を受ける可能性があります。Office 365 からオンプレミス システムへのインターネット ベースの受信フローに影響を与えないようにするには、次に説明するいくつかの対策を講じることをお勧めします。

受信ネットワーク トラフィック フローの非対称ルーティングのリスクを最小限に抑えるには、 ExpressRoute のルーティングを可視化できるネットワーク セグメントにルーティングする前に、すべての受信接続でソース NAT を使用する必要があります。ソース NAT を使用しないで、ExpressRoute のルーティングを可視化できるネットワーク セグメントへの受信接続を許可すると、Office 365から送信される要求は、インターネットから入ってきますが、Office 365 に返される応答は、Microsoft ネットワークへの ExpressRoute ネットワーク パスを優先するため、非対称のルーティングが設定されることになります。

この要件を満たすためには、次の実装パターンのいずれかを検討することができます。

  1. インターネットからオンプレミス システムへのパス上にあるファイアウォール、ロード バランサーなどのネットワーク機器を使用して要求を内部ネットワークにルーティングする前に、ソース NAT を実行します。

  2. ExpressRoute ルートが、インターネット接続を処理する受信サービス (フロント エンド サーバー、リバース プロキシ システムなど) が存在するネットワーク セグメントに伝達されないようにします。

ネットワークでこれらのシナリオを明示的に説明し、すべての受信ネットワーク トラフィック フローをインターネット経由にすることにより、展開および運用時の非対称ルーティングのりスナップショットクライアントを最小限に抑えることができます。

一部の受信フローを ExpressRoute 接続経由でダイレクトすることを選択できる場合もあります。これらのシナリオでは、次の追加事項を考慮する必要があります。

  1. Office 365 は、パブリック IP を使用するオンプレミスのエンドポイントしかターゲットにすることができません。これは、オンプレミスの受信エンドポイントが ExpressRoute 経由でのみ Office 365 に接続される場合でも、それに関連付けられたパブリック IP が必要であることを意味します。

  2. オンプレミスのエンドポイントを解決するために Office 365 サービスが実行するすべての DNS 名の解決は、パブリック DNS を使用します。これは、受信サービスのエンドポイントの FQDN をインターネット上の IP マッピングに登録する必要があることを意味します。

  3. ExpressRoute 経由で受信ネットワーク接続を受信するには、これらのエンドポイントのパブリック IP サブネットを、ExpressRoute 経由で Microsoft にアドバタイズする必要があります。

  4. これらの受信ネットワーク トラフィック フローを慎重に評価し、会社のセキュリティ ポリシーとネットワーク ポリシーに従って、適切なセキュリティおよびネットワークの制御が適用されるようにします。

  5. オンプレミスの受信エンドポイントを、ExpressRoute 経由で Microsoft にアドバタイズすると、Office 365 を含むすべての Microsoft サービスで、これらのエンドポイントへの優先されるルーティング パスとして ExpressRoute が効果的に使用されるようになります。これは、これらのエンドポイント サブネットを Office 365 サービスとの通信用としてのみ使用する必要があることを意味します。Microsoft ネットワーク上の他のサービスとの通信に使用することはできません。それ以外の場合、誤った設計のために、非対称ルーティングが設定され、Microsoft サービスからの受信接続では、ExpressRoute 経由での受信のルーティングが優先され、リターン パスはインターネットを使用することになります。

  6. ExpressRoute 回線または Meet-Me の場所が停止した場合でも、オンプレミスの受信エンドポイントが、個別のネットワーク パスを経由して要求を受け入れることができるようにする必要があります。これは、エンドポイントのサブネットのアドバタイズが複数の ExpressRoute 回線を経由する可能性があることを意味します。

  7. ExpressRoute 経由でネットワークに入ってくるすべての受信ネットワーク トラフィック フローについては、特にこれらのフローがファイアウォール、ファイアウォールなどのステートフル ネットワーク デバイスを通過する場合、ソース NAT を適用することをお勧めします。

  8. ADFS プロキシ、Exchange 自動検出などの一部のオンプレミスのサービスは、Office 365 サービスとユーザーの両方からの受信要求をインターネットから受信する場合があります。これらの要求の場合、Office 365 は、インターネット経由のユーザー要求と同じ FQDN をターゲットにします。インターネットからオンプレミスのエンドポイントへの受信ユーザー接続を許可し、Office 365 接続で強制的に ExpressRoute を使用するようにした場合、ルーティングは著しく複雑になります。大部分のお客様には、運用上の配慮から、ExpressRoute を経由したこのような複雑なシナリオを実装することは推奨できません。この追加のオーバーヘッドとしては、非対称ルーティングのリスクの管理が含まれ、ルーティングのアドバタイズメントとポリシーを多岐にわたって注意深く管理する必要があります。

非対称ルーティングを回避して、組織内のユーザーが Office 365 やインターネット上の他の重要なサービスをシームレスに使用できるようにする必要があります。非対称ルーティングの原因となる 2 つの一般的な構成があります。ここで、使用する予定のネットワーク構成を見直して、これらの非対称ルーティングのシナリオのいずれかが存在していないかどうかを確認することをお勧めします。

まず、次のネットワーク ダイアグラムに関連付けられたいくつかの異なる状況について説明します。この図では、受信要求を受信するすべてのサーバー (ADFS、オンプレミスのハイブリッド サーバーなど) は、ニュージャージーのデータセンターにあり、インターネットにアドバタイズされています。

  1. 境界ネットワークはセキュリティで保護されていますが、受信要求に使用できるソース NAT はありません。

  2. ニュージャージーのデータセンターにあるサーバーは、インターネットと ExpressRoute の両方のルートを確認できます。

ExpressRoute 接続の概要

ここでは、次の問題を修正する方法も提案します。

問題 1: インターネットを経由したクラウドからオンプレミスへの接続

次の図は、ネットワーク構成で、インターネットを経由した Microsoft クラウドからの受信要求用の NAT が指定されていない場合に生じる非対称ネットワーク パスを示しています。

  1. Office 365 からの受信要求は、オンプレミスのエンドポイントの IP アドレスをパブリック DNS から取得し、要求を境界ネットワークに送信します。

  2. この問題のある構成では、トラフィックが送信される境界ネットワークのソース NAT が構成されていないか、使用可能ではないため、実際のソース IP アドレスが返信先として使用されます。

    • ネットワーク上のサーバーは、リターン トラフィックを、使用可能な ExpressRoute ネットワーク接続を経由して Office 365 にルーティングします。

    • 結果として、Office 365 に対するそのフローのパスは非対称となり、接続エラーが発生します。

ExpressRoute 非対称ルーティングの問題 1

解決方法 1a: ソース NAT

受信要求にソース NAT を追加するだけで、このネットワーク構成の誤りを解決することができます。次の図では、

  1. 受信要求は引き続き、ニュージャージーのデータセンターにある境界ネットワークを経由して受信されます。今度は、ソース NAT が使用可能です。

  2. サーバーからの応答は、元の IP アドレスではなくソース NAT に関連付けられた IP 宛てにルーティングされるので、応答は同じネットワーク パスを経由して返されます。

ExpressRoute 非対称ルーティングの解決策 1

解決方法 1b: ルーティング範囲の指定

また、ExpressRoute BGP プレフィックスをアドバタイズできないようにして、それらのコンピューターの代替ネットワーク パスを削除することを選択することもできます。次の図では、

  1. 受信要求は引き続き、ニュージャージーのデータセンターにある境界ネットワークを経由して受信されます。今度は、ExpressRoute 回線を経由して Microsoft からアドバタイズされるプレフィックスをニュージャージーのデータセンターで使用することはできません。

  2. サーバーからの応答は、使用可能な唯一のルートを経由して、元の IP アドレスに関連付けられた IP 宛てにルーティングされるので、応答は同じネットワーク パスを経由して返されます。

ExpressRoute 非対称ルーティングの解決策 2

問題 2: ExpressRoute を経由したクラウドからオンプレミスへの接続

次の図は、ネットワーク構成で、ExpressRoute を経由した Microsoft クラウドからの受信要求用の NAT が指定されていない場合に生じる非対称ネットワーク パスを示しています。

  1. Office 365 からの受信要求は、IP アドレスを DNS から取得し、要求を境界ネットワークに送信します。

  2. この問題のある構成では、トラフィックが送信される境界ネットワークのソース NAT が構成されていないか、使用可能ではないため、実際のソース IP アドレスが返信先として使用されます。

    • ネットワーク上のコンピューターは、リターン トラフィックを、使用可能な ExpressRoute ネットワーク接続を経由して Office 365 にルーティングします。

    • 結果として、Office 365 に対する非対称接続が発生します。

ExpressRoute 非対称ルーティングの問題 2

解決方法 2: ソース NAT

受信要求にソース NAT を追加するだけで、このネットワーク構成の誤りを解決することができます。次の図では、

  1. 着信要求は引き続きニューヨークのデータ センターにある境界ネットワークを経由して受信されます。今度は、ソース NAT が使用可能です。

  2. サーバーからの応答は、元の IP アドレスではなくソース NAT に関連付けられた IP 宛てにルーティングされるので、応答は同じネットワーク パスを経由して返されます。

ExpressRoute 非対称ルーティングの解決策 3

ネットワーク設計に含まれるパスが対称であることを紙上で確認する

次に、実装計画において、Office 365 を使用するさまざまなシナリオに対してルート対称性が確保されていることを紙上で確認する必要があります。ユーザーがサービスのさまざまな機能を使用する場合に選択することが想定される特定のネットワーク ルート (オンプレミスのネットワークおよび WAN ルーティングから、境界デバイス、接続パス、ExpressRoute またはインターネット、オンライン エンドポイントへの接続まで) を識別します。

組織が採用するサービスとして事前に識別されたすべての Office 365 ネットワーク サービスについて、このネットワーク ルートの識別を行う必要があります。

他のユーザーと 2 人で、ルートを紙上でたどると、識別しやすくなります。各ネットワーク ホップが次のルートを取得することが想定される場所を説明し、ルーティング パスに精通しておく必要があります。ExpressRoute は常に、インターネットの既定のルートと比べて、Microsoft サーバーの IP アドレスへのより広い範囲のルートを提供するため、ルーティング コストが軽減されることを忘れないでください。

クライアント接続構成を設計する

PAC ファイルを ExpressRoute とともに使う

バインドされているインターネット プロキシ サーバーを使用している場合は、トラフィックして任意の PAC を調整する必要があります。 またはクライアント構成ファイルを Office 365 にプロキシ サーバー、および一部の Office 365 のトラフィックを含め、残りのトラフィックを移動する際に希望する ExpressRoute トラフィックを送信する、ネットワーク上のクライアント コンピューターが正しく構成されていることを確認するのには関連性の高いプロキシに送信します。PAC ファイルなど、 Office 365 の端点を管理するガイドを説明します。

注: エンドポイントは、頻繁に (週 1 回程度の頻度で) 変更されます。現状を維持する必要があるために変更回数を削減するには、組織が採用しているサービスおよび機能に基づいてのみ変更を行う必要があります。変更が通知され、過去のすべての変更に関する記録が保持されている RSS フィードの有効日には細心の注意を払ってください。通知された IP アドレスは、有効日になるまで、アドバタイズ、またはアドバタイズメントからの削除を行うことができない可能性があります。

展開およびテストの手順を策定する

展開計画には、テスト計画とロールバック計画の両方を含める必要があります。実装が期待どおりに機能していない場合、問題が検出される前に影響を受けるユーザー数が最小限に抑えられるように計画を策定する必要があります。計画で考慮する必要があるいくつかの基本的な原則を次に示します。

  1. ネットワーク セグメントとユーザー サービスのオンボーディングをステージングして中断を最小限に抑えます。

  2. インターネット接続されている個別のホストから traceroute と TCP 接続を使用してルートをテストする計画を立てます。

  3. 可能であれば、受信サービスと送信サービスのテストは、分離されたテスト用ネットワークでテスト用の Office 365 テナントを使用して行います。

    • あるいは、顧客がまだ Office 365 を使用していないか、パイロット段階にある場合は、テストを実稼働ネットワークで実行することができます。

    • あるいは、テストと監視のみを目的として用意された実稼働の停止期間にテストを実行することができます。

    • あるいは、各レイヤー 3 のルーター ノードでサービスごとにルートを確認することにより、テストを行うことができます。物理的なテストを実施しないとリスクが生じます。このフォールバックは他に可能なテストがない場合にのみ使用してください。

展開の手順は、大規模なユーザー グループに展開する前に、テストを実施できるように、小規模なユーザー グループに段階的にロール アウトする必要があります。次に、ExpressRoute を段階的に展開するためのいくつかの方法を示します。

  1. Microsoft ピアリングを使用して ExpressRoute を設定し、段階的なテスト専用の単一ホストにルート アドバタイズメントを転送します。

  2. 最初に、単一のネットワーク セグメントに ExpressRoute ネットワークへのルートをアドバタイズし、ネットワーク セグメントまたは地域別にルート アドバタイズメントを拡張します。

  3. Office 365 を初めて展開する場合は、少数のユーザーを対象としたパイロットとして ExpressRoute ネットワーク展開を使用します。

  4. プロキシ サーバーを使用する場合、別の方法として、詳細を追加する前に、テストとフィードバックを使用して、少数ユーザーを ExpressRoute にダイレクトするようにテスト用の PAC ファイルを構成することができます。

実装計画では、実行する必要がある展開手順、またはネットワーク構成の展開に使用する必要があるコマンドの一覧を作成する必要があります。ネットワークの停止期間が終了したら、あらかじめ作成されていた展開計画に対して行った変更をまとめて、ピア レビューを行います。ExpressRoute の技術的な構成については、Microsoft のガイダンスを参照してください。

  • 引き続き電子メールを送信するオンプレミス サーバーの IP アドレスを変更した場合は、SPF の TXT レコードを更新します。

  • 新しい NAT 構成を収容するために IP アドレスを変更した場合は、オンプレミス サーバーの DNS エントリを更新します。

  • ルーティングまたはプロキシの構成を保守するために、必ず、Office 365 エンドポイント通知用の RSS フィードの購読をお申し込みください。

ExpressRoute 展開が完了した後テスト プランの手順を実行する必要があります。各手順の結果を記録する必要があります。テスト プランの結果を示す実装できなかった場合に、元の運用環境に戻すための手順を追加する必要があります。

テスト手順には、Office 365 の各送信および受信ネットワーク サービスで、ExpressRoute を使用するものと使用しないものの両方のテストを含める必要があります。また、この手順には、企業 LAN 内のオンプレミスではないユーザーを含む固有の各ネットワークの場所からのテストを含める必要があります。

テスト アクティビティの例としては、次のようなものがあります。

  1. 内部設置型ルーターからネットワーク オペレーター ルーターに ping を実行します。

  2. 500 以上の Office 365 および CRM Online の IP アドレスのアドバタイズメントがオンプレミス ルーターによって受信されることを確認します。

  3. 送信 NAT および受信 NAT が ExpressRoute と内部ネットワーク間で動作していることを確認します。

  4. ルーターから、nat までの経路が提供されていることを確認します。

  5. ExpressRoute がアドバタイズされたプレフィックスを承諾したことを確認します。

    • ピアリング広告を確認するのには、次のコマンドレットを使用します。

    • Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
  6. 前述の例のように、パブリック NAT IP の範囲が大きな範囲の特定のサブセットではない限り、他の ExpressRoute 回線またはパブリック インターネット ネットワーク回線を経由して Microsoft にアドバタイズされていないことを確認します。

  7. ExpressRoute 回線がペア設定されており、両方の BGP セッションが実行されていることを確認します。

  8. NAT の内側に単一のホストをセットアップし、ping、tracert、tcpping を使用して、新しい回線を介したホスト outlook.office365.com への接続をテストします。また、ミラー化された MSEE ポートで Wireshark または Microsoft Network Monitor 3.4 などのツールを使用して、outlook.office365.com に関連付けられた IP アドレスに接続できるかどうかを確認することもできます。

  9. Exchange Online のアプリケーション レベルの機能をテストします。

    • Outlook が、Exchange Online に接続して、電子メールを送受信できるかどうかをテストします。

    • Outlook がオンラインモードを使用できるかどうかをテストします。

    • スマート フォンの接続と送受信の機能をテストします。

  10. SharePoint Online のアプリケーション レベルの機能をテストします。

    • OneDrive for Business 同期クライアントをテストします。

    • SharePoint Online の Web アクセスをテストします。

  11. Skype for Business の通話シナリオのアプリケーション レベルの機能をテストします。

    • 認証されたユーザーとして電話会議に参加します [エンドユーザーによって開始された招待]。

    • ユーザーを電話会議に招待します [MCU から送信された招待]。

    • Skype for Business Web アプリケーションを使用して、匿名ユーザーとして会議に参加します。

    • 優先接続された PC、IP 電話、携帯電話から電話会議に参加します。

    • フェデレーションされたユーザー o PSTN の入力規則に通話を着信: 通話が完了した、通話品質の確認が受け入れ可能、接続時間が受け入れ可能です。

    • テナントのメンバーとフェデレーション ユーザーの両方の連絡先のプレゼンス状態が更新されていることを確認します。

非対称のルーティングは、最も一般的な実装の問題です。ここでは、確認すべきいくつかの一般的な原因を示します。

  • ソース NAT を指定しないオープンまたはフラット状態のネットワーク ルーティング トポロジを使用している。

  • インターネット接続と ExpressRoute 接続の両方を経由した受信サービスのルーティングに SNAT を使用していない。

  • 広い範囲に展開する前にテスト ネットワークで ExpressRoute での受信サービスをテストしていない。

ネットワーク経由で ExpressRoute 接続を展開する

一度に 1 つのネットワーク セグメントずつ段階的に展開し、新しいネットワーク セグメントごとにロールバックする計画を使用してネットワークのさまざまな部分に接続を段階的にロールアウトします。目的の展開を Office 365 展開に合わせる場合は、まず、Office 365 パイロット ユーザーへの展開を行い、そこから拡張します。

まず、次の操作をテスト用に実施し、次に実稼働用に実施します。

  • 展開手順を実行して、ExpressRoute を有効にします。

  • ネットワーク ルートが予想通りに表示されるかテストします。

  • 各受信サービスおよび送信サービスでテストを実行します。

  • 問題が発生した場合は、ロールバックします。

紙上では計画を完了しているので、今度は小規模でのテストを実施します。このテストでは、Microsoft Peering を使用して、単一の ExpressRoute とオンプレミスのネットワーク上のテスト用サブネットとの接続を確立します。テスト用サブネットとの間の接続を使用して試用版の Office 365 テナントを構成し、運用環境で使用するすべての送信および受信サービスをテスト用サブネットに含めることができます。テスト用ネットワーク セグメントの DNS をセットアップして、すべての受信および送信サービスを設定します。テスト計画を実行し、各サービスのルーティングとルーティングの伝達に習熟していることを確認します。

前述の項目を完了したら、展開を実行して計画をテストする前に、完了した分野をチェックし、自分と自分のチームで、それらのレビューを行います。

  • ネットワークの変更に関係する送信および受信サービスの一覧。

  • インターネット送信と ExpressRoute の Meet-Me の場所の両方を示したグローバル ネットワーク アーキテクチャ ダイアグラム。

  • 展開された各サービスに使用されるさまざまなネットワーク パスを示したネットワーク ルーティング ダイアグラム。

  • 必要に応じて、変更とロールバックを実装するための手順を含む展開計画。

  • Office 365 およびネットワークの各サービスをテストするためのテスト計画。

  • 受信および送信サービスの運用ルートについて完了した紙上での検証。

  • 可用性のテストを含む、テスト用ネットワーク セグメントで完了したテスト。

展開計画全体とテスト計画を実行するための十分なネットワーク停止期間を選択します。必要に応じてトラブルシューティングを行うための時間とロールバックするための時間も必要です。

警告: インターネットと ExpressRoute の両方を経由したルーティングは複雑であるため、複雑なルーティングをトラブルシューティングするための予備の時間をこの停止期間に追加することをお勧めします。

QoS は、Skype for Business Online の音声と会議のメリットを得るために必要です。QoS は、ExpressRoute ネットワーク接続が他の Office 365 サービスのアクセスをブロックしないことを確認した後に構成することができます。QoS の構成については、記事「Skype for Business Online の ExpressRoute および QoS」で説明しています。

実装のトラブルシューティング

最初に調べる必要があるのは、この実装ガイドで説明した手順のうち、実装計画で実行していない手順はないかということです。エラーが繰り返し発生する可能性がある場合は、前に戻って、小規模のネットワーク テストをさらに実行し、エラーを修正してください。

テストで失敗した受信または送信サービスを特定し、失敗した各サービスの IP アドレスとサブネットを具体的に把握します。次に、紙上でネットワーク トポロジ ダイアグラムをたどり、ルーティングを検証します。ExpressRoute ルーティングがアドバタイズされる場所を具体的に確認し、可能な場合には、停止期間中にそのルーティングをテストして追跡します。

ネットワーク トレースで各顧客エンドポイントに PSPing を実行し、期待どおりにいることを検証するための元と移行先の IP アドレスを評価します。[Mail host] のポートを 25 に公開して、SNAT も、これが予想される場合に、元のソース IP アドレスを隠していることを確認するには、telnet を実行します。

ExpressRoute 接続を使用して Office 365 を展開する場合、ExpressRoute のネットワーク構成が最適に設計され、クライアント コンピューターなどのネットワーク上の他のコンポーネントも最適化されている必要があることにご注意ください。実行していない可能性のある手順のトラブルシューティングを行うには、この計画ガイドに加えて、Microsoft が作成した「パフォーマンスのトラブルシューティング Office 365 のプラン」も参照できます。

戻る場合は、ショート リンク https://aka.ms/implementexpressroute365 をご利用ください。

関連トピック

Office 365 への接続をネットワーク
Office 365 向け Azure ExpressRoute
の Office 365 の接続の管理 ExpressRoute
と Office 365 向け ExpressRoute ルーティング
ネットワークの計画と Office 365 向け ExpressRoute
(プレビュー版) のシナリオを Office 365 向け ExpressRoute で BGP を使用してコミュニティ
メディアの品質と Skype for Business Online でネットワーク接続のパフォーマンス
Skype for Business Online 用にネットワークを最適化する
ExpressRoute と Skype for Business Online ネットワーク通信
通話フロー ExpressRoute を使用して
基準計画とパフォーマンスの履歴を使用して Office 365 のパフォーマンスのチューニング
パフォーマンスOffice 365 のプランのトラブルシューティング
Office 365 の Url と IP アドレスの範囲
Office 365 のネットワークとパフォーマンスのチューニング

注: 機械翻訳についての免責事項: この記事の翻訳はコンピューター システムによって行われており、人間の手は加えられていません。マイクロソフトでは、英語を話さないユーザーがマイクロソフトの製品、サービス、テクノロジに関するコンテンツを理解するのに役立てるため、こうした機械翻訳を提供しています。記事は機械翻訳されているため、用語、構文、文法などに誤りがある場合があります。

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×