【実務・中級編】 VPCトラフィックミラーリングによるENIパケット抽出とVXLANカプセル化 – クラウドインフラと仮想化ネットワーク実践ガイド

パケットの裏側を覗き見ろ！AWS VPCトラフィックミラーリングとVXLANカプセル化の深層

「本番環境で、時折発生する謎のパケットドロップの犯人を特定したい」
「セキュリティ監査のために、特定のマイクロサービス間で行き交うすべてのリクエストをリアルタイムでキャッチし、別系統の解析基盤へ流し込みたい」

クラウドインフラの現場で幾度となく直面するこうした難題に対し、あなたならどうアプローチするだろうか。各インスタンスに重たいエージェントをインストールしてCPUを枯渇させる？ それともロードバランサーのアクセスログだけで推測ゲームを続ける？

ここで紹介したいのが、AWSのネットワーク仮想化レイヤーの奥深くでシームレスに動作する「VPCトラフィックミラーリング（VPC Traffic Mirroring）」だ。

今回は、パケットがAWSの巨大な物理ネットワークをどのように駆け巡り、なぜVXLANという技術が必要になるのか、そのメカニズムと実務で即座に使える設定手法を、現場のシニアエンジニアの視点から徹底的に紐解いていこう。

—

1. トラフィックミラーリングの全体像と「VXLANカプセル化」の正体

そもそも、VPCトラフィックミラーリングとは何だろうか。一言で言えば、「特定のElastic Network Interface（ENI）を流れるインバウンド/アウトバウンドのパケットを丸ごとコピーし、別のターゲットへ安全に転送する機能」である。

しかし、ここで少し立ち止まって考えてみてほしい。
AWSのマルチテナントな仮想化基盤（Nitro Systemなど）の上で、あるインスタンスのパケットを、どうやって安全かつ確実に別の解析用インスタンス（セキュリティアプライアンスやIDS/IPSなど）まで届け、「どのENIから来たものか」を判別しているのだろうか？

ここで主役となるのが、ネットワーク業界の標準規格である VXLAN（Virtual eXtensible LAN, RFC 7348） だ。

VXLANが選ばれる理由：レイヤー2のトンネリング

トラフィックミラーリングでは、キャプチャーした「オリジナルのパケット」の周りに、新たなUDPヘッダーとVXLANヘッダーを巻き付ける（これをカプセル化と呼ぶ）。

+-----------------------------------+
| 外側IPヘッダー (AWS内部ルーティング用)|
+-----------------------------------+
| UDPヘッダー (通常 Dest Port: 4789)  |
+-----------------------------------+
| VXLANヘッダー (VNI: 24bit)         |
+-----------------------------------+
| 内側イーサネットヘッダー            |
+-----------------------------------+
| 内側IPヘッダー (オリジナルの通信)   |
+-----------------------------------+
| TCP/UDP / ペイロード              |
+-----------------------------------+

1. VNI（VXLAN Network Identifier）の付与
VXLANヘッダー内には、24ビットの識別子であるVNIが含まれている。これにより、受け手側のターゲットインスタンスは、どのミラーリングセッション（どのENIのパケット）から送られてきたものかを完璧に識別できる。
2. UDPポート 4789 の利用
標準のVXLAN宛先ポートである 4789 を使用して、AWSの物理ネットワークからターゲットENIへとカプセル化されたパケットがUDPデータグラムとして流し込まれる。

つまり、ターゲットインスタンスで待ち受けるパケット解析ツール（tcpdump や Wireshark など）から見ると、見慣れないUDPパケットが飛んできているように見えるが、その中身をデコードすると、標的となったENIを通過した「生きたパケット」がそのままそっくり封入されているというわけだ。

—

2. 実務でハマる！トラフィックミラーリングの3大要素

AWSでトラフィックミラーリングを構成する際、概念として理解すべきコンポーネントは以下の3つに集約される。

  • トラフィックミラーソース（Source）：

監視対象となるENI。EC2インスタンスやNATゲートウェイ、ENIベースのAWSリソースを指定できる。

  • トラフィックミラーターゲット（Target）：

ミラーリングされたパケットの「送り先」。通常は解析用インスタンスのENIか、ネットワークロードバランサー（NLB）を指定する。

  • トラフィックミラーフィルター（Filter）：

「どのパケットをコピーし、どのパケットを無視するか」を定義するルール。ここでしっかりとプレフィックスやポート番号を絞り込まないと、ターゲット側のネットワーク帯域がすぐに飽和するので注意が必要だ。

—

3. 実践：AWS CLIによる構築手順と設定スクリプト

机上の空論はここまでにして、実際に手を動かしてトラフィックミラーリングの環境を構築してみよう。ここでは、管理用端末からAWS CLIを用いて一連のリソースをデプロイする手順を示す。

ステップ1：ターゲットの指定とセッションの作成

まずは、パケットの送り先となるターゲット（--network-interface-id に解析用インスタンスのENIを指定）を作成する。

# 1. トラフィックミラーターゲットの作成
aws ec2 create-traffic-mirror-target \
    --network-interface-id eni-0123456789abcdef0 \
    --description "Security Analysis Target ENI" \
    --tag-specifications 'ResourceType=traffic-mirror-target,Tags=[{Key=Name,Value=Prod-Analysis-Target}]'

上記のコマンドを実行すると、traffic-mirror-target-0abcdef123456789 のようなターゲットIDが返されるので控えておこう。

ステップ2：フィルターの作成（ノイズの排除）

次に、すべてのパケットをミラーリングするとコストや帯域が無駄になるため、「特定のWeb API（例: ポート443のトラフィック）のみをキャプチャーする」フィルターを作成する。

# 2. トラフィックミラーフィルターの作成
aws ec2 create-traffic-mirror-filter \
    --description "Filter for HTTPS API Traffic" \
    --tag-specifications 'ResourceType=traffic-mirror-filter,Tags=[{Key=Name,Value=API-HTTPS-Filter}]'

ターゲットIDと同様に traffic-mirror-filter-0123456789abcdef0 が得られたら、そこにインバウンド（受信）およびアウトバウンド（送信）のルールを紐付ける。

# 3. フィルタールールの追加（例: アウトバウンドのHTTPS通信をキャプチャー）
aws ec2 create-traffic-mirror-filter-rule \
    --traffic-mirror-filter-id traffic-mirror-filter-0123456789abcdef0 \
    --traffic-direction egress \
    --rule-number 100 \
    --rule-action accept \
    --destination-cidr-block 0.0.0.0/0 \
    --protocol 6 \
    --destination-port-range FromPort=443,ToPort=443

ステップ3：ミラーセッションの結合

最後に、ソース（監視対象）、ターゲット（送り先）、フィルター（条件）をひとつのセッションとして結びつける。ここでは、VNIを明示的に指定することも可能だ。

# 4. トラフィックミラーセッションの作成
aws ec2 create-traffic-mirror-session \
    --traffic-mirror-source-id eni-9876543210fedcba0 \
    --traffic-mirror-target-id traffic-mirror-target-0abcdef123456789 \
    --traffic-mirror-filter-id traffic-mirror-filter-0123456789abcdef0 \
    --packet-length 128 \
    --session-number 1 \
    --virtual-network-id 10001 \
    --description "Production API Traffic Mirroring Session"

> 💡 実務での重要Tips：--packet-length の罠
> --packet-length には、パケットの先頭から何バイトまでをキャプチャーして転送するかを指定する（最大はMTUサイズの 8800）。もし「ペイロードの中身まで完璧に解析したい」ということであれば、このパラメータを省略するか最大値に設定すべきだ。ただし、パケット長を大きくするとターゲット側のネットワーク負荷が跳ね上がるため、HTTPヘッダーやIPヘッダーのメタデータ確認だけで十分な場合は 128 や 256 に制限して帯域を節約するのがSREの定石だ。

—

4. ターゲットインスタンスでの受信確認とデバッグ

設定が無事に完了したら、次はパケットを受け取る側のターゲットインスタンスで、本当にVXLANパケットが届いているかを確認しよう。

Linux（UbuntuやAmazon Linux）の標準的なネットワークツールである tcpdump を用いて、ポート 4789 のトラフィックを監視する。

# VXLANの標準ポート(4789)を指定してパケットをキャプチャー
sudo tcpdump -nnvvXi eth0 udp port 4789

コンソールに以下のようなログが流れてくれば、トラフィックミラーリングは正常に機能している証拠だ。

12:34:56.789123 IP (tos 0x0, ttl 63, id 12345, offset 0, flags [DF], proto UDP (17), length 150)
    10.0.1.50.55555 > 10.0.2.100.4789: VXLAN, flags [I] (0x08), vni 10001
    192.168.10.15.54321 > 192.168.20.25.443: Flags [S], cksum 0x1234 (correct), seq 0:0, win 64240, options [mss 1460], length 0

この出力結果を読み解いてみよう。

  • 外側のパケットは 10.0.1.50 からターゲット 10.0.2.100 の 4789 ポートへ向かっている。
  • VXLANの vni 10001 が付与されている。
  • デコードされた内側のパケットを見ると、ソースENI上の元通信である 192.168.10.15 から 192.168.20.25:443 へのTCP SYNパケットが、見事にそのままカプセル化されて届いていることが一目でわかる。

—

5. 現場でありがちなトラブルシューティング

最後に、現場でこの構成を導入した際に陥りがちな「ハマりポイント」をいくつか共有しておこう。

1. セキュリティグループの落とし穴

  • ターゲットインスタンスのセキュリティグループで、インバウンドの UDP 4789番ポート が許可されていることを忘れてはならない。ここが塞がっていると、AWS基盤から送られてきたミラーパケットはすべてサイレントドロップされる。

2. ルーティングと非対称ルーティング

  • ターゲットインスタンスがプライベートサブネットにいる場合、インターネット経由のトラフィックをミラーリングしても、レスポンスパケットが変なルートを通っていないか（非対称ルーティングになっていないか）を確認する必要がある。基本的には「パケットを覗き見る専用の孤立したサブネット（あるいはアナリティクス基盤）」にターゲットを置くのが最も安全だ。

3. コスト面の爆発に注意

  • トラフィックミラーリングは非常に強力だが、「ミラーリングされたデータ量（GB単位）に応じた料金」と、「ENIあたりの時間料金」が発生する。高トラフィックなAPIサーバー全般に適用すると、翌月のAWS利用請求書を見て青ざめることになりかねない。フィルターを厳格にかけ、本当に必要な検証期間だけ有効化するのがプロの作法である。

—

まとめ

AWS VPCトラフィックミラーリングは、ネットワークの奥深くで行われている通信の挙動を、アプリケーションコードを一切変更することなく可視化してくれる強力な武器だ。

VXLANの仕組みとカプセル化の構造をしっかりと頭に叩き込んでおけば、単なる「AWSの便利機能」ではなく、「低レイヤーからネットワークの真実を暴く確かな技術」として使いこなせるようになるはずだ。

あなたのインフラストラクチャに潜む次のパフォーマンスボトルネックやセキュリティインシデントを暴くその日まで、ぜひこの知見を現場で役立ててほしい。

スポンサーリンク

コメント

タイトルとURLをコピーしました