Azure Virtual Network TAP を使ったトラフィックのミラーリング

Azure Virtual Network TAP (Terminal Access Point) がパブリックプレビューとなっております。この機能を利用することで Azure VM のトラフィックをミラーリングすることができます。トラフィックの分析では NVA を使ったパートナーソリューションが有用ですが、Windows/Linux の VM を NVA 代わりに利用してパケットキャプチャを取ることもできます。実際に Linux VM にてパケットを取得して動作を確認した際の手順や制限事項をまとめておりますので、ご利用の際はご一読いただけると幸いです。

https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-tap-overview

# Azure Virtual Network TAP とは？
Azure Virtual Network TAP は Azure 上の仮想マシンのネットワークトラフィックをミラーリングし、NVA に送信する機能です。NVA でパケットをキャプチャして、ネットワークトラフィックを分析することができます。

# 主な用途
- ネットワークトラフィックのセキュリティ監視
- トラブルシューティング
- パフォーマンス分析
- コンプライアンス要件

# 制限事項
- 送信元として指定できるのは VM の NIC のみ
- あて先として指定できるのは VM の NIC か Standard LB のみ (プライベートエンドポイントは不可)
- 暗号化されている仮想ネットワーク上の VM 場合は送信元として指定できない
- 送信元として指定していした VM の追加、削除時は最大 60 秒の切断あり (ミラーリングしてる他の VM は影響なし)
- サポートされるリージョンは現状、Asia East, US West Central のみ
- VNet ピアリングはサポートされるが同じリージョンのみ

## 試してみて気づいたこと
- 送信元として指定した VM では現状、UDR が使えない模様 (VNet TAP の対象から外すと UDR が使えるようになったため)
- Nat Gateway を使った通信では Egress パケットのみがミラーリングされる

# 構成図
以下のような構成で仮想ネットワーク内の Web サイトにアクセスした際のパケットを Linux VM 側で取得します。サブネットは分けていますが、同じサブネットでも問題ありません。
※アクセスには Bastion を使ってますが、図中では省略

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/06df9408-c58e-404b-b09c-b019d93c5190.png)


# 設定
こちらの記載に従って設定していきます。ドキュメント内のリンクからポータルを開かないと機能を利用できないため、ドキュメントの手順通りに実施することをお勧めします。

https://learn.microsoft.com/ja-jp/azure/virtual-network/tutorial-virtual-network-tap-portal

# 動作確認
NVA 用の VM (Ubuntu 24.04) にログインし、パケットキャプチャを仕掛けておきます。

```
tcpdump -s0 -i any -n -w outfile-nva.pcap
```

送信元として指定した VM にて curl コマンドで適当な Web サイトにアクセスします。

```
$ curl -v http://10.90.0.38
*   Trying 10.90.0.38:80...
* Connected to 10.90.0.38 (10.90.0.38) port 80
> GET / HTTP/1.1
> Host: 10.90.0.38
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Fri, 09 May 2025 07:06:56 GMT
< Server: Apache/2.4.58 (Ubuntu)
< Last-Modified: Fri, 09 May 2025 07:02:35 GMT
< ETag: "e-634ae8d10b9d1"
< Accept-Ranges: bytes
< Content-Length: 14
< Content-Type: text/html
< 
vm-taptest-02
```

取得したパケットキャプチャを確認してみます。

4789 は本来 VXLAN で利用されるポートとなりますが、NVA 用の VM で取得したパケットを見てみるとやはり VXLAN トラフィック (UDP 4789) として記録されていることがわかります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/69c21b82-2890-440b-adea-f7bd8d0ae011.png)

①、② と IP ヘッダ (送信元、宛先の IP アドレス情報) が２つあるのは VXLAN にてカプセル化されているためで、① がトラフィック転送 (ミラーリング) で使うための IP ヘッダで、② が送信元 VM が実際に通信を行った際の IP ヘッダです。

送信元の VM でもパケットキャプチャを取得し、比較してみましたが、NVA 用の VM で取得したパケットの方が情報量が多く、データサイズも大きくなっています。
これは VXLAN でカプセル化したトラフィックをミラーリングしているためだと考えられます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/8eea3a50-e85e-44e8-b726-04c095a27b82.png)
(左：送信元 VM、右：NVA 用の VM)


# 冗長化の方法
宛先には Internal Load Balancer を指定可能ですので下の様な構成にすれば NVA を冗長構成にすることができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/48da604a-bf4b-4324-a60d-9b81eeb2d505.png)

負荷分散規則は以下のような形で、UDP 4789 をそのままバックエンドに流すような構成にしています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/73fe8bf1-bacb-4bbf-8705-bc1b3d819d91.png)

ただし、この構成の場合はトラフィックがミラーリングされる先が ILB の負荷分散によってばらけますので、NVA 側に Act/Stb で稼働させる機能や、トラフィックデータをまとめる機能がない場合は運用対処が必要になる可能性があります。
実機で確認した感じだと TCP のコネクションが変わるタイミングで異なる VM にトラフィックが転送されていました。
パケットを見ても TCP のコネクション単位で UDP の送信元のポートが変わっていました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2266293/48e02625-21b8-41f6-bdf2-d6a4ab04be0e.png)


# まとめ
Virtual Network TAP を使うことで様々なケースにおいて VM のネットワークトラフィックを簡単に取得できるようになりそうです。
今回は単純な Linux VM にて動作を確認しましたが、様々な[パートナーソリューション](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-tap-overview#virtual-network-tap-partner-solutions)が提供されておりますので、単純なパケットキャプチャだけではなく、パフォーマンス分析やセキュリティ監視も可能になります。ネットワークのトラブルシューティングやトラフィック監視方法を検討する際は、Virtual Network TAP も試してみてください。