Microsoft (有志)Publicationへの投稿
🌮

Azure → 各 Microsoft サービスの通信がインターネットに出ないことを Datadog Network Path で検証

Masato Ueda
に公開
Azure
Network
Datadog
networking
Microsoft
tech

はじめに

Datadog Network Path を利用し、AWS リソース間通信を可視化したこちらの記事が素晴らしく、 Azure からの通信も可視化して確認をしてみました。

https://zenn.dev/datadog/articles/f7ac35d6cac1bd

なお Azure でも同様に、 Public IP を使った通信だとしても MS バックボーン通信となることは以下ドキュメントにて明言されています。
また、より幅広く、Microsoft サービス同士の通信がインターネットを経由しないことも明言されています。

Microsoft グローバル ネットワーク

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

バックボーン については、以下の記事で図解していますので、あわせてご覧ください。
https://zenn.dev/microsoft/articles/azurebackbone#広義のバックボーン

検証内容

Azure VM を東日本リージョンに 1 台用意し、そこからいくつかの宛先へ通信を確認します。

試してみる宛先はこんな感じです。

  • ① Microsoft 外にあるサービス( zenn.dev ) に対しての通信
  • ② VM の パブリックIPアドレス に対しての通信
  • ③ PaaS サービス ( Azure App Service ) の FQDN に対しての通信
  • ④ Entra ID ( login.microsoft.com ) に対しての通信
  • ⑤ Microsoft 365 ( outlook.cloud.microsoft ) に対しての通信
  • ⑥ Defender ポータル ( security.microsoft.com ) に対しての通信

検証準備

datadog のアカウント作成から始め、Azure VMに Datadog Agent をインストールします。アカウント作成後、無償枠が 14 日間利用可能であり、network path 機能含め、その無償枠で試させて頂いています。

1. Datadog アカウントの作成

https://www.datadoghq.com/ja/ から作成するか、ログインします。

2. Azure VMに Datadog Agent をインストール

エージェントインストール先の環境（Linuxであるか等)を選ぶと、キャプチャのようにインストールするコマンド ③ 付の画面ができます。キーも入力されているので、コピーして実行するだけです。

DD_API_KEY=*** 自分のキーを指定 *** \
DD_SITE="ap1.datadoghq.com" \
DD_REMOTE_UPDATES=true \
DD_ENV=dev \
bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

エージェントインストール後、1-3 分程で、エージェントからのデータが Datadog 側に届き、エージェントインストール成功が表示されます。

3. Datadog の Network Path 機能を設定

Azure VM 側で、Datadog Agent の設定ファイルを編集し、前提となる traceroute 機能 や Network Path 機能を有効化します。

Datadog のドキュメントはこちら Network Path - Setup

/etc/datadog-agent/system-probe.yaml
traceroute:
  enabled: true
/etc/datadog-agent/conf.d/network_path.d/conf.yaml
init_config:
  min_collection_interval: 60 # in seconds, default 60 seconds
instances:

  - hostname: <VM の パブリックIPアドレス>
    protocol: TCP
    port: 80
    min_collection_interval: 120
    tcp_method: prefer_sack

  - hostname: <PaaS サービス の FQDN>
    protocol: TCP
    port: 443
    min_collection_interval: 120
    tcp_method: prefer_sack

  - hostname: login.microsoft.com
    protocol: TCP
    port: 443
    min_collection_interval: 120
    tcp_method: prefer_sack
    
  - hostname: outlook.cloud.microsoft
    protocol: TCP
    port: 443
    min_collection_interval: 120
    tcp_method: prefer_sack

  - hostname: security.microsoft.com
    protocol: TCP
    port: 443
    min_collection_interval: 120
    tcp_method: prefer_sack

  - hostname: zenn.dev
    protocol: TCP
    port: 443
    min_collection_interval: 120
    tcp_method: prefer_sack

設定変更後、Datadog Agent を再起動します。

Datadog Agent 再起動
sudo systemctl restart datadog-agent

4. Azure の NSG を調整

Azure VM で ICMP(ping や traceroute) を外部に対して行うには、VM に直接 Public IP を付与する必要があり、また、 NSG で受信許可設定をする必要があります。
今回 tcp_method も指定しているため、以下のように ICMP と TCP の受信許可ルールを追加します。

5. Datadog の Network Path ダッシュボードを確認

Infrastructure > Network Path から、Network Path のダッシュボードを開きます。

検証結果

① Microsoft 外にあるサービス( zenn.dev ) に対しての通信

まずは Microsoft の外にある zenn.dev に対しての通信です。

Microsoft グローバル ネットワーク経由のルーティング(cold potato routing)

既定では、極力 Microsoft のバックボーンを経由してルーティングされてから、インターネットへ出ていく設定となっています。→ ルーティング設定とは
イメージとしては、東日本にある VM から イギリス の webサイト を訪れる場合、まずは Microsoft のバックボーンを通ってイギリスあたりまで移動し、そこから最後のラストワンマイルだけインターネット利用して Webサイトへ到達するような感じです。いきなり東日本から通信をインターネットに出し、インターネットを使ってロンドンまで行くのではなく、Microsoft のバックボーンをできるだけ長く利用するイメージです。

Network Path の結果でも、Microsoft のバックボーンをある程度進んだ後、 Cloudflare (Zenn の CDN) のネットワークに入っていることがわかります。

パブリック インターネット経由のルーティング (hot potato routing)

さて、Public IP アドレスの設定を変更したパターンです。
外部の ISP である PCCW Global (AS3491) を経由し、Cloudflare に到達しています。途中経由する ISP は、タイミングにより変化します（例えば NTT(AS2914) など）。

② VM の パブリックIPアドレス に対しての通信

Azure VM の Public IP アドレスに対しての通信です。
先ほどのように、外部の ISP を経由している形跡はありません。
バックボーンの内部では基本的に traceroute の結果が返ってこないため、Unknown hops ばかり経由となっています。

③ PaaS サービス ( Azure App Service ) の FQDN に対しての通信

Azure App Service の FQDN に対しての通信です。
こちらも VM と同様、外部 ISP を通った形跡はなく、Microsoft バックボーン内で完結しています。

④ Entra ID ( login.microsoft.com ) に対しての通信

Entra ID ( login.microsoft.com ) に対しての通信です。
こちらも Microsoft バックボーン内で完結しています。

⑤ Microsoft 365 ( outlook.cloud.microsoft ) に対しての通信

こちらも Microsoft バックボーン内で完結しています。

なお、②～⑤まで、Microsoftのバックボーンである AS8075 (MICROSOFT-CORP-MSN-AS-BLOCK) 内で、完結していることがわかります。

⑥ Defender ポータル ( security.microsoft.com ) に対しての通信

さて、最後に Defender ポータル ( security.microsoft.com ) に対しての通信です。



これまでとは違い、AS8075 からでて、 AS8068 (MICROSOFT-CORP-MSN-AS-BLOCK) に移動していることがわかります。しかし、この場合でも外部の ISP を経由している形跡はなく、Microsoft のネットワーク内で完結していることが確認できました。

まとめ

Datadog Network Path 機能を利用して、Azure VM からの通信経路を確認しました。
ドキュメント通りではありますが、改めて、Microsoft サービス同士の通信はインターネットを経由せず、 Microsoft バックボーン内で完結していることがわかりました。

宛先 経路
Microsoft 外にあるサービス 外部インターネットを経由 (ただし、既定では 極力 MS バックボーンに留まる経路で配送され、ラストワンマイルがインターネット経由)
VM の パブリックIPアドレス MS バックボーン内で完結
PaaS ( Azure App Service ) MS バックボーン内で完結
Entra ID ( login.microsoft.com ) MS バックボーン内で完結
Microsoft 365 ( outlook.cloud.microsoft ) MS バックボーン内で完結
Defender ポータル ( security.microsoft.com ) MS バックボーン内で完結

Datadog はエージェントインストールが非常に容易であり、また Network Path 機能も簡単に利用を開始できました。
今回利用した通信経路の可視化以外にも、さまざまな監視機能があり、非常に便利であるとも感じました。

経由する経路や AS を確認するだけであれば、 MTR (My Traceroute) などのツールでも確認自体は可能ですが、Datadog の場合には様々な監視ポイントを含めて、継続的に監視でき、視覚的にわかりやすい Dashboard から確認できる点も良いかと思います。

参考 : teams, sharepoint や xbox など

基本的に AS8075 内で完結していました。
ただし、 CDN で提供されているサービスの場合には、Akamai に移動しているケースもあります。

  • teams.microsoft.com

  • outlook.office365.com

  • sharepoint.com

  • www.microsoft.com (AS8075 -> AS16625(Akamai))

  • www.xbox.com (AS8075 -> AS20940(Akamai) -> AS16625(Akamai))

参考URL

Microsoft (有志)
Microsoft (有志)Publication

Microsoft Azureをはじめとする最新技術情報をお届けします。 ※このPublicationは日本マイクロソフトまたは米Microsoft所属社員による個人の見解であり、所属する組織の公式見解ではありません。 ※Publicationに参加希望の社員は @07JP27までご連絡ください。

Discussion