🍳

ExpressRoute (Microsoft Peering) を使った経路最適化の勘所

2024/06/15に公開

Azure

network

tech

引用元: ExpressRoute を使用したオンプレミスネットワーク - Azure Architecture Center | Microsoft Learn

クラウドサービスの普及に伴い、企業のネットワークはますます複雑化しています。その中で、Azure ExpressRoute は、企業のオンプレミス拠点やデータセンターと Azure を高速かつ安全に接続するための強力なツールとなっています。このサービスを利用することで、プライベートネットワークとパブリックネットワークの両方で高い信頼性とパフォーマンスを確保することが可能です。

ExpressRoute の主要な機能の一つに、Private Peering と Microsoft Peering の 2 つのピアリングオプションがあります。それぞれ、プライベート IP アドレス範囲での Azure VNet との接続、パブリック IP アドレス範囲での Microsoft データセンターとの接続を実現します。

本稿では、特に Microsoft Peering に焦点を当て、その中でもサービスや製品の通信を最適化・閉域化する際のポイントについて詳しく解説していきます。ExpressRoute の基礎知識や Microsoft Peering 構築方法については多くのリソースが存在しますので、それらについて知りたい方は次のような参考資料をご覧ください。

制御のキホン

Microsoft Peering での通信制御の基本単位は、BGP コミュニティ です。

BGP コミュニティは、BGP で交換される経路に付与される属性値で、同じルーティングポリシーを適用したい経路を束ねて管理するために使用されます。例えば、Exhcange Online で利用される経路は、12076:5010 の値を持つ BGP コミュニティで定義されており、具体的には以下の経路が含まれます。

BGP コミュニティの定義例: Exchange (12076:5010)

{
  "ServiceSupportedRegion": "Global",
  "CommunityName": "Exchange",
  "CommunityValue": "12076:5010",
  "CommunityPrefixes": [
    "13.107.6.152/31",
    "13.107.18.10/31",
    "13.107.128.0/22",
    "23.103.160.0/20",
    "40.92.0.0/15",
    "40.96.0.0/13",
    "40.104.0.0/15",
    "40.107.0.0/16",
    "52.96.0.0/14",
    "52.100.0.0/14",
    "52.238.78.88/32",
    "104.47.0.0/17",
    "131.253.33.215/32",
    "132.245.0.0/16",
    "150.171.32.0/22",
    "204.79.197.215/32",
    "13.107.128.0/24",
    "13.107.129.0/24",
    "150.171.32.0/24",
    "150.171.34.0/24",
    "150.171.35.0/24",
    "52.96.38.0/24"
  ],
  "IsAuthorizedToUse": false,
  "ServiceGroup": "O365"
},

Microsoft 側からあるコミュニティの経路を広報するには、本来であればルーター (MSEE に切られた VRF) で route-map 等のコマンドをごにょごにょして設定しなければならないのですが、Azure では「ルートフィルター」というリソースに抽象化されています。ルートフィルターで広報したい BGP コミュニティを選択して、ExpressRoute 回線にアタッチすると、広報が始まります。

また、BGP コミュニティにはトラフィックエンジニアリングを容易にする特徴がいくつかありますが、その一つに「同じアドレス範囲の経路に複数の BGP コミュニティを付与できる」点があります。そのため、BGP コミュニティのアドレス範囲は重複することがあります。

重複する BGP コミュニティの確認方法

たとえば Azure PowerShell (Get-AzBgpServiceCommunity) を使えば、複数の BGP コミュニティに所属する経路を以下のように調べることが出来ます。

$prefixToCommunities = @{}

foreach ($elem in $(Get-AzBgpServiceCommunity).BgpCommunities) {
    foreach ($prefix in $elem.CommunityPrefixes) {
        if (-not $prefixToCommunities.ContainsKey($prefix)) {
            $prefixToCommunities[$prefix] = @()
        }
        $prefixToCommunities[$prefix] += $elem.CommunityValue
    }
}

foreach ($prefix in $prefixToCommunities.Keys) {
    if ($prefixToCommunities[$prefix].Count -gt 1) {
        Write-Output "${prefix}: $($prefixToCommunities[$prefix] -join ', ')"
    }
}

BGP コミュニティの種類

Microsoft Peering で使用される BGP コミュニティの一覧は、公式ドキュメント、Azure REST API、コマンドで確認できます。

コミュニティの詳しい説明等はこれらの一次情報を利用いただくとして、ここでは独断と偏見で BGP コミュニティをカテゴライズして表にまとめてみました。ざっくりどのようなコミュニティがあるのか把握するのにお役立てください。

カテゴリ	粒度	説明
Azure リージョン	Region	単一の Azure リージョン全体で利用されているパブリック IP アドレス範囲を表すコミュニティです。たとえば、東日本リージョンの任意の Azure リソースに割り当てられたパブリック IP アドレスは、`Azure Japan East` コミュニティに含まれます。
Azure リージョナルサービス	Region	ひとつのリージョンで完結する Azure サービスをサポートするコミュニティです。現在のところ、ストレージアカウント、SQL Database、Costmos DB、Azure Backup があります。たとえば、東日本リージョンのストレージアカウントに割り当てられるパブリック IP アドレスは、`Azure Storage Japan East` コミュニティに含まれます。
Azure グローバルサービス	Global	Azure グローバルサービスをサポートするコミュニティです。現在のところ、Microsoft Entra ID (`Azure Active Directory`^[1])、Azure の管理プレーン (`Azure Resource Manager`)、Azure DevOps (`Azure Global Services`)、Communication Services のメディアトラフィック (`Azure Communication Services`)^[2] があります。
Microsoft 365	Global	Microsoft 365 (旧称: Office 365) サービスをサポートするコミュニティです。`Other Office 365 Services`、`Exchange`、`Sharepoint Online`、`Skype for Business` の４種類に分かれています。いずれも、利用に特別な承認が必要である点が特異的です。
CRM	Global	Dynamics (v8.2 以前) で使用されていたパブリック IP アドレスが `CRM Online` コミュニティとしてまとめられています。
Defender for Endpoint	Global	Defender for Endpoint の通信をカバーするサービスタグ^[3] (`MicrosoftDefenderForEndpoint` ならびに `OneDSCollector`) に対応するコミュニティが存在します。
PSTN	Global	Teams の PSTN (公衆交換電話網) 回線で使用されているパブリック IP アドレスを束ねるコミュニティ `Azure SIP Trunking` が存在します^[4]。

最適化の原則

Microsoft Peering を使った経路の最適化（一部通信の閉域化）を効果的に実現するためには、いくつかの基本原則を理解しておくことが必要です。

原則 ①: 必要性を再確認する

まずは、Microsoft Peering が本当に必要なのか問うてみる所からです。

Microsoft のパブリックサービスの通信を最適化する方法としては、Azure Peering Service と呼ばれる接続サービスも活用できます。インターネットサービスプロバイダーや Internet Exchange を介した接続になるため、Azure Peering Services は閉域化の道具としては使えないものの、経路を最適化する目的なら十分役割を果たしてくれます。詳しい違いについては、技術サポートの公式ブログ記事が参考になります。

引用: Azure Peering Service と ExpressRoute の違いについて | Japan Azure IaaS Core Support Blog

また、対象の製品・サービスが Private Link を使ったプライベート接続に対応している場合は、Private Link を使うことがベストプラクティスとされています。パブリック IP アドレス領域の通信ではなくなることや、NSG や Azure Firewall といった、プライベートネットワーク向けに展開される各種ネットワーク・セキュリティ機能を活用できるためです。以下のドキュメントで、対応しているサービスの一覧を確認してみてください。

最後に、意外な事実かもしれませんが、Azure 仮想ネットワーク (Azure VM) から Microsoft のパブリックサービスに対しての通信は、Microsoft のバックボーンネットワークで完結します^[5]。したがって、オンプレミス拠点からの通信でも、(Private Peering を通って) Azure VM で一旦終端できるようにすればインターネット回線を使わずに通信が可能です。例えば、オンプレミス拠点ホストのプロキシ設定で Azure VM を指定したり、Entra Connect (Azure AD Connect) を Azure VM で構築することで、これが実現できます。

Microsoft Azure 内のデータセンター間、または Virtual Machines、Microsoft 365、Xbox、SQL DB、Storage、仮想ネットワークなどの Microsoft サービス間のあらゆるトラフィックはこのグローバルトラフィック内でルーティングされ、決してパブリックインターネットを経由しません。

引用元: マイクロソフトのグローバルネットワーク - Azure | Microsoft Learn

原則 ②: 技術サポートに問い合わせる

技術サポートが受けられる環境であれば、閉域化の対応状況や手順を調べる最善手はサポートリクエストの起票です。後述する調査フローのように自力でも対応状況は調べられるものの、結局のところ、製品・サービスの通信要件やら動作やらは開発元に聞くのが一番手っ取り早くて信頼できます。

Microsoft 製品であれば、ExpressRoute (Microsoft Peering) の対応状況を直接聞くこともできますし、サードパーティ製品であっても、通信要件を確認する目的で有効活用できます。

原則 ③: FQDN よりも IP アドレス

製品・サービスの通信要件を IP アドレス（範囲）で洗い出すことが重要です。なぜなら、BGP コミュニティを使って経路を管理・広報する以上、最終的にはコミュニティの定義を使って包摂関係を検証する必要があるためです。

反対に、FQDN で表現された要件は閉域化対応の検証ができない恐れがあります。FQDN から IP アドレスへの変換サービスのようなものは準備されていないものと考えてください (dig や nslookup 等の名前解決で得られる IP アドレスは、ある環境・ある時点での一瞬のスナップショットにすぎない点に注意してください)。

例外として、FQDN ごとに対応状況が明示されているサービスも存在します。Microsoft 365 がその代表例で、FQDN ごとに「その FQDN を利用するすべての通信が ER 回線を通るか」という情報が公開されています。

原則 ④: 閉域化に期待しすぎない

もちろんサービスの仕様や利用シナリオに大きく依存しますが、インターネット回線を全く利用しない閉域化を期待していると痛い目を見ることがあります。あくまで、Microsoft Peering は一部経路を最適化するツールだと捉えておくとよいです。

たとえば、Microsoft 365 の多くのエンドポイントは ER に対応していません^[6]。インターネット経由でも安全に利用できるため、最適化が必要なエンドポイントだけが ER に対応している形となっています。

また、Microsoft 365 に限らず、外部の証明書失効リストや CDN を参照するような製品であれば、原理的に ExpressRoute を通すことはできません。これは、Microsoft が所有していないパブリック IP アドレス範囲を、Microsoft のネットワーク (AS) から広報できないためです。Azure Portal が ExpressRoute で完結しない理由がまさにこれです^[7]。

原則 ⑤: プレフィックスレベルでの制御は難しい

なるべくBGP コミュニティより細かい粒度での経路制御を避けることを心がけましょう。

広報される経路のうち、一部の経路だけを受け取ったり明示的にブロックしたいことがあります。しかし、サービス側が必ずしもプレフィックスレベルで通信要件を管理しているとは限らず、どの経路ならブロックしてよいか判断できないケースもあります。また、経路は定期的にアップデートされるので、追従するための運用負荷も加わります。特別な理由がない限り、オンプレミス/プロバイダー側でフィルタリングは実施しないことをお勧めします。

なお、経路数のハードウェア/ソフトウェアリミットなどで、どうしても部分的な経路制御をしなければならないケースもあります。その場合、Service Health から通知される経路情報のアップデートをウォッチし、必要があれば都度 config を見直す運用を検討してください。

閉域化対応の確認フロー

ある製品・サービスが、Microsoft Peering による閉域化に対応しているかを確認しつつ、対応する場合に選択すべき BGP コミュニティの選定を進めるプロセスは、次のように進めます。

確認フロー：サポートで解決しなければ、一つ一つ通信要件を虱潰し的に検証していく

なお、ここでは「想定されるシナリオのすべての通信を閉域化する」ことを目的としているため、一つでも閉域化できない通信要件が見つかった時点で調査を中断しています。実際には、一部の通信を最適化できれば良いというユースケースもあると思うので、その場合は柔軟に対応してください。

以下では、いくつかの判断と処理について補足します。

判断: サポートリクエストで解決する？

原則で伝えた通り、まずは技術サポートに確認をするのが最善の初手です。おそらく殆どのケースで Microsoft (Azure) の技術サポートに対する問い合わせになるでしょう。Microsoft への問い合わせでは、次の３点に留意します。

閉域化対応を確認したい製品・サービスを対象にサポートリクエストを起票する
「Microsoft Peering での閉域化の可否」と「選択すべき BGP コミュニティ」を併せて質問する
想定しているシナリオを明確化する

意外かもしれませんが、リクエスト起票時の対象リソースとして ExpressRoute は適切ではありません。ExpressRoute は接続サービスに過ぎず、それを利用する（かもしれない）個別製品の要件を開発部門が把握してないためです。間違っていてもよしなにトリアージしてくれますが、余計なコミュニケーションコストや時間を費やさない為にも初めから製品・サービス観点で起票しましょう。

リクエスト内容の観点だと、Microsoft Peering での閉域化対応状況を聞きつつ、選択すべき BGP コミュニティの情報も質問するようにしてください。また、利用シナリオごとに通信要件が変化する可能性もあるため、どのシナリオの通信を閉域化したいか明言しておくことも重要です。

処理: 通信要件を洗い出す

このステップでは、製品・サービスの通信要件を整理します。なるべく FQDN (URL) ではなく、IP アドレスを用いた表現になるよう心がけます。主に３つの方法を活用します。

ドキュメントを確認する
サポートに問い合わせる
実機で検証する

なお、実機での検証は、特定環境での通信をリストアップするにすぎず、すべてのシナリオを網羅できている保証はない点に留意します。

実機で検証するには？

実機検証の具体的な方法論は、それだけで記事が書けそうな大きなトピックです。自分はあまりいいアイディアを持ち合わせていませんが、WEB 通信なら Fiddler のようなプロキシを使うのが手っ取り早いでしょう。

任意のプロトコルに対応したければ少しトリッキーになります。Linux だと、検証対象のプロセスに別途 network namespace を割り当てて tcpdump で監視したり、BPF や strace のようなトレーシングツールで network 周りの syscall を捕捉する方法が取れると思います。Windows だと、netsh のトレーシング機能、Microsoft Network Monitor^[8]、Process Monitor 等で頑張ればなんとかなる気がします（すみません）。

判断: IP アドレスが BGP コミュニティに含まれる？

この判断には、以下の API やコマンドで取得した BGP コミュニティのリストを利用します。

たとえば、Azure PowerShell (Get-AzBgpServiceCommunity) を使う場合は、以下のようにして判定することができます。

# $cidr1 <= $cidr2 の包含関係にあるかを判断する
function IsCidrContained {
    param(
        [string]$cidr1,
        [string]$cidr2
    )

    $ip1, $mask1 = $cidr1 -split '/'
    $ip2, $mask2 = $cidr2 -split '/'

    $mask1 = [math]::Pow(2, 32) - [math]::Pow(2, 32 - $mask1)
    $mask2 = [math]::Pow(2, 32) - [math]::Pow(2, 32 - $mask2)

    $ip1 = [convert]::ToUInt32($ip1.Split('.')[0]) -shl 24 -bor [convert]::ToUInt32($ip1.Split('.')[1]) -shl 16 -bor [convert]::ToUInt32($ip1.Split('.')[2]) -shl 8 -bor [convert]::ToUInt32($ip1.Split('.')[3])
    $ip2 = [convert]::ToUInt32($ip2.Split('.')[0]) -shl 24 -bor [convert]::ToUInt32($ip2.Split('.')[1]) -shl 16 -bor [convert]::ToUInt32($ip2.Split('.')[2]) -shl 8 -bor [convert]::ToUInt32($ip2.Split('.')[3])

    return ($ip1 -band $mask2) -eq ($ip2 -band $mask2)
}

$target = "20.191.166.131/32"
$communities = (Get-AzBgpServiceCommunity).BgpCommunities
foreach ($c in $communities) {
    foreach ($prefix in $c.CommunityPrefixes) {
        if ($prefix.Contains(":")) {
            break
        }
        if (IsCidrContained -cidr1 $target -cidr2 $prefix) {
            Write-Output "${prefix} - $($c.CommunityName) ($($c.CommunityValue))"
        }
    }
}

# 20.191.160.0/19 - Azure Japan East (12076:51012)
# 20.191.166.128/26 - Azure Backup Japan East (12076:55012)

判断: FQDN が BGP コミュニティに含まれる？

ある FQDN が特定の BGP コミュニティに包含されていることがあります。代表的なものは Microsoft 365 系統の通信です。下記のドキュメント^[9]で、ER 列が「はい」のエンドポイントは閉域化に対応しているので、もし検証している FQDN がこの中に含まれていれば BGP コミュニティに包含されることを意味します。

ただし、Microsoft 365 関連の BGP コミュニティを広報するには、Microsoft からの承認が必要です。法的要件や企業の規模などに基づいて審査が行われますので、利用できないリスクがあることを理解しましょう。

この接続モデルを使用するには Microsoft の承認が必要です。お客様のすべての要求を確認し、必要なまれなシナリオでのみ、Microsoft 365 の ExpressRoute を承認します。

引用元: Azure ExpressRoute for Microsoft 365 - Microsoft 365 Enterprise | Microsoft Learn

まとめ

ExpressRoute は、オンプレミスのネットワークを Microsoft のバックボーンネットワークに直接接続することで、高速かつ信頼性の高い接続を実現するサービスです。特に Microsoft Peering を利用することで、Microsoft のさまざまなパブリックサービスへのアクセスを安定化させ、堅牢にすることができます。本稿では、サービス・製品の通信を閉域化する際の重要なポイントに焦点を当てました。

ExpressRoute の経路制御の基本単位である BGP コミュニティを活用し、ルートフィルターを設定することで、必要なサービスの通信を管理できます。ただし、閉域化の対応状況を確認するためには、技術サポートへの問い合わせや、通信要件の IP アドレスベースでの確認が不可欠です。また、完全な閉域化が難しい場合もあるため、現実的な期待値の設定と早期確認が重要です。

本記事が、Azure ExpressRoute の導入や運用を検討している皆様にとって、有益な情報となれば幸いです。今後も最新の情報やベストプラクティスを共有していきたいと思います。

脚注

Azure Active Directory (AAD) は現在 Microsoft Entra ID にブランド名称が変更されていますが、コミュニティ名は互換性のため旧称のままです。 ↩︎
Azure Communication Services 用に組織のネットワークを準備する - An Azure Communication Services concept document | Microsoft Learn ↩︎
Microsoft Defender for Endpointの合理化された接続を使用したデバイスのオンボード - Microsoft Defender for Endpoint | Microsoft Learn ↩︎
Microsoft PSTN サービスに ExpressRoute を使用する | Microsoft Learn ↩︎
ISP に出ていかない事が保証される理由は、バックボーンにホットポテトルーティングを採用しているためです: Azure でのルーティング優先設定 - Azure Virtual Network | Microsoft Learn ↩︎
Microsoft 365 の URL と IP アドレスの範囲 - Microsoft 365 Enterprise | Microsoft Learn ↩︎
Azure Portal や Office 365 への通信は、ExpressRoute のみでは完結しません – Made in container ↩︎
リタイア済みです。後続の Microsoft Message Analyzer もリタイア済みです。 ↩︎
Microsoft 365 のエンドポイント情報は API でも取得できます: Microsoft 365 IP アドレスと URL Web サービス - Microsoft 365 Enterprise | Microsoft Learn ↩︎