8
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Azure VNet フローログ

Last updated at Posted at 2024-05-09

2024/06/28 ER Gateway のフローログの有無の詳細を追記

Virtual Netowrk フローログが 2024/04/25 に一般提供となりました。今までは NSG フローログが利用可能でしたが、この機能を利用することで NSG に限らないより広い範囲 (対応シナリオが多い) で通信ログを取得できるようになります。
Azure のネットワーク機能で取得可能な通信ログについては以前、こちらにまとめていますが、この記事では Virtual Network フローログの詳細や実際に検証した内容をまとめております。
VNet flow log にてログ出力されたかといった確認のみとなり、各プロダクトの正式なサポート状況は確認できておりません。

NSG フローログとの違い

こちらに違いがまとまっていますが、主な違いは以下があると思います。

  • Azure Virtual Network Manager セキュリティ規則に対応
  • 仮想ネットワーク暗号化にも対応
  • NSG フローログは NIC/サブネットの両方に NSG があった場合、どちらか一方の NSG しか記録されない
  • VNet フローログは取得範囲を VNet/Subnet/NIC から選択できる (※ NIC は VM のみのため、プライベートエンドポイント等は選べない)
  • 仮想ネットワーク内でサポートされているワークロードをサポート (ER 経由の通信や Hub 部分の通信の可視化が可能)

トラフィックの重複記録や追加コストを避けるために、同じ基になるワークロードで仮想ネットワーク フロー ログを有効にする前に、ネットワーク セキュリティ グループ フロー ログを無効にすることをお勧めします。

利用シナリオ

MS Tech Community ブログに詳細がまとまっていますが、以下のようなシナリオで利用できます。

  • Azure Virtual Network Manager セキュリティ規則のトラブルシューティング
  • Hub & Spoke 構成における Hub 部分のネットワークトラフィックの可視化
  • ER/VPN Gateway 経由のトラフィックの可視化 (5タプル、方向、通信量等を取得可能) ※ER の場合、Azure からオンプレへの Egress はログがでないようなので注意

ログ取得することでトラフィックの影響はないのか?

ログは、Azure プラットフォームを通して 1 分間隔で収集されます。 お使いの Azure リソースやネットワーク トラフィックに影響はありません。

VNet フローログ設定手順

事前に Log Aanalytics ワークスペース、ストレージアカウントを作成済みであれば、以下の手順で簡単に設定可能です。NIC 単位で取る場合は VM しか選択できません。

動作確認

以下のような構成にて疑似オンプレ (OCI) - Azure 間の通信、Spoke VNet 間の通信のログを取得し、Traffic 分析を使って各リソースでログが記録されるかを確認してみました。

image.png

Private Endpoint

Private Endpoint 宛の通信ですが、以下のように Hub VNet のフローログにて記録されており、データサイズ等も記録されておりました。
image.png

ただし、Spoke VNet の方のフローログとしては記録されておりませんでしたので、プライベートエンドポイント単体ではなく Express Route Gateway や Azure Firewall を経由したところでログが記録されるようです。

Private Endpoint 用サブネットの NSG で拒否された通信が記録されるか

NSG で拒否されている状態で OCI から BLOB Storage の Private Endpoint へ通信を試してみたところ、一応通信としては記録されておりましたが、Flow State は Allowed となっておりました。

image.png

Application Gateway

以下のような構成で Public IP のリスナーとプライベート IP のリスナーそれぞれにアクセスしてみます。
image.png

Private IP リスナー

Privete IP リスナー宛の通信も記録されておりました。また、Application Gateway 用のサブネット内の IP アドレス宛の通信が Spoke-B の方のフローログで記録されておりました。

image.png

Public IP リスナー

Public IP 宛の通信も Spoke-B の方のフローログで記録されておりました。DestIP は Application Gateway 用のサブネットの IP になっていますが、Azure の NSG は PublicIP ではなく VM の Private IP アドレスで評価するためそれと同様の動作と考えられます。

image.png

NSG で拒否した通信も記録されていたため、NSG で評価された結果は VNet フローログの FlowStatus に反映されるようです。

image.png

Bastion

Bastion から Windows VM に接続した際のログも記録されておりました。
Bastion インスタンスへの接続と、Bastion から Target VM へ双方のログが記録されていました。

image.png

DNS Private Resolver

DNS Private Resolver 宛の通信も Hub VNet のフローログに記録されていました。

image.png

ただし、Spoke VNet の方のフローログとしては記録されておりませんでしたので、DNS Private Resolver ではなく Express Route Gateway や Azure Firewall を経由したところでログが記録されるようです。

また、転送ルールを使った送信エンドポイントからの通信は検証しておりません。

オンプレ向け通信

image.png

OCI の VM に Azure VM から SSH した際のログですが、送信元の VM の IP とあて先 IP アドレスが記録されております。
image.png

ただし、OCI あての通信で ER Gateway の MacAddress と思われるログは記録されておりませんでした。

MAC アドレスの判別

こちらのログは Application Gateway に OCI からアクセスしたときのフローログですが、MacAddress が複数あり、どこを通過したときのログかはわかりにくい状態です。

image.png

通信経路としては以下であるため、ER Gateway か Azure Firewall の MacAddress の可能性が高そうです。
image.png

そこで Hub の VNet フローログに対して以下のようなクエリを使って GatewaySubnet 関連の通信で利用されている MacAddress を調べてみます。"10.10.4" は GatewaySubnet のものです。

NTANetAnalytics
| where SrcIp contains "10.10.4"
| project FlowStartTime, SrcIp, DestIp, DestPort, FlowDirection, FlowStatus, MacAddress, TargetResourceType, TargetResourceId
| summarize count() by MacAddress

ER Gateway のものと思われる MacAddress がでてきました。ログからの推測にはなりますが、何らかの内部的な通信のために ER Gateway の通信もログが出てると考えられます。
image.png

リソースによっては VMSS のようにスケールアウト・イン等があり、タイミングにより MacAddress が異なる可能性があるため、該当時間帯の情報を都度確認することをお勧めします。

この方法にて以下の感じで、 ExpressRoute, Azure Firewall を経由していると推測できます。
image.png

プライベートエンドポイントの通信で、ルーティングの設定が誤っていたために Azure Firewall を経由できてなかった時間帯があったのですが、その際は ER Gateway 用の MacAddress しか出力がありませんでした。
image.png

Express Route 経由のトラフィック可視化

Tech community のブログを参考に ER Gateway のトラフィックの割合を可視化してみました。
私の環境では SrcExpressRouteCircuit, DestExpressRouteCircuit が記録されていなかったため、以下の表示に絞っています。

  • ER Gateway の MacAddress の MacAddress が含まれる
  • SrcIp が GatewaySubnet、空ではないもの
  • DestIp にあて先 VNet のアドレス空間 ("10.12.") を含むもの
  • DestIp を基準にパイチャートを作成する
NTANetAnalytics
| where SubType == 'FlowLog'
    and FaSchemaVersion == '3'
    and FlowStartTime  > ago(2d)
| where SrcIp !contains "10.10.4" and isnotempty(SrcIp) and DestIp contains "10.12."
| where MacAddress == "00-22-48-E6-54-32" or MacAddress == "60-45-BD-66-1C-8F"
| summarize TotalBytesSrcToDest=sum(BytesSrcToDest), TotalBytesDestToSrc=sum(BytesDestToSrc) by tostring(DestIp)
| render piechart

こんな感じで Azure の Spoke VNet への通信でどこ宛の通信がどの程度多いのかがわかります。
image.png

Azure Firewall 経由のトラフィック可視化

Azure Firewall のトラフィックも可視化してみます。以下の表示に絞っています。Azure Firewall ではアプリケーションルール、ネットワークルール両方使っています。

  • Azure Firewall の MacAddress が含まれる
  • SrcIp が AzureFirewallSubnet、空ではないもの
  • DestIp にあて先 VNet のアドレス空間 ("10.12.") を含むもの
  • SrcIp を基準にパイチャートを作成する
NTANetAnalytics
| where SubType == 'FlowLog'
    and FaSchemaVersion == '3'
    and FlowStartTime  > ago(3d)
| where SrcIp !contains "10.10.1" and isnotempty(SrcIp) and DestIp contains "10.12."
| where MacAddress == "00-22-48-EA-53-4B" or MacAddress == "00-22-48-EA-5E-D7"
| summarize TotalBytesSrcToDest=sum(BytesSrcToDest), TotalBytesDestToSrc=sum(BytesDestToSrc) by tostring(SrcIp)
| render piechart

こんな感じで特定の Spoke VNet への通信でどこからの通信がどの程度多いのかがわかります。
image.png

サブネット委任、Global VNet Peering

こんな構成で VNet 統合した AppService から BLOB のプライベートエンドポイントへの接続が記録されるかを確認してみます。
image.png

以下のように Hub VNet のフローログに記録されておりました。
image.png

ただし、Spoke VNet の方のフローログとしては記録されておりませんでした。そのため Azure Firewall 等を経由させる必要がありそうです。

念のため、Global VNet Peering も使ってみましたが、ログは出力されました。

ログ量、課金について

ログ量は構成、要件により大幅に変動しますが、検証した構成で常時通信がない状態で 12MB/日 程度のログが記録されていました。

image.png

大規模環境やパブリックの Web サイトでログを取得する場合は、不測の事態でログおよび課金が増大する可能性もありますので、トラフィック分析を使う場合は通常の Usage をふまえたうえで Log Analytics に日次上限を設定しておくとよいかもしれません。

ExpressRoute Gateway 経由のトラフィックについて

以下のブログにもわかりやすく書かれていますが、Azure からオンプレ方向のパケットは ExpressRoute の Gateway 非経由となります。そのため、オンプレ方向の通信についてはフローログの記録がなかったと考えられます。

まとめ

まとめると以下のような検証結果となりました。

サービス 確認結果 備考
オンプレへの通信 Firewall 経由で取得
Private Endpoint Gateway や Firewall 経由で取得
Application Gateway
Bastion
DNS Private Resolver Gateway や Firewall 経由で取得
サブネット委任 Firewall 経由で取得
VNet ピアリング (Global 含む)

少量のトラフィックでもログの項目が多く、量も膨大であるため、詳細を細かく確認するのは非常に労力がいるなと感じましたが、トラブルシューティング時やトラフィックの内訳を大まかに確認したいときは有用なツールであると感じました。
すべてのシナリオを検証しているわけではないので、ご利用の環境で事前に検証いただくことをお勧めします。

8
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?