Microsoft 365 向け ExpressRoute の実装
この記事は、Microsoft 365 Enterpriseに適用されます。
ExpressRoute for Microsoft 365 は、多くのインターネットに接続する Microsoft 365 サービスへの代替ルーティング パスを提供します。 ExpressRoute for Microsoft 365 のアーキテクチャは、インターネット経由で既にアクセス可能な Microsoft 365 サービスのパブリック IP プレフィックスをプロビジョニングされた ExpressRoute 回線にアドバタイズし、その後、それらの IP プレフィックスをネットワークに再配布することに基づいています。 ExpressRoute を使用すると、多くの Microsoft 365 サービスに対して、インターネット経由と ExpressRoute 経由で複数の異なるルーティング パスを効果的に有効にすることができます。 ネットワーク上のこのルーティング状態は、内部ネットワーク トポロジの設計方法に大きな変化をもたらす可能性があります。
注:
Microsoft 365 の ExpressRoute は、ほとんどの状況でサービスに最適な接続モデルを提供しないため 、お勧めしません 。 そのため、この接続モデルを使用するには Microsoft の承認が必要です。 お客様のすべての要求を確認し、必要なまれなシナリオでのみ、Microsoft 365 の ExpressRoute を承認します。 詳細については 、ExpressRoute for Microsoft 365 ガイド を参照してください。また、生産性、ネットワーク、セキュリティ チームに関するドキュメントの包括的なレビューに従って、Microsoft アカウント チームと協力して、必要に応じて例外を送信してください。 Microsoft 365 のルート フィルターを作成しようとしている未承認のサブスクリプションには、 エラー メッセージが表示されます。
Microsoft 365 実装用の ExpressRoute を慎重に計画し、コア ネットワークとインターネットに挿入されたルートを持つ専用回線を介してルーティングを利用できるようにするネットワークの複雑さに対応する必要があります。 このガイドでユーザーとチームが詳細な計画とテストを実行しない場合、ExpressRoute 回線が有効になっていると、断続的または Microsoft 365 サービスへの接続が完全に失われるリスクが高くなります。
実装を成功させるには、インフラストラクチャ要件を分析し、詳細なネットワーク評価と設計を行い、段階的かつ制御された方法でロールアウトを慎重に計画し、詳細な検証とテスト計画を構築する必要があります。 大規模で分散された環境の場合、実装が数か月にわたって表示されるのは珍しいことではありません。 このガイドは、事前に計画を立てるのに役立つよう設計されています。
大規模なデプロイの成功には計画に 6 か月かかる場合があり、多くの場合、ネットワーク、ファイアウォールとプロキシ サーバー管理者、Microsoft 365 管理者、セキュリティ、エンドユーザー サポート、プロジェクト管理、エグゼクティブ スポンサーなど、organizationの多くの領域のチーム メンバーが含まれます。 計画プロセスへの投資により、デプロイエラーが発生し、ダウンタイムや複雑でコストのかかるトラブルシューティングが発生する可能性が低くなります。
この実装ガイドを開始する前に、次の前提条件が完了することを想定しています。
ネットワーク評価を完了して、ExpressRoute が推奨および承認されているかどうかを判断しました。
ExpressRoute ネットワーク サービス プロバイダーを選択しました。 ExpressRoute パートナーとピアリングの場所の詳細を確認します。
既に ExpressRoute のドキュメントを読んで理解しており、内部ネットワークは ExpressRoute の前提条件をエンドツーエンドで満たしています。
チームは、 のhttps://aka.ms/expressrouteoffice365https://aka.ms/ertパブリック ガイダンスとドキュメントをすべて読み、チャネル 9 の Azure ExpressRoute for Microsoft 365 トレーニング シリーズを見て、次のような重要な技術的な詳細を理解しました。
SaaS サービスのインターネットの依存関係。
非対称ルートを回避し、複雑なルーティングを処理する方法。
境界セキュリティ、可用性、アプリケーション レベルの制御を組み込む方法。
まず、要件を収集します
まず、organization内で採用する予定の機能とサービスを決定します。 さまざまな Microsoft 365 サービスのどの機能を使用し、ネットワーク上のどの場所でそれらの機能を使用してユーザーをホストするかを決定する必要があります。 シナリオのカタログでは、これらの各シナリオで必要なネットワーク属性を追加する必要があります。たとえば、受信および送信のネットワーク トラフィック フロー、および Microsoft 365 エンドポイントが ExpressRoute 経由で使用できるかどうかなどです。
organizationの要件を収集するには:
organizationが使用している Microsoft 365 サービスの受信および送信ネットワーク トラフィックをカタログ化します。 さまざまな Microsoft 365 シナリオで必要なフローの説明については、「Microsoft 365 URL と IP アドレス範囲」ページを参照してください。
内部 WAN バックボーンとトポロジの詳細、サテライト サイトの接続、最後の 1 マイルのユーザー接続、ネットワーク境界エグレス ポイントへのルーティング、プロキシ サービスを示す既存のネットワーク トポロジのドキュメントを収集します。
Microsoft 365 やその他の Microsoft サービスが接続するネットワークダイアグラム上の受信サービス エンドポイントを特定し、インターネットと提案された ExpressRoute 接続パスの両方を示します。
場所間のすべての地理的なユーザーの場所と WAN 接続を特定し、現在インターネットへのエグレスがある場所と、ExpressRoute ピアリングの場所へのエグレスが提案されている場所を特定します。
プロキシ、ファイアウォールなど、すべてのエッジ デバイスを特定し、インターネットと ExpressRoute を経由するフローとの関係をカタログ化します。
エンド ユーザーがダイレクト ルーティング経由で Microsoft 365 サービスにアクセスするか、インターネットフローと ExpressRoute フローの両方の間接アプリケーション プロキシにアクセスするかを文書化します。
テナントの場所とミートミーの場所をネットワーク ダイアグラムに追加します。
主要なユーザーの場所から Microsoft 365 までの予想される、観察されたネットワーク パフォーマンスと待機時間の特性を見積もります。 Microsoft 365 はグローバルで分散型のサービス セットであり、ユーザーはテナントの場所とは異なる可能性のある場所に接続することに注意してください。 このため、ExpressRoute とインターネット接続を介して、ユーザーと Microsoft グローバル ネットワークの最も近いエッジとの間の待機時間を測定して最適化することをお勧めします。 ネットワーク評価の結果を使用して、このタスクを支援できます。
新しい ExpressRoute 接続で満たす必要がある会社のネットワーク セキュリティと高可用性の要件を一覧表示します。 たとえば、インターネットエグレスまたは ExpressRoute 回線障害が発生した場合に、ユーザーが Microsoft 365 に引き続きアクセスできるようにする方法です。
受信および送信の Microsoft 365 ネットワーク フローがインターネット パスを使用し、ExpressRoute を使用するドキュメント。 ユーザーの地理的な場所の詳細とオンプレミス ネットワーク トポロジの詳細により、プランがユーザーの場所と別の場所とは異なる必要がある場合があります。
送信と受信のネットワーク トラフィックをカタログ化する
ルーティングやその他のネットワークの複雑さを最小限に抑えるために、規制要件やネットワーク評価の結果として、専用接続を経由するために必要なネットワーク トラフィック フローには、Microsoft 365 の ExpressRoute のみを使用することをお勧めします。 さらに、ExpressRoute ルーティングのスコープをステージングし、実装プロジェクトの異なる個別のステージとして送信および受信ネットワーク トラフィック フローにアプローチすることをお勧めします。 ユーザーが開始した送信ネットワーク トラフィック フローに対して ExpressRoute for Microsoft 365 を展開し、インターネット経由で受信ネットワーク トラフィック フローを残しておくと、トポロジの複雑さと非対称ルーティングの可能性が追加されるリスクの増加を制御するのに役立ちます。
ネットワーク トラフィック カタログには、オンプレミス ネットワークと Microsoft の間にあるすべての受信および送信ネットワーク接続の一覧が含まれている必要があります。
送信ネットワーク トラフィック フローは、内部クライアントやサーバーなど、Microsoft サービスの宛先を使用して、オンプレミス環境から接続が開始されるシナリオです。 これらの接続は、Microsoft 365 に直接送信される場合や、接続が Microsoft 365 へのパス上のプロキシ サーバー、ファイアウォール、またはその他のネットワーク デバイスを経由する場合など、間接的な場合があります。
受信ネットワーク トラフィック フローは、Microsoft クラウドからオンプレミス ホストへの接続が開始されるシナリオです。 通常、これらの接続は、外部から発信されたフローに対して顧客のセキュリティ ポリシーが必要とするファイアウォールやその他のセキュリティ インフラストラクチャを経由する必要があります。
「ルートの対称性の確保」セクションを参照して、受信トラフィックを送信するサービスを決定し、Microsoft 365 エンドポイントリファレンス記事で ExpressRoute for Microsoft 365 とマークされている列を探して、接続情報の残りの部分を特定します。
送信接続を必要とするサービスごとに、ネットワーク ルーティング、プロキシ構成、パケット検査、帯域幅のニーズなど、サービスの計画された接続について説明します。
受信接続を必要とするサービスごとに、追加情報が必要です。 Microsoft クラウド内のサーバーは、オンプレミス ネットワークへの接続を確立します。 接続が正しく行われるようにするには、この接続のすべての側面 (を含む) を記述する必要があります。これらの受信接続を受け入れるサービスのパブリック DNS エントリ、CIDR 形式の IPv4 IP アドレス、ISP 機器が関与する方法、およびこれらの接続に対する受信 NAT またはソース NAT の処理方法。
非対称ルーティングが導入されていないことを確認するために、インターネット経由または ExpressRoute 経由で接続しているかどうかに関係なく、受信接続を確認する必要があります。 場合によっては、Microsoft 365 サービスが受信接続を開始するオンプレミス エンドポイントも、他の Microsoft および Microsoft 以外のサービスからアクセスする必要があります。 Microsoft 365 の目的でこれらのサービスへの ExpressRoute ルーティングを有効にしても、他のシナリオが損なわれないことが最も重要です。 多くの場合、お客様は、ExpressRoute を有効にした後も Microsoft からの受信フローを対称的に保つため、ソース ベースの NAT など、内部ネットワークに特定の変更を実装する必要があります。
必要な詳細レベルのサンプルを次に示します。 この場合、Exchange Hybrid は ExpressRoute 経由でオンプレミス システムにルーティングされます。
| Connection プロパティ | 値 |
|---|---|
| ネットワーク トラフィックの方向 |
受信 |
| サービス |
Exchange ハイブリッド |
| パブリック Microsoft 365 エンドポイント (ソース) |
Exchange Online (IP アドレス) |
| パブリック オンプレミス エンドポイント (宛先) |
5.5.5.5 |
| パブリック (インターネット) DNS エントリ |
Autodiscover.contoso.com |
| このオンプレミス エンドポイントは、他の (Microsoft 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 |
| セキュリティ/境界コントロール |
インターネット パス: ExpressRoute パスDeviceID_002: DeviceID_003 |
| 高可用性 |
2 つの geo 冗長/ExpressRoute 回線にわたるアクティブ/アクティブ - シカゴとダラス |
| パス対称制御 |
方法: ソース NAT インターネット パス: 192.168.5.5 ExpressRoute パスへのソース NAT 受信接続: 192.168.1.0 (シカゴ) と 192.168.2.0 (ダラス) へのソース NAT 接続 |
送信専用のサービスのサンプルを次に示します。
| Connection プロパティ | 値 |
|---|---|
| ネットワーク トラフィックの方向 |
送信 |
| サービス |
SharePoint |
| オンプレミス エンドポイント (ソース) |
ユーザー ワークステーション |
| パブリック Microsoft 365 エンドポイント (宛先) |
SharePoint (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 つの geo 冗長 ExpressRoute 回線間のアクティブ/アクティブ "ホット ポテト" ルーティング - シカゴとダラス |
| パス対称制御 |
方法: すべての接続のソース NAT |
リージョン接続を使用したネットワーク トポロジの設計
サービスとそれに関連するネットワーク トラフィック フローを理解したら、これらの新しい接続要件を組み込んだネットワーク ダイアグラムを作成し、ExpressRoute for Microsoft 365 を使用するために行う変更を示します。 図には、次のものが含まれている必要があります。
Microsoft 365 やその他のサービスにアクセスするすべてのユーザーの場所。
すべてのインターネットおよび ExpressRoute エグレス ポイント。
ルーター、ファイアウォール、アプリケーション プロキシ サーバー、侵入検出/防止など、ネットワークとの間の接続を管理するすべての送信および受信デバイス。
ADFS Web アプリケーション プロキシ サーバーからの接続を受け入れる内部 ADFS サーバーなど、すべての受信トラフィックの内部宛先。
アドバタイズされるすべての IP サブネットのカタログ
ユーザーが Microsoft 365 にアクセスする各場所を特定し、ExpressRoute に使用されるミートミーの場所を一覧表示します。
ExpressRoute から学習した Microsoft IP プレフィックスが受け入れられ、フィルター処理され、伝達される内部ネットワーク トポロジの場所と部分。
ネットワーク トポロジは、各ネットワーク セグメントの地理的な場所と、ExpressRoute またはインターネット経由で Microsoft ネットワークに接続する方法を示す必要があります。
次の図は、ユーザーが Microsoft 365 を使用する各場所と、Microsoft 365 への受信および送信ルーティングアドバタイズを示しています。
送信トラフィックの場合、ユーザーは次の 3 つの方法のいずれかで Microsoft 365 にアクセスします。
カリフォルニアの人々のための北米のミートミーの場所を通じて。
香港特別行政区の人々のためのミートミーの場所を通じて。
人が少なく、ExpressRoute 回線がプロビジョニングされていないバングラデシュのインターネット経由。
同様に、Microsoft 365 からの受信ネットワーク トラフィックは、次の 3 つの方法のいずれかで返されます。
カリフォルニアの人々のための北米のミートミーの場所を通じて。
香港特別行政区の人々のためのミートミーの場所を通じて。
人が少なく、ExpressRoute 回線がプロビジョニングされていないバングラデシュのインターネット経由。
適切なミートミーの場所を決定する
ExpressRoute 回線がネットワークを Microsoft ネットワークに接続する物理的な場所であるミートミーの場所の選択は、ユーザーが Microsoft 365 にアクセスする場所の影響を受けます。 SaaS オファリングとして、Microsoft 365 は Azure と同じように IaaS または PaaS リージョン モデルで動作しません。 代わりに、Microsoft 365 は、ユーザーが複数のデータセンターとリージョン間でエンドポイントに接続する必要がある場合があり、ユーザーのテナントがホストされているのと同じ場所またはリージョンにあるとは限らない、分散型コラボレーション サービスのセットです。
つまり、ExpressRoute for Microsoft 365 のミートミーの場所を選択する際に必要な最も重要な考慮事項は、organizationのユーザーが接続する場所です。 最適な Microsoft 365 接続の一般的な推奨事項は、ルーティングを実装することです。これにより、Microsoft 365 サービスへのユーザー要求が最短のネットワーク パスを介して Microsoft ネットワークに渡されます。これは、多くの場合、"ホット ポテト" ルーティングとも呼ばれます。 たとえば、ほとんどの Microsoft 365 ユーザーが 1 つまたは 2 つの場所にいる場合、それらのユーザーの場所に最も近い場所にあるミートミーの場所を選択すると、最適な設計が作成されます。 会社のユーザー人口が多い地域が多い場合は、複数の ExpressRoute 回線とミートミーの場所を使用することを検討してください。 一部のユーザーの場所では、Microsoft ネットワークと Microsoft 365 への最短/最も最適なパスは、内部 WAN と ExpressRoute のミートミー ポイントではなく、インターネット経由である可能性があります。
多くの場合、ユーザーとの距離が相対的に近いリージョン内で選択できる複数のミートミーの場所があります。 次の表を入力して、決定を導きます。
計画された ExpressRoute meet-me の場所 (カリフォルニアとニューヨーク)
| 場所 |
ユーザー数 |
インターネットエグレス経由の Microsoft ネットワークへの予想待機時間 |
ExpressRoute 経由の Microsoft ネットワークへの予想待機時間 |
|---|---|---|---|
| Los Angeles |
10,000 |
~15ms |
~10ms (シリコン バレー経由) |
| ワシントン DC |
15,000 |
~20ms |
約 10 ミリ秒 (ニューヨーク経由) |
| ダラス |
5,000 |
~15ms |
約 40 ミリ秒 (ニューヨーク経由) |
Microsoft 365 リージョン、ExpressRoute ネットワーク サービス プロバイダーの meet-me の場所、場所別のユーザーの数を示すグローバル ネットワーク アーキテクチャを開発したら、最適化を行うことができるかどうかを識別するために使用できます。 また、ミートミーの場所を取得するために、トラフィックが遠くの場所にルーティングされるグローバル ヘアピン ネットワーク接続も表示される場合があります。 グローバル ネットワーク上のヘアピンが検出された場合は、続行する前に修復する必要があります。 別の meet-me の場所を見つけるか、選択的なインターネット ブレークアウトエグレス ポイントを使用してヘアピンを回避します。
最初の図は、北米に 2 つの物理的な場所を持つ顧客の例を示しています。 Office の場所、Microsoft 365 テナントの場所、および ExpressRoute のミートミーの場所に関するいくつかの選択肢に関する情報を確認できます。 この例では、顧客は次の 2 つの原則に基づいて、次の順序でミートミーの場所を選択しています。
organizationの人々に最も近い。
Microsoft 365 がホストされている Microsoft データセンターに最も近い。
この概念をさらに拡張した 2 番目の図は、類似の情報と意思決定に直面した複数国の顧客の例を示しています。 この顧客はバングラデシュに小規模なオフィスを持ち、10人の小さなチームだけが地域でのフットプリントの拡大に焦点を当てています。 チェンナイにはミートミーの場所があり、Microsoft 365 がチェンナイでホストされている Microsoft データセンターがあるため、ミートミーの場所が理にかなっています。しかし、10人の場合、余分な回路の費用は負担になります。 ネットワークを見ると、ネットワーク経由でネットワーク トラフィックを送信する際の待機時間が、別の ExpressRoute 回線の取得に資本を費やすよりも効果的かどうかを判断する必要があります。
または、バングラデシュの 10 人のユーザーは、インターネット経由で Microsoft ネットワークに送信されるネットワーク トラフィックのパフォーマンスが、次の入門図で示されているように、内部ネットワーク上でルーティングするよりも優れたパフォーマンスを実現する可能性があります。
ExpressRoute for Microsoft 365 の実装計画をCreateする
実装計画には、ExpressRoute の構成に関する技術的な詳細と、次のようなネットワーク上の他のすべてのインフラストラクチャの構成の詳細の両方が含まれている必要があります。
ExpressRoute とインターネットの間で分割されるサービスを計画します。
帯域幅、セキュリティ、高可用性、フェールオーバーを計画します。
さまざまな場所に対する適切なルーティング パスの最適化など、受信と送信のルーティングを設計する
ExpressRoute ルートをネットワークにどの程度アドバタイズするか、クライアントがインターネットまたは ExpressRoute パスを選択するメカニズムを決定します。たとえば、ダイレクト ルーティングやアプリケーション プロキシなどです。
Sender Policy Framework エントリなど、DNS レコードの変更を計画します。
送信および受信ソース NAT を含む NAT 戦略を計画します。
インターネットと ExpressRoute の両方のネットワーク パスを使用してルーティングを計画する
初期デプロイでは、受信メールやハイブリッド接続など、すべての受信サービスがインターネットを使用することをお勧めします。
PAC/WPAD ファイル、既定のルート、プロキシ サーバー、BGP ルートアドバタイズメントの構成など、エンド ユーザー クライアント LAN ルーティングを計画します。
プロキシ サーバー、ファイアウォール、クラウド プロキシなど、境界ルーティングを計画します。
帯域幅、セキュリティ、高可用性、フェールオーバーを計画する
主要な Microsoft 365 ワークロードごとに必要な帯域幅の計画をCreateします。 Exchange Online、SharePoint、Skype for Businessオンライン帯域幅の要件を個別に見積もります。 Exchange OnlineとSkype for Businessのために提供した見積もり計算ツールを出発点として使用できますが、organizationの帯域幅のニーズを完全に理解するには、ユーザー プロファイルと場所の代表的なサンプルを使用したパイロット テストが必要です。
各インターネットと ExpressRoute エグレスの場所でのセキュリティの処理方法をプランに追加します。Microsoft 365 への ExpressRoute 接続はすべてパブリック ピアリングを使用しており、外部ネットワークへの接続に関する会社のセキュリティ ポリシーに従ってセキュリティ保護する必要があります。
プランに、どの種類の停止によって影響を受けるユーザーと、それらのユーザーが最も簡単な方法で最大限に作業を実行できるかに関する詳細を計画に追加します。
ジッター、待機時間、輻輳、ヘッドルームに関するSkype for Business要件を含む帯域幅要件を計画する
Skype for Business Online には、Skype for Business Online のメディア品質とネットワーク接続パフォーマンスに関する記事で詳しく説明されている、特定の追加のネットワーク要件もあります。
「Azure ExpressRoute の帯域幅計画」セクションを参照してください。 パイロット ユーザーに対して帯域幅評価を実行する場合は、 ベースラインとパフォーマンス履歴を使用して Microsoft 365 のパフォーマンス チューニングガイドを使用できます。
高可用性要件を計画する
ニーズを満たすために高可用性の計画をCreateし、更新されたネットワーク トポロジ図に組み込みます。 「 Azure ExpressRoute を使用した高可用性とフェールオーバー」セクションを参照してください。
ネットワーク セキュリティ要件を計画する
ネットワーク セキュリティ要件を満たす計画をCreateし、更新されたネットワーク トポロジ図に組み込みます。 「 Microsoft 365 シナリオの Azure ExpressRoute にセキュリティ 制御を適用する」セクションを参照してください。
送信サービス接続を設計する
ExpressRoute for Microsoft 365 には、なじみのない 送信 ネットワーク要件があります。 具体的には、Microsoft 365 へのユーザーとネットワークを表し、Microsoft への送信ネットワーク接続のソース エンドポイントとして機能する IP アドレスは、次に示す特定の要件に従う必要があります。
エンドポイントは、会社または ExpressRoute 接続を提供する通信事業者に登録されているパブリック IP アドレスである必要があります。
エンドポイントは Microsoft にアドバタイズされ、ExpressRoute によって検証/受け入れられる必要があります。
エンドポイントは、同じまたはより優先されるルーティング メトリックを使用してインターネットにアドバタイズしないでください。
エンドポイントは、ExpressRoute 経由で構成されていない Microsoft サービスへの接続に使用しないでください。
ネットワーク設計がこれらの要件を満たしていない場合、ルートのブラック ホリングまたは非対称ルーティングにより、ユーザーが Microsoft 365 やその他の Microsoft サービスへの接続エラーを経験するリスクが高くなります。 これは、Microsoft サービスへの要求が ExpressRoute 経由でルーティングされるが、応答がインターネット経由でルーティングされるか、またはその逆にルーティングされ、応答がファイアウォールなどのステートフル ネットワーク デバイスによって破棄される場合に発生します。
上記の要件を満たすために使用できる最も一般的な方法は、ネットワークの一部として実装されているか、ExpressRoute 通信事業者によって提供されるソース NAT を使用することです。 ソース NAT を使用すると、ExpressRoute からインターネット ネットワークの詳細とプライベート IP アドレスを抽象化できます。適切な IP ルート アドバタイズと組み合わせて、パス対称性を確保するための簡単なメカニズムを提供します。 ExpressRoute ピアリングの場所に固有のステートフル ネットワーク デバイスを使用している場合は、パスの対称性を確保するために、ExpressRoute ピアリングごとに個別の NAT プールを実装する必要があります。
ExpressRoute NAT の要件の詳細については、こちらをご覧ください。
送信接続の変更をネットワーク トポロジ図に追加します。
受信サービス接続を設計する
ほとんどのエンタープライズ Microsoft 365 展開では、Exchange、SharePoint、Skype for Business ハイブリッド シナリオ、メールボックスの移行、ADFS インフラストラクチャを使用した認証など、Microsoft 365 からオンプレミス サービスへの何らかの形式の受信接続が想定されています。 ExpressRoute で送信接続のためにオンプレミス ネットワークと Microsoft の間で余分なルーティング パスを有効にすると、これらのフローでインターネットを引き続き使用する場合でも、これらの受信接続が非対称ルーティングによって誤って影響を受ける可能性があります。 Microsoft 365 からオンプレミス システムへのインターネット ベースの受信フローに影響を与えないことを確認するために、以下で説明するいくつかの予防策をお勧めします。
受信ネットワーク トラフィック フローの非対称ルーティングのリスクを最小限に抑えるには、すべての受信接続で、ExpressRoute へのルーティングの可視性を持つネットワークのセグメントにルーティングする前に、ソース NAT を使用する必要があります。 送信元 NAT なしで ExpressRoute へのルーティングの可視性を持つネットワーク セグメントへの受信接続が許可されている場合、Microsoft 365 からの要求はインターネットから送信されますが、Microsoft 365 に戻る応答は、Microsoft ネットワークへの ExpressRoute ネットワーク パスを優先し、非対称ルーティングを引き起こします。
この要件を満たすために、次のいずれかの実装パターンを検討できます。
インターネットからオンプレミス システムへのパス上のファイアウォールやロード バランサーなどのネットワーク機器を使用して、要求が内部ネットワークにルーティングされる前に、ソース NAT を実行します。
ExpressRoute ルートが、フロントエンド サーバーやリバース プロキシ システムなどの受信サービスが存在するネットワーク セグメントに伝達されないようにします。
ネットワーク内のこれらのシナリオを明示的に説明し、インターネット経由のすべての受信ネットワーク トラフィック フローを維持することで、非対称ルーティングの展開と運用リスクを最小限に抑えることができます。
ExpressRoute 接続経由で一部の受信フローを送信する場合があります。 これらのシナリオでは、次の追加の考慮事項を考慮してください。
Microsoft 365 では、パブリック IP を使用するオンプレミス エンドポイントのみを対象にすることができます。 つまり、オンプレミスの受信エンドポイントが ExpressRoute 経由で Microsoft 365 にのみ公開されている場合でも、パブリック IP が関連付けられている必要があります。
Microsoft 365 サービスがオンプレミス エンドポイントを解決するために実行するすべての DNS 名前解決は、パブリック DNS を使用して行われます。 つまり、受信サービス エンドポイントの FQDN をインターネット上の IP マッピングに登録する必要があります。
ExpressRoute 経由で受信ネットワーク接続を受信するには、これらのエンドポイントのパブリック IP サブネットを ExpressRoute 経由で Microsoft にアドバタイズする必要があります。
これらの受信ネットワーク トラフィック フローを慎重に評価して、会社のセキュリティとネットワーク ポリシーに従って適切なセキュリティとネットワーク制御が適用されるようにします。
オンプレミスの受信エンドポイントが ExpressRoute 経由で Microsoft にアドバタイズされると、ExpressRoute は実質的に、Microsoft 365 を含むすべての Microsoft サービスでこれらのエンドポイントへの優先ルーティング パスになります。 つまり、これらのエンドポイント サブネットは、Microsoft 365 サービスとの通信にのみ使用する必要があり、Microsoft ネットワーク上の他のサービスは使用できません。 それ以外の場合、設計によって非対称ルーティングが発生します。この場合、他の Microsoft サービスからの受信接続は ExpressRoute 経由で受信をルーティングしますが、リターン パスではインターネットが使用されます。
ExpressRoute 回線またはミートミーの場所がダウンした場合は、別のネットワーク パス経由で要求を受け入れるために、オンプレミスの受信エンドポイントを引き続き使用できるようにする必要があります。 これは、複数の ExpressRoute 回線を介してこれらのエンドポイントのサブネットをアドバタイズする場合があります。
特に、これらのフローがファイアウォールなどのステートフル ネットワーク デバイスを通過する場合は、ExpressRoute 経由でネットワークに入るすべての受信ネットワーク トラフィック フローにソース NAT を適用することをお勧めします。
ADFS プロキシや Exchange 自動検出などの一部のオンプレミス サービスは、Microsoft 365 サービスとインターネットからのユーザーの両方から受信要求を受け取る場合があります。 これらの要求の場合、Microsoft 365 はインターネット経由のユーザー要求と同じ FQDN をターゲットにします。 インターネットからそれらのオンプレミス エンドポイントへの受信ユーザー接続を許可すると同時に、Microsoft 365 接続で ExpressRoute を使用することを強制すると、ルーティングが大幅に複雑になります。 ExpressRoute 経由でこのような複雑なシナリオを実装しているお客様の大半は、運用上の考慮事項のため推奨されません。 この追加のオーバーヘッドには、非対称ルーティングのリスクの管理が含まれます。また、複数のディメンションにわたってルーティングアドバタイズとポリシーを慎重に管理する必要があります。
ネットワーク トポロジプランを更新して、非対称ルートを回避する方法を示します
organizationのユーザーが Microsoft 365 やインターネット上の他の重要なサービスをシームレスに使用できるように、非対称ルーティングを回避する必要があります。 非対称ルーティングの原因となる一般的な構成は 2 つあります。 ここで、使用する予定のネットワーク構成を確認し、これらの非対称ルーティング シナリオのいずれかが存在する可能性があるかどうかをチェックします。
まず、次のネットワーク図に関連するいくつかの異なる状況について説明します。 この図では、ADFS やオンプレミスのハイブリッド サーバーなど、受信要求を受信するすべてのサーバーがニュージャージー のデータ センターにあり、インターネットにアドバタイズされます。
境界ネットワークはセキュリティで保護されていますが、受信要求に使用できるソース NAT はありません。
ニュージャージー のデータ センター内のサーバーは、インターネットルートと ExpressRoute ルートの両方を確認できます。
また、修正方法に関する提案もあります。
問題 1: インターネット経由のクラウドからオンプレミスへの接続
次の図は、ネットワーク構成でインターネット経由の Microsoft クラウドからの受信要求に NAT が提供されない場合に使用される非対称ネットワーク パスを示しています。
Microsoft 365 からの受信要求は、パブリック DNS からオンプレミス エンドポイントの IP アドレスを取得し、境界ネットワークに要求を送信します。
この障害が発生した構成では、トラフィックが送信される境界ネットワークでソース NAT が構成されていないか、使用可能でないため、実際の送信元 IP アドレスが戻り先として使用されます。
ネットワーク上のサーバーは、使用可能な ExpressRoute ネットワーク接続を介して、戻りトラフィックを Microsoft 365 にルーティングします。
その結果、Microsoft 365 へのそのフローの非対称パスが作成され、接続が切断されます。
解決策 1a: ソース NAT
受信要求にソース NAT を追加するだけで、この正しく構成されていないネットワークが解決されます。 この図では次のようになっています。
受信要求は、引き続きニュージャージー データ センターの境界ネットワークを介して入力されます。 今回はソース NAT を使用できます。
サーバーからの応答は、元の IP アドレスではなくソース NAT に関連付けられている IP に戻り、その結果、応答は同じネットワーク パスに沿って返されます。
解決策 1b: ルート スコーピング
または、ExpressRoute BGP プレフィックスのアドバタイズを許可しないことを選択して、それらのコンピューターの代替ネットワーク パスを削除することもできます。 この図では次のようになっています。
受信要求は、引き続きニュージャージー データ センターの境界ネットワークを介して入力されます。 今回は、ExpressRoute 回線経由で Microsoft からアドバタイズされたプレフィックスは、ニュージャージー のデータ センターでは使用できません。
サーバーからの応答は、使用可能な唯一のルート経由で元の IP アドレスに関連付けられている IP に戻り、その結果、応答は同じネットワーク パスに沿って返されます。
問題 2: ExpressRoute 経由のクラウドからオンプレミスへの接続
次の図は、ネットワーク構成で ExpressRoute 経由の Microsoft クラウドからの受信要求に NAT が提供されない場合に取得される非対称ネットワーク パスを示しています。
Microsoft 365 からの受信要求は、DNS から IP アドレスを取得し、境界ネットワークに要求を送信します。
この障害が発生した構成では、トラフィックが送信される境界ネットワークでソース NAT が構成されていないか、使用可能でないため、実際の送信元 IP アドレスが戻り先として使用されます。
ネットワーク上のコンピューターは、使用可能な ExpressRoute ネットワーク接続を介して、戻りトラフィックを Microsoft 365 にルーティングします。
その結果、Microsoft 365 への非対称接続になります。
解決策 2: ソース NAT
受信要求にソース NAT を追加するだけで、この正しく構成されていないネットワークが解決されます。 この図では次のようになっています。
受信要求は、引き続きニューヨーク のデータ センターの境界ネットワークを介して入力されます。 今回はソース NAT を使用できます。
サーバーからの応答は、元の IP アドレスではなくソース NAT に関連付けられている IP に戻り、その結果、応答は同じネットワーク パスに沿って返されます。
論文では、ネットワーク設計にパス対称性があることを確認する
この時点で、実装計画で、Microsoft 365 を使用するさまざまなシナリオのルート 対称性が提供されていることを紙で確認する必要があります。 ユーザーがサービスのさまざまな機能を使用する場合に実行されることが予想される特定のネットワーク ルートを特定します。 オンプレミス ネットワークと WAN ルーティングから境界デバイス、接続パスへ。ExpressRoute またはインターネット、およびオンライン エンドポイントへの接続。
これは、organizationが採用するサービスとして以前に識別されたすべての Microsoft 365 ネットワーク サービスに対して行う必要があります。
これは、2 人目の人と一緒にルートのこのペーパー ウォークスルーを行うのに役立ちます。 各ネットワーク ホップが次のルートを取得する必要がある場所を説明し、ルーティング パスを理解していることを確認します。 ExpressRoute では、Microsoft サーバーの IP アドレスに対して常にスコープが設定されたルートが提供されるため、インターネットの既定のルートよりもルート コストが低くなります。
クライアント接続の構成を設計する
インターネットにバインドされたトラフィックにプロキシ サーバーを使用している場合は、ネットワーク上のクライアント コンピューターがプロキシ サーバーを転送せずに Microsoft 365 に ExpressRoute トラフィックを送信するように正しく構成され、一部の Microsoft 365 トラフィックを含む残りのトラフィックが関連するプロキシに送信されるように、PAC またはクライアント構成ファイルを調整する必要があります。 PAC ファイルなど、 Microsoft 365 エンドポイントの管理に関するガイドをお読みください。
注:
エンドポイントは、毎週のように頻繁に変更されます。 最新の状態を維持するために必要な変更の数を減らすために、organizationが採用したサービスと機能に基づいてのみ変更を加える必要があります。 変更が発表され、過去のすべての変更のレコードが保持される RSS フィードの 有効日 に細心の注意を払います。通知された IP アドレスは、有効日に達するまでアドバタイズされないか、広告から削除される可能性があります。
ルートの対称性の確保
Microsoft 365 フロントエンド サーバーには、インターネットと ExpressRoute の両方でアクセスできます。 これらのサーバーは、どちらも使用可能な場合は、ExpressRoute 回線経由でオンプレミスに戻す必要があります。 このため、ネットワークからのトラフィックがインターネット回線経由でルーティングすることを好む場合は、ルートの非対称性が発生する可能性があります。 ステートフル パケット検査を実行するデバイスは、送信パケットの後に続く別のパスに続くリターン トラフィックをブロックできるため、非対称ルートは問題です。
インターネットまたは ExpressRoute 経由で Microsoft 365 への接続を開始するかどうかにかかわらず、ソースはパブリックにルーティング可能なアドレスである必要があります。 多くのお客様が Microsoft と直接ピアリングしている場合、顧客間で重複が可能なプライベート アドレスを持つことは不可能です。
Microsoft 365 からオンプレミス ネットワークへの通信が開始されるシナリオを次に示します。 ネットワーク設計を簡略化するために、インターネット パス経由で次のルーティングを行うことをお勧めします。
Exchange Online テナントからオンプレミス ホストへのメールや、SharePoint からオンプレミス ホストに送信される SharePoint メールなどの SMTP サービス。 SMTP プロトコルは、ExpressRoute 回線で共有されるルート プレフィックスよりも Microsoft のネットワーク内で広く使用され、ExpressRoute 経由でオンプレミスの SMTP サーバーをアドバタイズすると、これらの他のサービスでエラーが発生します。
サインインのパスワード検証中の ADFS。
ハイブリッドフェデレーションまたはSkype for BusinessフェデレーションをSkype for Businessします。
Microsoft がこれらの双方向トラフィック フローのためにネットワークにルーティングし直すには、オンプレミス デバイスへの BGP ルートを Microsoft と共有する必要があります。 ExpressRoute 経由でルート プレフィックスを Microsoft にアドバタイズする場合は、次のベスト プラクティスに従う必要があります。
パブリック インターネットと ExpressRoute 経由で同じパブリック IP アドレス ルート プレフィックスをアドバタイズしないでください。 ExpressRoute 経由の Microsoft への IP BGP ルート プレフィックスアドバタイズは、インターネットにまったくアドバタイズされない範囲から提供することをお勧めします。 使用可能な IP アドレス空間が原因でこれを実現できない場合は、どのインターネット回線よりも ExpressRoute 経由で特定の範囲をアドバタイズすることが不可欠です。
ExpressRoute 回線ごとに個別の NAT IP プールを使用し、インターネット回線とは別に使用します。
Microsoft にアドバタイズされたルートは、ExpressRoute 経由でネットワークにアドバタイズされるルートだけでなく、Microsoft のネットワーク内の任意のサーバーからのネットワーク トラフィックを引き付けます。 ルーティング シナリオが定義され、チームによって十分に理解されているサーバーにのみルートをアドバタイズします。 ネットワークから複数の ExpressRoute 回線のそれぞれに個別の IP アドレス ルート プレフィックスをアドバタイズします。
Azure ExpressRoute を使用した高可用性とフェールオーバー
ExpressRoute を使用して各エグレスから ExpressRoute プロバイダーに少なくとも 2 つのアクティブ回線をプロビジョニングすることをお勧めします。 これは、お客様にエラーが発生する最も一般的な場所であり、アクティブ/アクティブ ExpressRoute 回線のペアをプロビジョニングすることで簡単に回避できます。 また、多くの Microsoft 365 サービスはインターネット経由でのみ利用できるため、少なくとも 2 つのアクティブ/アクティブインターネット回線をお勧めします。
ネットワークのエグレス ポイント内には、他の多くのデバイスや回線があり、ユーザーが可用性を認識する際に重要な役割を果たします。 接続シナリオのこれらの部分は、ExpressRoute または Microsoft 365 SLA ではカバーされませんが、organizationのユーザーが認識するエンドツーエンドサービスの可用性において重要な役割を果たします。
Microsoft 365 を使用して運用しているユーザーに焦点を当て、1 つのコンポーネントの障害がサービスを使用するユーザーのエクスペリエンスに影響を与える場合は、影響を受けるユーザーの合計割合を制限する方法を探します。 フェールオーバー モードが運用上複雑な場合は、復旧に長い時間の人々の経験を考慮し、運用上単純で自動化されたフェールオーバー モードを探します。
ネットワークの外部では、Microsoft 365、ExpressRoute、および ExpressRoute プロバイダーの可用性レベルがすべて異なります。
サービスの可用性
Microsoft 365 サービスは、個々のサービスのアップタイムと可用性メトリックを含む、適切に定義された サービス レベルアグリーメントでカバーされています。 Microsoft 365 がこのような高いサービス可用性レベルを維持できる理由の 1 つは、グローバルな Microsoft ネットワークを使用して、個々のコンポーネントが多くの Microsoft データセンター間でシームレスにフェールオーバーできることです。 このフェールオーバーは、データセンターとネットワークから複数のインターネットエグレス ポイントに拡張され、サービスを使用するユーザーの観点からシームレスにフェールオーバーを可能にします。
ExpressRoute は、Microsoft Network Edge と ExpressRoute プロバイダーまたはパートナー インフラストラクチャの間の個々の専用回線で 99.9% の可用性 SLA を提供 します。 これらのサービス レベルは ExpressRoute 回線レベルで適用されます。これは、冗長な Microsoft 機器と各ピアリング場所のネットワーク プロバイダー機器の間の 2 つの独立した相互接続 で構成されます。
プロバイダーの可用性
- Microsoft のサービス レベルの手配は、ExpressRoute プロバイダーまたはパートナーで停止します。 これは、可用性レベルに影響を与える選択を行うことができる最初の場所でもあります。 ExpressRoute プロバイダーが提供するアーキテクチャ、可用性、回復性の特性を、各 Microsoft ピアリングの場所でネットワーク境界とプロバイダー接続の間で密接に評価する必要があります。 冗長性、ピアリング機器、通信事業者が提供する WAN 回線、NAT サービスやマネージド ファイアウォールなどの追加の付加価値サービスの論理面と物理的側面の両方に細心の注意を払います。
可用性プランの設計
Microsoft 365 のエンドツーエンド接続シナリオに対する高可用性と回復性を計画して設計することを強くお勧めします。 デザインには を含める必要があります。
インターネット回線と ExpressRoute 回線の両方を含め、単一障害点はありません。
影響を受けるユーザーの数とその影響の期間を最小限に抑え、予想されるほとんどの障害モードに対する影響を最小限に抑えます。
最も予想される障害モードからの単純、反復可能、自動復旧プロセスの最適化。
冗長パスを介してネットワーク トラフィックと機能の完全な要求をサポートします。大幅な低下はありません。
接続シナリオには、Microsoft 365 への複数の独立したアクティブなネットワーク パス用に最適化されたネットワーク トポロジが含まれている必要があります。 これにより、個々のデバイスレベルまたは機器レベルでの冗長性のためにのみ最適化されたトポロジよりも、エンドツーエンドの可用性が向上します。
ヒント
ユーザーが複数の大陸または地理的なリージョンに分散しており、それらの各場所が冗長 WAN 回線経由で 1 つの ExpressRoute 回線が配置されている 1 つのオンプレミスの場所に接続する場合、ユーザーは、異なるリージョンを最も近いピアリングの場所に接続する独立した ExpressRoute 回線を含むネットワーク トポロジ設計よりも、エンドツーエンドのサービスの可用性が低くなります。
各回線が異なる地理的ピアリングの場所に接続されている ExpressRoute 回線を少なくとも 2 つプロビジョニングすることをお勧めします。 ユーザーが Microsoft 365 サービスに ExpressRoute 接続を使用するすべてのリージョンに対して、このアクティブとアクティブの回線のペアをプロビジョニングする必要があります。 これにより、データセンターやピアリングの場所などの主要な場所に影響を与える障害発生時に、各リージョンを接続したままにできます。 これらをアクティブ/アクティブとして構成すると、エンド ユーザー トラフィックを複数のネットワーク パスに分散できます。 これにより、デバイスまたはネットワーク機器の停止中に影響を受けるユーザーの範囲が縮小されます。
インターネットをバックアップとして 1 つの ExpressRoute 回線を使用することはお勧めしません。
例: フェールオーバーと高可用性
Contoso のマルチ地理的な設計では、ルーティング、帯域幅、セキュリティのレビューが行われ、高可用性レビューを行う必要があります。 Contoso は、高可用性について 3 つのカテゴリをカバーしていると考えます。回復性、信頼性、冗長性。
回復性により、Contoso は障害から迅速に復旧できます。 信頼性により、Contoso はシステム内で一貫した結果を提供できます。 冗長性により、Contoso はインフラストラクチャの 1 つ以上のミラー化されたインスタンス間を移動できます。
各エッジ構成内には、冗長なファイアウォール、プロキシ、IDS があります。 北米では、Contoso はダラスのデータセンターに 1 つのエッジ構成を、バージニアデータセンターに別のエッジ構成を持っています。 各場所の冗長機器は、その場所に対する回復性を提供します。
Contoso のネットワーク構成は、いくつかの重要な原則に基づいて構築されています。
各地理的リージョン内には、複数の Azure ExpressRoute 回線があります。
リージョン内の各回線は、そのリージョン内のすべてのネットワーク トラフィックをサポートできます。
ルーティングでは、可用性、場所などに応じて、どちらか一方のパスが明確に優先されます。
Azure ExpressRoute 回線間のフェールオーバーは、Contoso が追加の構成またはアクションを必要とせずに自動的に実行されます。
インターネット回線間のフェールオーバーは、Contoso が追加の構成またはアクションを必要とせずに自動的に実行されます。
この構成では、物理レベルと仮想レベルの冗長性を備えた Contoso は、ローカルの回復性、リージョンの回復性、グローバルな回復性を信頼性の高い方法で提供できます。 Contoso は、リージョンごとに 1 つの Azure ExpressRoute 回線とインターネットにフェールオーバーする可能性を評価した後、この構成を選択しました。
Contoso がリージョンごとに複数の Azure ExpressRoute 回線を持つことができなかった場合、北米で発生したトラフィックをアジア太平洋の Azure ExpressRoute 回線にルーティングすると、許容できないレベルの待機時間が追加され、必要な DNS フォワーダー構成が複雑になります。
インターネットをバックアップ構成として使用することはお勧めしません。 これにより、Contoso の信頼性の原則が破られ、接続を使用して一貫性のないエクスペリエンスが得られます。 さらに、構成済みの BGP アドバタイズメント、NAT 構成、DNS 構成、プロキシ構成を考慮して、手動構成をフェールオーバーする必要があります。 これにより、フェールオーバーの複雑さが増し、復旧にかかる時間が長くなり、関連する手順を診断してトラブルシューティングする能力が低下します。
トラフィック管理または Azure ExpressRoute の計画と実装方法についてまだ質問がありますか? ネットワークとパフォーマンスに関するその他のガイダンスまたは Azure ExpressRoute に関する FAQ をお読みください。
Microsoft 365 シナリオの Azure ExpressRoute にセキュリティ制御を適用する
Azure ExpressRoute 接続のセキュリティ保護は、インターネット接続のセキュリティ保護と同じ原則から始まります。 多くのお客様は、オンプレミス ネットワークを Microsoft 365 やその他の Microsoft クラウドに接続する ExpressRoute パスに沿ってネットワークと境界コントロールを展開することを選択します。 これらの制御には、ファイアウォール、アプリケーション プロキシ、データ漏洩防止、侵入検出、侵入防止システムなどが含まれます。 多くの場合、お客様は、オンプレミスから Microsoft に送信されるトラフィックに対してさまざまなレベルの制御を適用します。また、Microsoft から開始されたトラフィックは、顧客のオンプレミス ネットワークに送信されるトラフィックと、オンプレミスから開始されたトラフィックが一般的なインターネット宛先に送信されるトラフィックに対して適用されます。
デプロイを選択した ExpressRoute 接続モデル とセキュリティを統合する例をいくつか次に示します。
| ExpressRoute 統合オプション | ネットワーク セキュリティ境界モデル |
|---|---|
| クラウド交換で併置 |
ExpressRoute 接続が確立されているコロケーション機能に、新規または既存のセキュリティ/境界インフラストラクチャをインストールします。 単にルーティング/相互接続の目的でコロケーション機能を使用し、コロケーション機能からオンプレミスのセキュリティ/境界インフラストラクチャへのバックホール接続を行います。 |
| ポイントツーポイント イーサネット |
既存のオンプレミスのセキュリティ/境界インフラストラクチャの場所でポイントツーポイント ExpressRoute 接続を終了します。 ExpressRoute パスに固有の新しいセキュリティ/境界インフラストラクチャをインストールし、そこでポイント対ポイント接続を終了します。 |
| Any-to-Any IPVPN |
Microsoft 365 接続の ExpressRoute に使用される IPVPN に送信するすべての場所で、既存のオンプレミスのセキュリティ/境界インフラストラクチャを使用します。 セキュリティ/境界として指定された特定のオンプレミスの場所に、Microsoft 365 の ExpressRoute に使用される IPVPN をヘアピンします。 |
一部のサービス プロバイダーでは、Azure ExpressRoute との統合ソリューションの一部として、マネージド セキュリティ/境界機能も提供されています。
Microsoft 365 接続の ExpressRoute に使用されるネットワーク/セキュリティ境界オプションのトポロジ配置を検討する場合は、次の点に関する追加の考慮事項を示します。
深度と種類のネットワーク/セキュリティ制御は、Microsoft 365 ユーザー エクスペリエンスのパフォーマンスとスケーラビリティに影響する可能性があります。
送信 (オンプレミス->Microsoft) と受信 (Microsoft->オンプレミス) (有効な場合) フローには異なる要件がある場合があります。 これらは、一般的なインターネット宛先への送信とは異なる可能性があります。
ポート/プロトコルと必要な IP サブネットに関する Microsoft 365 の要件は、トラフィックが ExpressRoute for Microsoft 365 またはインターネットを介してルーティングされるかどうかにかかわらず同じです。
お客様のネットワーク/セキュリティ 制御のトポロジ的配置は、ユーザーと Microsoft 365 サービス間の最終的なエンドツーエンド ネットワークを決定し、ネットワークの待機時間と輻輳に大きな影響を与える可能性があります。
お客様は、冗長性、高可用性、ディザスター リカバリーのベスト プラクティスに従って、ExpressRoute for Microsoft 365 で使用するセキュリティ/境界トポロジを設計することをお勧めします。
さまざまな Azure ExpressRoute 接続オプションと上記の境界セキュリティ モデルを比較する Contoso の例を次に示します。
例: Azure ExpressRoute のセキュリティ保護
Contoso は Azure ExpressRoute の実装を検討しており、ExpressRoute for Microsoft 365 の最適なアーキテクチャを計画した後、上記のガイダンスを使用して帯域幅の要件を理解した後、境界をセキュリティで保護するための最適な方法を決定しています。
Contoso の場合、複数の大陸に場所を持つ複数国のorganizationでは、セキュリティはすべての境界にまたがる必要があります。 Contoso の最適な接続オプションは、世界中の複数のピアリング場所とのマルチポイント接続であり、各大陸の従業員のニーズに対応します。 各大陸には、大陸内に冗長な Azure ExpressRoute 回線が含まれており、セキュリティはこれらのすべてにまたがっている必要があります。
Contoso の既存のインフラストラクチャは信頼性が高く、余分な作業を処理できるため、Contoso は Azure ExpressRoute とインターネット境界のセキュリティにインフラストラクチャを使用できます。 そうではない場合、Contoso は、既存の機器を補完したり、別の種類の接続を処理したりするために、より多くの機器を購入することを選択できます。
Azure ExpressRoute の帯域幅計画
各 Microsoft 365 のお客様は、各場所のユーザーの数、各 Microsoft 365 アプリケーションでのアクティブな状況、オンプレミスまたはハイブリッド機器の使用やネットワーク セキュリティ構成などのその他の要因に応じて、固有の帯域幅ニーズを持っています。
帯域幅が少なすぎると、輻輳、データの再送信、予期しない遅延が発生します。 帯域幅が多すぎると、不要なコストが発生します。 既存のネットワークでは、帯域幅は多くの場合、回線で使用可能なヘッドルームの量をパーセンテージで表します。 ヘッドルームが 10% の場合、混雑が発生する可能性があり、80% のヘッドルームを持つことは、一般的に不要なコストを意味します。 一般的なヘッドルーム ターゲットの割り当ては、20% から 50% です。
適切なレベルの帯域幅を見つけるには、既存のネットワーク使用量をテストするのが最適なメカニズムです。 これは、すべてのネットワーク構成とアプリケーションがいくつかの点で一意であるため、使用状況とニーズの真の尺度を取得する唯一の方法です。 測定するときは、帯域幅の合計消費量、待機時間、TCP 輻輳に細心の注意を払って、ネットワークのニーズを理解する必要があります。
すべてのネットワーク アプリケーションを含む推定ベースラインを作成したら、organizationのユーザーのさまざまなプロファイルを構成する小さなグループで Microsoft 365 をパイロットし、2 つの測定値を使用して各オフィスの場所に必要な帯域幅の量を見積もります。 テストで待機時間や TCP 輻輳の問題が見つかった場合は、Microsoft 365 を使用しているユーザーにエグレスを近づけるか、SSL 復号化や検査などの集中的なネットワーク スキャンを削除する必要がある場合があります。
推奨されるネットワーク処理の種類に関するすべての推奨事項は、ExpressRoute 回線とインターネット回線の両方に適用されます。 パフォーマンス チューニング サイトの残りのガイダンスについても同じことが当てはまります。
デプロイとテストの手順を構築する
実装計画には、テスト計画とロールバック計画の両方を含める必要があります。 実装が期待どおりに機能していない場合は、問題が検出される前に最小限の人数に影響するように計画を設計する必要があります。 次に、プランで考慮する必要があるいくつかの大まかな原則を示します。
中断を最小限に抑えるために、ネットワーク セグメントとユーザー サービスのオンボードをステージングします。
別のインターネット接続ホストから traceroute と TCP 接続を使用してルートをテストする計画を立てます。
望ましくは、受信サービスと送信サービスのテストは、テスト Microsoft 365 テナントを使用して分離されたテスト ネットワークで行う必要があります。
または、お客様がまだ Microsoft 365 を使用していない場合、またはパイロット中の場合は、運用ネットワークでテストを実行できます。
または、テストと監視専用に設定されている運用停止中にテストを実行することもできます。
または、各レイヤ 3 ルータ ノード上の各サービスのルートを確認することで、テストを行うことができます。 このフォールバックは、物理的なテストの欠如によってリスクが発生するため、他のテストが不可能な場合にのみ使用する必要があります。
デプロイ手順を構築する
デプロイ手順は、大規模なユーザー グループにデプロイする前にテストできるように、段階的に少数のユーザー グループにロールアウトする必要があります。 ExpressRoute のデプロイをステージングする方法を次に示します。
Microsoft ピアリングを使用して ExpressRoute を設定し、ステージングされたテスト目的でのみ、ルートアドバタイズを 1 つのホストに転送します。
最初は ExpressRoute ネットワークへのルートを 1 つのネットワーク セグメントにアドバタイズし、ネットワーク セグメントまたはリージョン別にルート アドバタイズを拡張します。
Microsoft 365 を初めて展開する場合は、少数のユーザーのパイロットとして ExpressRoute ネットワーク展開を使用します。
プロキシ サーバーを使用する場合は、テスト用 PAC ファイルを構成して、追加する前にテストとフィードバックを使用して、少数のユーザーを ExpressRoute に誘導することもできます。
実装計画には、実行する必要がある各デプロイ手順、またはネットワーク構成のデプロイに使用する必要があるコマンドを一覧表示する必要があります。 ネットワークの停止時間が到着すると、行われるすべての変更は、事前に記述され、ピア レビューされた書き込みデプロイ 計画から行う必要があります。 ExpressRoute の技術的な構成に関するガイダンスを参照してください。
メールを送信し続けるオンプレミス サーバーの IP アドレスを変更した場合は、SPF TXT レコードを更新します。
新しい NAT 構成に対応するように IP アドレスを変更した場合は、オンプレミス サーバーの DNS エントリを更新します。
ルーティングまたはプロキシ構成を維持するために、Microsoft 365 エンドポイント通知の RSS フィードをサブスクライブしていることを確認します。
ExpressRoute のデプロイが完了したら、テスト 計画のプロシージャを実行する必要があります。 各プロシージャの結果をログに記録する必要があります。 テスト 計画の結果が実装に成功しなかった場合は、元の運用環境にロールバックするための手順を含める必要があります。
テスト 手順を構築する
テスト手順には、ExpressRoute を使用する Microsoft 365 の送信ネットワーク サービスと受信ネットワーク サービスごとにテストを含める必要があります。 手順には、企業 LAN のオンプレミスではないユーザーを含む、一意の各ネットワークの場所からのテストを含める必要があります。
テスト アクティビティの例を次に示します。
オンプレミスのルーターからネットワーク オペレーター ルーターに ping を実行します。
500 以上の Microsoft 365 および CRM Online IP アドレスアドバタイズがオンプレミス ルーターによって受信されていることを検証します。
ExpressRoute と内部ネットワークの間で受信 NAT と送信 NAT が動作中であることを確認します。
NAT へのルートがルーターからアドバタイズされていることを検証します。
ExpressRoute がアドバタイズされたプレフィックスを受け入れたことを検証します。
- ピアリングアドバタイズを確認するには、次のコマンドレットを使用します。
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering前の例のように、より広い範囲の特定のサブセットでない限り、パブリック NAT IP 範囲が他の ExpressRoute またはパブリック インターネット ネットワーク回線を介して Microsoft にアドバタイズされていないことを検証します。
ExpressRoute 回線がペアになっている場合は、両方の BGP セッションが実行されていることを検証します。
NAT の内部に 1 つのホストを設定し、ping、tracert、tcpping を使用して、新しい回線間のホスト outlook.office365.com への接続をテストします。 または、MSEE へのミラー化されたポートでWiresharkや Microsoft Network Monitor 3.4 などのツールを使用して、outlook.office365.com に関連付けられている IP アドレスに接続できることを検証することもできます。
Exchange Onlineのアプリケーション レベル機能をテストします。
テスト Outlook は、Exchange Onlineに接続し、電子メールを送受信できます。
Outlook のテストでは、オンライン モードを使用できます。
スマートフォンの接続と送受信機能をテストします。
- SharePoint のアプリケーション レベル機能をテストする
同期クライアントOneDrive for Businessテストします。
SharePoint Web アクセスをテストします。
- Skype for Business呼び出しシナリオのアプリケーション レベル機能をテストします。
認証済みユーザーとして電話会議に参加する [エンド ユーザーによって開始された招待]。
電話会議へのユーザーの招待 [MCU から送信された招待]。
Skype for Business Web アプリケーションを使用して匿名ユーザーとして会議に参加します。
有線 PC 接続、IP 電話、モバイル デバイスからの通話に参加します。
フェデレーション ユーザーへの呼び出し o PSTN 検証への呼び出し: 通話が完了し、通話品質が許容され、接続時間が許容されます。
テナントのメンバーとフェデレーション ユーザーの両方について、連絡先のプレゼンス状態が更新されていることを確認します。
一般的な問題
非対称ルーティングは、最も一般的な実装の問題です。 検索する一般的なソースを次に示します。
ソース NAT を設定せずに、オープンまたはフラットなネットワーク ルーティング トポロジを使用する。
SNAT を使用してインターネット接続と ExpressRoute 接続の両方を介して受信サービスにルーティングしない。
広範に展開する前に、テスト ネットワーク上の ExpressRoute で受信サービスをテストしない。
ネットワーク経由での ExpressRoute 接続のデプロイ
デプロイを一度に 1 つのネットワーク セグメントにステージングし、新しいネットワーク セグメントごとにロールバックする計画を持つネットワークのさまざまな部分への接続を段階的にロールアウトします。 デプロイが Microsoft 365 展開と一致している場合は、最初に Microsoft 365 パイロット ユーザーに展開し、そこから拡張します。
最初にテストを行い、次に運用環境に対して次の手順を実行します。
展開手順を実行して ExpressRoute を有効にします。
ネットワーク ルートが想定どおりに表示されていることをテストします。
各受信および送信サービスでテストを実行します。
問題が検出された場合はロールバックします。
テスト ネットワーク セグメントを使用して ExpressRoute へのテスト接続を設定する
これで、完成した計画が紙に書かれたので、小規模でテストします。 このテストでは、オンプレミス ネットワーク上のテスト サブネットへの Microsoft ピアリングとの 1 つの ExpressRoute 接続を確立します。 テスト サブネットとの間の接続を使用して 試用版 Microsoft 365 テナント を構成し、運用環境で使用するすべての送信および受信サービスをテスト サブネットに含めることができます。 テスト ネットワーク セグメントの DNS を設定し、すべての受信サービスと送信サービスを確立します。 テスト 計画を実行し、各サービスのルーティングとルート伝達について理解していることを確認します。
デプロイとテストの計画を実行する
上記の項目を完了すると、完了した領域をオフにチェックし、デプロイとテスト計画を実行する前に、自分とチームが確認したことを確認します。
ネットワークの変更に関連する送信サービスと受信サービスの一覧。
インターネット エグレスと ExpressRoute の両方のミートミーの場所を示すグローバル ネットワーク アーキテクチャ図。
デプロイされるサービスごとに使用される異なるネットワーク パスを示すネットワーク ルーティング図。
必要に応じて変更とロールバックを実装する手順を含むデプロイ 計画。
各 Microsoft 365 およびネットワーク サービスをテストするためのテスト 計画。
受信および送信サービスの生産ルートのペーパー検証を完了しました。
可用性テストを含むテスト ネットワーク セグメント全体で完了したテスト。
デプロイ 計画全体とテスト 計画を実行するのに十分な期間の停止期間を選択し、トラブルシューティングに使用できる時間と、必要に応じてロールバックする時間を確保します。
注意
インターネットと ExpressRoute の両方でのルーティングが複雑であるため、複雑なルーティングのトラブルシューティングを処理するために、このウィンドウにバッファー時間を追加することをお勧めします。
Skype for Business Online の QoS を構成する
Skype for Business Online の音声と会議の利点を得るために QoS が必要です。 ExpressRoute ネットワーク接続で他の Microsoft 365 サービス アクセスがブロックされないようにした後で QoS を構成できます。 QoS の構成については、Skype for Business Online の「ExpressRoute と QoS」の記事を参照してください。
実装のトラブルシューティング
最初に、この実装ガイドの手順を確認します。実装計画に見逃された点はありますか? 戻るし、可能であればさらに小さなネットワーク テストを実行して、エラーをレプリケートしてそこでデバッグします。
テスト中に失敗した受信サービスまたは送信サービスを特定します。 失敗した各サービスの IP アドレスとサブネットを具体的に取得します。 先に進み、ネットワーク トポロジ図を紙に書き、ルーティングを検証します。 ExpressRoute ルーティングがアドバタイズされる場所を具体的に検証します。可能な場合はトレースで停止中にそのルーティングをテストします。
各顧客エンドポイントへのネットワーク トレースを使用して PSPing を実行し、ソースと宛先の IP アドレスを評価して、それらが期待どおりに動作することを検証します。 ポート 25 で公開するすべてのメール ホストに telnet を実行し、SNAT が元のソース IP アドレスを隠していることを確認します (これが予想される場合)。
ExpressRoute 接続を使用して Microsoft 365 を展開するときは、ExpressRoute のネットワーク構成が最適に設計されていることと、クライアント コンピューターなどのネットワーク上の他のコンポーネントも最適化されていることを確認する必要があることに注意してください。 この計画ガイドを使用して、見逃した可能性のある手順のトラブルシューティングに加えて、 Microsoft 365 のパフォーマンストラブルシューティング計画 も作成しました。
ここに戻る場合は、次の短いリンクをご利用ください: https://aka.ms/implementexpressroute365
関連項目
Azure ExpressRoute for Microsoft 365
Skype for Business Online でのメディア品質とネットワーク接続のパフォーマンス
Skype for Business Online 向けのネットワークの最適化
Skype for Business Online での ExpressRoute および QoS
ベースラインとパフォーマンス履歴を使用した Microsoft 365 パフォーマンス チューニング
Microsoft 365 のパフォーマンストラブルシューティング計画