Merge pull request #363 from ShuheiUda/master

Add expressroute-deep-dive

articles/archive/expressroute-deep-dive-part1.md

@@ -0,0 +1,114 @@
+---
+title: "詳説 Azure ExpressRoute – Part1: ExpressRoute を導入する前に"
+date: 2018-02-09 17:24:39
+tags:
+ - Archive
+ - Network
+ - ExpressRoute
+---
+> [!WARNING]
+> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。**
+
+こんにちは。Azure サポートの宇田です。
+今回から複数回にわたって、ExpressRoute について詳しく解説したいと思います。
+
+* Part1: ExpressRoute を導入する前に
+* [Part2: ExpressRoute のルーティング制御について](./archive/expressroute-deep-dive-part2.md)
+* [Part3: ExpressRoute の導入手順について](./archive/expressroute-deep-dive-part3.md)
+* [Part4: ExpressRoute の冗長構成について](./archive/expressroute-deep-dive-part4.md)
+* [Part5: ExpressRoute の増速やプロバイダー変更について](./archive/expressroute-deep-dive-part5.md)
+* [Part6: ExpressRoute の各種上限値について](./network/expressroute-deep-dive-part6.md)
+
+## ExpressRoute とは何か
+
+ExpressRoute は、オンプレミスと Azure を閉域網で接続するためのサービスです。
+
+Azure (Microsoft) とは別にプロバイダー様と別途契約いただき、既存の WAN などと接続して、オンプレミスから Azure の各種サービス (一部を除く) に対して、Internet 経由や VPN 経由での接続と比較して低遅延で信頼性の高い通信ができるようになります。
+
+* ExpressRoute の概要
+https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-introduction
+
+## 3 種類のピアリング形態
+
+ExpressRoute では、接続先に応じて 3 種類のピアリング形態が用意されています。
+
+(1 つの ExpressRoute 回線に対して、これら 3 つのピアリングを併用することが可能です)
+
+* Private Peering: 仮想ネットワークとの接続 (Azure 上の Private IP 帯との接続)
+* Public Peering: Azure のパブリック サービスとの接続 (Azure の Public IP 帯との接続)
+* Microsoft Peering: Office 365 サービスとの接続
+
+利用するサービスに応じて、必要になるピアリングを選択し、それぞれ構築いただく事となります。
+
+例えば、Azure VM とだけ通信ができればよいという事であれば Private Peering のみで疎通が可能です。他方で、Azure Storage や SQL Database などといった PaaS のサービス群にアクセスする場合は、Public Peering が必要になります。
+
+**2018/03/06 追記:**
+**ExpressRoute の中長期的な予定として、Public Peering は Microsoft Peering へ統合される方針となっております。詳細については以下のアナウンスをご確認ください。**
+
+* ExpressRoute の Public Peering と Microsoft Peering に関するアナウンス
+https://blogs.technet.microsoft.com/jpaztech/2018/03/02/expressroute-announcement-march-2018/
+
+## Premium Add-On
+
+ピアリングと併せて検討が必要な事項として、Premium Add-On があります。
+
+国内で ExpressRoute をご利用になる場合、東京 or 大阪の接続ポイントから Azure に接続することになるかと思います。この際、東京で接続しても、大阪で接続しても、Azure の東日本・西日本リージョンとの通信が可能になります。
+
+一方で、国内で接続した場合には、海外の Azure データセンターとは既定の状態では接続ができません。PaaS のサービスや Office 365 など、国内のデータセンターのみで完結せず海外との通信が必要になる場合や、DR 要件などで国外のリージョンをご利用になる場合には、別途 Premium Add-On が必要になります。
+
+## ExpressRoute の費用
+
+ExpressRoute を利用するにあたっては、様々な費用が発生しますので、事前に十分確認しましょう。
+
+* ExpressRoute の価格 (Azure 側の Edge Router の費用および、従量課金プランの場合は転送量に応じた課金)
+https://azure.microsoft.com/ja-jp/pricing/details/expressroute/
+
+* ExpressRoute ゲートウェイの価格 (各仮想ネットワークに必要な Gateway の費用)
+https://azure.microsoft.com/ja-jp/pricing/details/vpn-gateway/
+
+* ExpressRoute プロバイダーの費用 (Azure - プロバイダー間の費用)
+
+* アクセス回線の費用 (プロバイダー - オンプレミス間の費用)
+
+Microsoft が関与するのは前者二点のみとなりますので、後者の費用については各プロバイダー様までお問い合わせください。
+
+## プロバイダーの選択
+
+ExpressRoute を契約するにあたっては、Microsoft のほかに回線プロバイダーとの契約も必要です。
+
+多くのプロバイダーから ExpressRoute 関連サービスを提供いただいていますが、以下の二種類のプロバイダー様に大別され、提供されているサービスや責任範囲が異なりますので、事前に十分確認しましょう。
+
+* L2 プロバイダー: ルーターの管理はお客様側で実施 (BGP オペレーターが必要)
+* L3 プロバイダー: ルーターの管理を含めてプロバイダー様が提供
+
+なお、L3 のプロバイダーと比較して費用が安価であるという理由で L2 のプロバイダーを選択されて、構築時に大変苦労されており、それによってコストメリットを十分に享受できていないようなお客様も、少なからずいらっしゃいます。L2 のプロバイダー様を利用する場合には、お客様側でルーターのコンフィグや管理を行うことになりますので、決して費用のみで判断せず、運用コストも含めて検討いただければと思います。(特に、BGP オペレーターがいない場合は、L3 のプロバイダーを利用することを強く推奨します。)
+
+また、プロバイダーからオンプレミス側へのアクセス回線についても、専用線 / IP-VPN / 閉域 SIM など多様な形態が用意されています。こうした点についても、プロバイダー様へご相談ください。
+
+## ExpressRoute のよくある誤解
+
+### 全ての通信が ExpressRoute で完結する (?)
+
+結論からいうと、答えは No です。
+
+ExpressRoute をご利用いただくことで、多くの Azure サービスと閉域網で接続が可能ですが、一部の通信については、ExpressRoute だけでは完結しません。代表的な例をいくつかご紹介しましょう。
+
+* Azure ポータル
+ポータルは多種多様な接続先とバックグラウンドで通信を行っています。ExpressRoute を通るものもありますが、Azure 外の CDN を経由して配信されているもの等も存在しますので、ExpressRoute のみではアクセスできません。
+
+* Azure CDN / Traffic Manager
+FAQ にも記載の通り、これらのサービスは ExpressRoute 経由ではアクセスができません。また、利用されるサービスや API エンドポイントによっては、フロントエンドでこうした ExpressRoute 非対応のサービスを使用している場合があります。利用予定のサービスが ExpressRoute のみで通信できるのか、一部の通信は Internet へ出ることになるのかは事前にご確認ください。
+
+### Internet から完全に分離できる (?)
+
+先の内容とも重複しますが、Internet から完全に分離して疑似的にプライベート クラウドのように利用することは極めて困難です。IaaS の Azure VM のみを利用して、一切の拡張機能を使用しないなどであれば不可能ではありませんが、完全閉域にしようとすると利用できないサービスや機能制限が多々生じることになりますのでご注意ください。(例えば、Azure バックアップを利用しようとすると、Azure Storage の FQDN である xxx.blob.core.windows.net などに対して名前解決が必要となりますし、名前解決された IP アドレスは Azure データセンターの Public IP アドレスになります。)
+
+### オンプレミスから L2 で延伸できる (?)
+
+こちらも No です。ExpressRoute は、あくまでも L3 での接続となりますし、Azure の仮想ネットワークは VLAN には対応していません。
+
+### セキュリティが高い (?)
+
+ExpressRoute は閉域網で Azure と接続しますので、Internet 経由の通信と比較して盗聴リスクが低いことは間違いありません。また、Private Peering であれば、お客様にて作成した仮想ネットワークにのみ接続されるため、その他のお客様のネットワークとは分離されます。ただし、Public Peering や Microsoft Peering で接続されるネットワークは Azure や Office 365といったパブリック クラウドのネットワークになります。つまり、ExpressRoute 自体は Azure や Office 365 をご利用いただいているお客様が共通で利用しているネットワークとの接続のみを提供するサービスとなるため、その中のテナント（お客様が利用しているサーバー）との通信のみに制限すると行ったことはできません。
+
+このように、ExpressRoute を利用したからといって、セキュリティ面を一切考慮しなくてよくなる訳では無いため、Public Peering や Microsoft Peering を利用する場合は、これまでのオンプレミス環境と同様に、多層防御の原則にのっとって適切にセキュリティを考慮していただくことが極めて重要です。

articles/archive/expressroute-deep-dive-part2.md

@@ -0,0 +1,93 @@
+---
+title: "詳説 Azure ExpressRoute - Part2: ExpressRoute のルーティング制御について"
+date: 2018-02-09 17:30:18
+tags:
+ - Archive
+ - Network
+ - ExpressRoute
+---
+> [!WARNING]
+> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。**
+
+こんにちは。Azure サポートの宇田です。
+詳説 Azure ExpressRoute Part 2 では、ルーティング制御について詳しく取り上げます。
+
+* [Part1: ExpressRoute を導入する前に](./archive/expressroute-deep-dive-part1.md)
+* Part2: ExpressRoute のルーティング制御について
+* [Part3: ExpressRoute の導入手順について](./archive/expressroute-deep-dive-part3.md)
+* [Part4: ExpressRoute の冗長構成について](./archive/expressroute-deep-dive-part4.md)
+* [Part5: ExpressRoute の増速やプロバイダー変更について](./archive/expressroute-deep-dive-part5.md)
+* [Part6: ExpressRoute の各種上限値について](./network/expressroute-deep-dive-part6.md)
+
+## ExpressRoute のルーティング基礎
+
+Part.1 でも説明した通り、ExpressRoute では BGP (Border Gateway Protocol) を用いてプロバイダー様のエッジルーター (PE) と経路を交換します。(BGP という単語が聞きなれない方は、JPNIC さんが公開されている「[インターネット10分講座：BGP](https://www.nic.ad.jp/ja/newsletter/No35/0800.html)」ほかをご参照ください。)
+
+もう少し具体的に、3 種類のピアリングでどのような経路交換が行われるかを見てみましょう。
+
+### (Azure 側から広報される経路)
+
+* Private Peering: ExpressRoute に接続された仮想ネットワークのアドレス空間が広報されます
+* Public Peering: Azure の各データセンターが保有する Public IP アドレス空間が広報されます
+* Microsoft Peering: Office 365 で使用される Public IP アドレス空間が広報されます
+
+![](./expressroute-deep-dive-part2/ExpressRouteRoutingSummary1.png)
+
+### (オンプレミス / プロバイダー側から広報していただく経路)
+
+* Private Peering: ExpressRoute 経由で通信されたいオンプレミス側のアドレス空間を広報ください
+* Public Peering: オンプレミス側で NAT に使用される Public IP のアドレスを広報ください
+* Microsoft Peering: オンプレミス側で NAT に使用される Public IP のアドレスを広報ください
+
+![](./expressroute-deep-dive-part2/ExpressRouteRoutingSummary2.png)
+
+## Private Peering におけるルーティングに関する考慮事項
+
+この際、「Azure に対して、どのような経路を広報するか」および「Azure から受け取った経路をオンプレミスへどのように広報するか」について、事前に熟考が必要です。
+
+### Azure に対して、どのような経路を広報するか
+
+Azure とオンプレミスの端末間で通信を行うためには、オンプレミス側から正しく経路が広報されている必要があります。
+
+代表的な構成例としては、以下のようなパターンが多いかと思います。
+
+* オンプレミスで使用しているアドレス空間を細かく広報する (192.168.X.0/24, 192.168.Y.0/24, 192.168.Z.0/24 …)
+* オンプレミスで使用しているアドレス空間をサマライズして広報する (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 など)
+* デフォルト ルート (0.0.0.0/0) を広報する (強制トンネリングと呼ばれる構成)
+
+ここで最も注意をしなくてはいけないのは、三点目のデフォルト ルートを広報する場合です。
+
+通常、ExpressRoute に接続されていない仮想ネットワークでは、Azure から直接インターネットへ出れるようにルーティングされます。しかしながら ExpressRoute を構成して PE からデフォルト ルートを広報した場合には、全ての IP アドレス宛ての通信がオンプレミスへとルーティングされることになり、Azure からは直接インターネットへ出ることができません。このため、仮想ネットワーク上の Azure VM では、下図のようにオンプレミス側からインターネットへと抜ける経路をたどることになります。
+
+![](./expressroute-deep-dive-part2/ExpressRouteRoutingSummary3.png)
+
+したがって、当然ですがオンプレミス側からインターネットへと出られない構成においては、Azure VM もインターネットへ接続できなくなります。(セキュリティの観点から、あえてこうした構成とされるお客様もいらっしゃいます。)
+
+![](./expressroute-deep-dive-part2/ExpressRouteRoutingSummary4.png)
+
+また、強制トンネリングを構成された環境では、Windows のライセンス認証で用いられる KMS に影響が生じます。こちらについては以下にて詳しくご紹介しておりますので、併せてご参照ください。
+
+* ExpressRoute 環境でライセンス認証ができない事象について
+https://www.syuheiuda.com/?p=4867
+
+### Azure から受け取った経路をオンプレミスへどのように広報するか
+
+他方で、Azure 側から受け取った経路をどのようにオンプレミスへ広報するかも検討が必要です。
+
+Azure は ExpressRoute プロバイダー様のエッジ ルーターまで BGP で経路を広報するのみとなりますので、必要に応じて他の経路制御プロトコル (OSPF 等) にて再配布を行う必要があります。これらオンプレミス側のルーティングに関しては、Azure 側で制御できるものではありませんので、オンプレミスのネットワーク管理者様およびプロバイダー様と事前にご相談ください。
+
+![](./expressroute-deep-dive-part2/ExpressRouteRoutingSummary5.png)
+
+## Private / Public Peering の共存環境でのルーティングに関する考慮事項
+
+Private Peering と Public Peering を併用されている場合、プロバイダー様のルーター (PE) では Private Peering 経由で受け取った経路情報と、Public Peering 経由で受け取った経路情報を保持しています。この際、Public Peering 側から受け取った経路 (Azure の Public IP アドレス帯) を Private Peering へ再配布するようなクロスアドバタイズと呼ばれる構成を行いますと、IaaS -> PaaS の通信が下図のようにプロバイダー様で折り返すような経路をたどることになります。
+
+![](./expressroute-deep-dive-part2/ExpressRouteRoutingSummary6.png)
+
+こうしたルーティングでも通信自体は全く問題はありませんが、プロバイダー様で折り返して ExpressRoute を往復することになるため、帯域が逼迫する恐れがあることと、従量課金プランをご利用の場合には費用が増加することとなりますので十分ご留意ください。一例としては、Azure バックアップなどの拡張機能が行う通信において、Azure VM (Private IP) から Azure Storage (Public IP) へと通信が行われますので、バックアップの際に大量のトラフィックが生じた場合などで問題が顕在化しやすいかと存じます。
+
+ExpressRoute はあくまでも Azure とお客様のオンプレミス環境を接続するサービスという位置づけになりますので、プロバイダー様のルーターから Azure へと広報される経路は、あくまでもオンプレミス側で利用されているもののみとしていただくのがよろしいかと存じます。
+
+以上、詳説 Azure ExpressRoute Part 2 をお届けしました。
+
+今回取り上げた内容に関しては、事前の考慮不足で構築スケジュールに影響が生じたり、ExpressRoute の接続後のトラブルにつながる場合もありますので、設計段階から十分にご検討いただければ幸いです。