MS_AzureExpressRoute

Azure ExpressRoute

• 戻る（Azureの仮想ネットワーク）
  • VPN Gateway
  • Express Route
  • Azure Peering Service
  • 仮想ネットワーク ピアリング
  • Azure Private Link / Endpoint
  • OA-LANとAzureのVNETの分離

概要

• オンプレミスと VNET を専用線で接続する帯域保証型サービス
• 以下、Peering、Peering 言うが、Azureの仮想ネットワーク ピアリングではない。

補足（この注意書きが親切）: Azure で「ピアリング」という語は
少なくとも 3 つの別物を指すため、非常に紛らわしい。

用語	何と何を繋ぐか
ExpressRoute の Private Peering	オンプレ ⇔ Azure VNET（本ページ）
ExpressRoute の Microsoft Peering	オンプレ ⇔ Microsoft の SaaS（本ページ）
VNET ピアリング	Azure VNET ⇔ Azure VNET（Azureの仮想ネットワーク ピアリング）
（BGP の）ピアリング	ルータ同士の隣接関係（一般用語）

ExpressRoute の「Peering」は
**BGP のピアリング（経路情報の交換）**に由来する用語であり、
VNET ピアリングとは無関係である。

詳細

特徴

• 既設の DC が Express Route に対応していれば、追加費用は比較的少ない。
• 盗聴の可能性は低いので、暗号化はされない（VPN との併用は可能だが非推奨）。

補足（暗号化されない点は要確認事項）: 「専用線だから安全」という
前提に立った設計だが、要件によっては問題になる。

• 監査・規制要件で**「経路上の暗号化」が明示的に求められる**場合、
  ExpressRoute 単体では要件を満たせない。
• キャリアの設備内を通るため、
  物理的に「誰も触れない」わけではない。

対処としては、

手段	内容
アプリケーション層で暗号化	TLS（HTTPS、TDS over TLS 等）。最も現実的
ExpressRoute + VPN	IPsec を重ねる。本文が「非推奨」とするのは帯域が VPN GW の上限に制限されるため
MACsec（ExpressRoute Direct）	L2 で暗号化。ExpressRoute Direct 契約が必要

通常は TLS で十分であり、
それが本文の「暗号化のために専用線を使う必要はない」
（後掲の「要件の再確認」）という主張とも整合する。

接続方法

• パブリック・インターネットを経由しない。
• Express Route に対応した DC 経由で接続する。
  • Azure ⇔ DC までが Express Route で、
  • DC ⇔ オンプレまでが専用線接続サービス。

補足（この 2 区間の分離が費用と品質を決める）: ExpressRoute の
全体像を図にすると次のようになる。

オンプレ拠点 ══[① 専用線接続サービス]══ 接続 DC（ピアリング拠点）
                                           ║
                                      [② ExpressRoute 回線]
                                           ║
                                      Microsoft のエッジ ── Azure リージョン

区間	誰と契約するか	費用
① オンプレ ⇔ DC	キャリア／接続プロバイダ	ここが支配的
② DC ⇔ Microsoft	Microsoft（ExpressRoute 回線）	帯域とプラン次第

本文が「既設の DC が対応していれば追加費用は比較的少ない」と言うのは、
既にその DC に回線を引いているなら ① が不要だからである。
逆に、ゼロから引く場合は ① が期間・費用ともに支配的になる
（開通まで数か月かかることもある）。

なお、可用性の観点では
ExpressRoute 回線は既定で冗長化されている（2 本のペア）が、
① の区間は自分で冗長化しないと単一障害点になる。
ここも見落とされやすい。

2つのタイプ

Private Peering

VNET（プライベート IP）に対する接続（オンプレ延伸）。

Microsoft Peering

• 以下の SaaS のパブリック IP へ（、L4 NAT ルータのプライベート IP 経由で）、接続も可能。
  • Office 365
  • Azure Active Directory（＋条件付きアクセス）
  • , etc.（サポート状況、利用承認の要否は SaaS による）
• 構築時のポイント
  • L4 NAT ルータで、プライベート IP → パブリック IP へ変換する。
  • 接続先 SaaS はマルチテナントなので、
    L7 プロキシを使用して、自テナントへのアクセスのみに制限するなど。
• 参考
  • Microsoft Peering 導入時の注意事項 | Japan Azure IaaS Core Support Blog
    https://jpaztech.github.io/blog/network/considerations-of-microsoft-peering/

補足（2 つの Peering の決定的な違い）: 名前が似ているが、
扱う IP アドレスの種類が違うという点が本質である。

	Private Peering	Microsoft Peering
接続先	VNET（自分のリソース）	Microsoft の SaaS（共有リソース）
IP	プライベート IP	パブリック IP
NAT	不要	必要（L4 NAT ルータ）
経路広告	VNET のアドレス空間	Microsoft の全パブリック プレフィックス（膨大）
利用承認	不要	必要（SaaS による）
主な用途	Azure 上の自社システム	Microsoft 365

Microsoft Peering で NAT が必要なのは、
接続先がパブリック IP だからである。
オンプレのプライベート IP のままでは
パブリック IP のサービスに到達できない。

また、Microsoft が広告する経路が非常に多いため、
オンプレ側のルータの経路数上限に当たることがある。
ルート フィルターで必要なサービス（Office 365 の
特定コミュニティ等）に絞るのが定石である。

なお、Microsoft 365 について Microsoft は
**「ExpressRoute より通常のインターネット接続を推奨する」**という
立場を取っている（経路が最適化されるため）。
本文が代替として Azure Peering Service を
挙げているのはこの流れに沿っている。

代替サービス

VPN Gateway

• Private Peeringの代替サービス
• 専用線は慣例で、実は不要なケースが多い。
  • 盗聴対策としては暗号化で十分
  • 帯域も DC までの専用線接続サービス部分で問題が起きやすい。
  • 以下の検討を行う。
    • インターネットの主要幹線の近くで接続するようにする。
    • ローカル-WAN に、SD-WAN を活用するようにする。
  • → 要件の再確認

移行メモ（体裁）: 原典の「問題が起き安い」は
「問題が起きやすい」の誤変換であるため修正した。

Azure Peering Service

• Microsoft Peeringの代替サービス
• いくらか違いがあるので用途に合わせて使い分ける。

要件の再確認

インターネットを使わない

• 意味
  • パブリック IP を使わない。
  • 特定できない経路を通らない。
• 検討項目
  • パブリック IP を使わないと構成できないケースや、
    パブリック IP を使っても、セキュアに構成できるケース等がある。
  • 従って、重要なのは、
    危険性の高い不特定ネットワークを通る通信、
    特に下位 IX (Internet eXchange) を通るような通信
    を避けるように経路を構成すること。

専用線で接続する

• 意味
  • 機密性（安全性）を確保したい。
  • 通信の安定性を確保したい。
• 検討項目
  • 機密性（安全性）は暗号化通信により確保できるため、
    機密性確保のために専用線を使う必要はない。
  • 通信の安定性は、確かに専用線（ER）では確保し易いが、
    Azure Peering Serviceであっても回線契約を
    太くすれば十分な帯域と安定性が安価に確保できる。

閉域接続する

• 意味
  • 必要ないところに経路上出ていけないようにする。
  • 接続先を特定のサービスに限定する。
• 検討項目
  Microsoft Peeringの先で他のテナントにも接続できるため、
  プロキシによる FQDN 絞り込みや AzAD テナント制限が必要になる。

補足（この「要件の再確認」が本ページの白眉）: 3 つの要望を
「言葉」ではなく「意味」に分解して、
それぞれに適した手段を当てるという進め方は、
非機能要件を扱ううえで極めて有効である。

整理すると次のようになる。

言われる要望	本当に守りたいもの	適した手段
「インターネットを使わない」	不特定の経路を通らせない	経路の設計（ER / Peering Service）。パブリック IP の有無は本質ではない
「専用線で接続する」	機密性	暗号化（TLS / IPsec）。専用線は不要
同上	安定性	帯域の確保。ER でも Peering Service でも可
「閉域接続する」	接続先の限定	経路制御では不十分。プロキシの FQDN 制限、テナント制限が要る

特に重要なのは 3 つ目で、
「閉域にしたから安全」は成り立たないという指摘である。
Microsoft Peering の先はマルチテナントの SaaS であり、
経路を閉じても他社テナントには到達できてしまう
（Azure Peering Serviceの補足も参照）。

「専用線を引く」という要望の背後にあるのが
機密性なのか、安定性なのか、経路の特定なのかを切り分ければ、
もっと安く・速く満たせる手段が見つかることが多い。
ExpressRoute は開通に数か月・費用も大きいため、
この確認を最初に行う価値は非常に高い。

参考

• ちょっと違う専用線「ExpressRoute」とは？
  https://www.cloudou.net/expressroute/exr001/

---

Tags: 移行, インフラストラクチャ, クラウド, セキュリティ, 通信技術, Azure