パケットの裏側を覗き見ろ！AWSトラフィックミラーリングとVXLANが生み出すリアルタイム観測の深層
「本番環境で、APIリクエストのペイロードがなぜか一部欠損している……？」
「セキュリティ監査から、特定のマイクロサービス間で行われる通信の生パケットをすべてキャプチャして証拠として残せと言われた……」
夜中にインフラ・SREチームのSlackがこんな悲鳴で埋め尽くされた経験はありませんか？ アプリケーション層のログ（CloudWatch LogsやDatadogなど）だけでは、ロードバランサーが書き換えたヘッダーの機微や、TLSハンドシェイクの裏側、あるいはコンテナネットワークの奥深くで起パケットロスまでは見えてきません。
そんなとき、クラウドネイティブなインフラエンジニアが最終兵器として取り出すのが「トラフィックミラーリング（Traffic Mirroring）」です。
今回は、AWS（Amazon VPC）を舞台に、ENI（Elastic Network Interface）を駆け巡るパケットの複製と、それを支えるVXLAN（Virtual Extensible LAN）のメカニズムを、実務的な設定手順やトラブルシューティングのノウハウを交えながら徹底解説します。
—
1. トラフィックミラーリングの正体と「VXLANカプセル化」の裏側
教科書的な定義を軽くおさらいすると、トラフィックミラーリングとは「指定したENI（ターゲット）を通過するインバウンドおよびアウトバウンドのパケットをリアルタイムに複製し、別のENIやセキュリティアプライアンス（コレクター）へと転送する機能」です。
しかし、シニアエンジニアとしてここで一歩踏み込んでおきたいのが、「どうやってAWSの巨大なSDN（Software Defined Networking）基盤の中で、パケットを別の宛先へ安全に届けているのか」という点です。
データのカプセル化：UDPポート4789の秘密
トラフィックミラーリングは、元となるパケット（L2〜L7）をそのままの状態で、VXLAN（RFC 7348）というオーバーレイネットワークプロトコルで包み込みます。
+-------------------------------------------------------+
| 外側IPヘッダー (送信元: ミラー元ENI / 宛先: 監視用ENI) |
+-------------------------------------------------------+
| 外側UDPヘッダー (宛先ポート: 4789) |
+-------------------------------------------------------+
| VXLANヘッダー (VNI: 24ビットの識別子) |
+-------------------------------------------------------+
| 元のパケット (元のIP、TCP/UDP、HTTPペイロードなど) |
+-------------------------------------------------------+この仕組みにより、以下のようなメリットと注意点が生じます。
- メリット: ミラー先の監視ツール（Wiresharkを仕掛けたEC2や、専用のIDS/IPSアプライアンス）側で、元パケットの送信元IPやMACアドレスをそのまま維持した状態で解析できる。
- 注意点（重要）: パケットがVXLANで包まれることで、データサイズ（パケット長）が通常より54バイト増加します。もし元のパケットがMTUの限界（通常は1500バイト）に近い場合、フラグメンテーションが発生するか、Jumbo Frames（9001バイト等）を有効にしていないと途中でパケットがドロップする原因になります。ここ、障害対応で本当によくハマるポイントです。
—
2. トラフィックミラーリング構築の3大要素
AWSでこれを実装するには、以下の3つのリソースを正しく連係させる必要があります。
1. Traffic Mirror Filter（フィルター）: どのパケットをミラーリングし、どれを無視（ドロップ）するかのルールを定義します。ポート番号やプロトコル、CIDRでフィルタリング可能です。
2. Traffic Mirror Target（ターゲット）: 複製されたパケットの「送り先」です。監視用EC2のENIか、NLB（Network Load Balancer）を指定します。
3. Traffic Mirror Session（セッション）: 「どのミラー元ENI」から、「どのフィルター」を通して、「どのターゲット」に送るかを結びつける管理単位です。セッションにはVNI（VXLAN Network Identifier）や、パケットをどれくらい切り詰めて送るか（Packet-Length）を設定できます。
—
3. 実践：AWS CLIによるトラフィックミラーリングの設定フロー
机上の空論はこれくらいにして、実際にAPIサーバーのENIからトラフィックをキャプチャし、隣のモニタリング用インスタンスへ流すための構築手順をAWS CLIで追ってみましょう。
Step 1: ミラーターゲット（宛先）の作成
まず、パケットを受け取る監視用インスタンスのENI ID（例: eni-0123456789abcdef0）を確認し、ターゲットを作成します。
# 監視用ENIをターゲットとして登録
aws ec2 create-traffic-mirror-target \
--network-interface-id eni-0123456789abcdef0 \
--description "Security Analysis Collector Target"（実行結果として Tmt-0123456789abcdef0 のようなターゲットIDが返ってきます）
Step 2: フィルター（条件）の作成
今回は、トラブルシューティングのためにWeb API（ポート 443）のトラフィックのみをインバウンド・アウトバウンド共にキャプチャするフィルターを作ります。
# フィルターの作成
aws ec2 create-traffic-mirror-filter \
--description "Capture HTTPS Traffic Only"（Tmf-0123456789abcdef0 が返されたと仮定します）
次に、このフィルターに対して「ルール」を追加します。HTTPS（443番ポート）のインバウンドを許可（ミラーリング対象）するルールを記述します。
# インバウンドルールの追加（ルール番号10、TCPポート443をキャプチャ）
aws ec2 create-traffic-mirror-filter-rule \
--traffic-mirror-filter-id Tmf-0123456789abcdef0 \
--traffic-direction inbound \
--rule-number 10 \
--rule-action accept \
--destination-port-range FromPort=443,ToPort=443 \
--protocol 6*(プロトコル 6 はTCPを意味します)*
Step 3: セッションの結びつけ
最後に、監視対象であるAPIサーバーのENI（例: eni-9876543210fedcba0）と、ターゲット、フィルターを「セッション」で結合します。ここで指定する session-number は、1つのENIに複数のセッションを設定する際の優先順位になります。
aws ec2 create-traffic-mirror-session \
--traffic-mirror-target-id Tmt-0123456789abcdef0 \
--traffic-mirror-filter-id Tmf-0123456789abcdef0 \
--network-interface-id eni-9876543210fedcba0 \
--session-number 1 \
--virtual-network-id 1001 \
--description "Production API Server Mirroring Session"これで設定は完了です。監視用インスタンス側で tcpdump や wireshark を起動すれば、VNI 1001 のVXLANパケットが流れ込んできているのが確認できます。
—
4. 現場で使える！デバッグとトラブルシューティングの極意
「設定したのに、監視側のサーバーにパケットが届かない……」
現場でよく遭遇するトラブルと、その泥臭い解決アプローチを共有します。
トラブル1: セキュリティグループ（SG）の落とし穴
VXLANはUDPの 4789 ポートを使用します。
監視用インスタンスのセキュリティグループは、ミラー元のインスタンスからの UDP 4789 のインバウンドを許可しているでしょうか？ ここを見落としていて、パケットが宛先の寸前でAWSのセキュリティグループにドロップされているケースが非常に多いです。
トラブル2: 非対称ルーティングとステートフルファイアウォール
もし監視用アプライアンスやIDSが、単にパケットを受け取るだけでなく何らかの応答を返そうとする場合、VPCのルートテーブルやセキュリティグループのステートフルな挙動（戻りパケットの経路）で迷子になりがちです。
基本原則として、トラフィックミラーリングのターゲット側ではパケットを「受信・解析するだけ（ステートレスな処理）」に徹し、双方向通信をさせない設計にするのが鉄則です。
トラブル3: パケットのドロップ（ENIのキャパシティ制限）
インスタンスタイプによって、トラフィックミラーリング処理をハンドリングできるスループットやセッション数には上限があります。大量のトラフィックを流す高負荷なAPIサーバーで全パケットをミラーリングすると、ENI自体の帯域が圧迫されたり、CPUが悲鳴を上げたりします。
フィルターでしっかりと「必要なトラフィック（特定のIPやポート）」だけに絞り込むチューニングが、SREとしての腕の見せ所です。
—
まとめ
トラフィックミラーリングは、クラウドのブラックボックスになりがちなネットワークの挙動を、まるで手元でパケットアナライザーを叩いているかのように可視化してくれる強力な武器です。
「ログには出ないが、現実はパケットが語る」——ネットワークの深淵を覗くこの技術をマスターすれば、どんな難解なインフラ・アプリ間の不具合も恐れるに足りません。ぜひ、検証環境でVXLANのカプセル化パケットを tcpdump で眺めるところから試してみてください。
コメント