【入門編】トラフィックミラーリング(Traffic Mirroring)を用いたパケットキャプチャとENI分析 – クラウド＆コンテナネットワーク実践ガイド

「ネットワークの盗聴」は怖くない！トラフィックミラーリングでパケットを丸裸にする方法

こんにちは！SREとして日々クラウドの裏側と格闘している筆者です。

インフラエンジニアとして働いていると、たまにこんな壁にぶつかります。「なぜか特定の通信だけが途中で消えている気がする……」「セキュリティログには出てこない不審な動きを、生データで追いかけたい」。

そんなとき、最強の武器になるのが「トラフィックミラーリング」です。今日は、この少しだけ怪しい響きを持つ技術を、郵便配達に例えて優しく解説していきますね。

—

トラフィックミラーリングって、結局なに？

一言で言うと、「通信のコピーを、別の場所にこっそり届ける機能」です。

想像してみてください。あるマンション（AWSのEC2インスタンス）に届くすべての郵便物（パケット）を、本来の宛先に届けつつ、全く同じ内容のコピーをもう一通作って、監視員の詰め所（分析用サーバー）に転送する仕組みです。

これを使えば、アプリケーションを止めることなく、裏側で「どんな内容の手紙が来ているのか」をじっくり分析できるんです。

なぜわざわざ「コピー」するの？

普通、サーバー上の通信を覗き見しようとすると、tcpdump のようなコマンドを使ってサーバーの中で直接キャプチャしますよね。でも、これには問題があります。

負荷がかかる: キャプチャ処理でサーバーのCPUを食ってしまう。
改ざんのリスク: 調査のためにサーバーにログインすること自体が、ログを汚してしまう。

トラフィックミラーリングなら、ネットワークの入り口（ENI：Elastic Network Interface）でパケットを「物理的にコピー」して別の場所へ流すので、サーバー本体には一切負荷をかけずに済みます。これぞSREの知恵というわけです。

—

「VXLAN」って何者？：郵便物のカプセル化

ここで少しだけ技術的な話をしますね。ミラーリングされたパケットは、分析用サーバーに届く際、VXLAN（ブイエックスラン）という特殊な「封筒」に入れられます。

なぜわざわざ新しい封筒に入れるのでしょうか？
それは、元のパケットを「そのまま」届けるためです。

郵便物（元のパケット）には、宛先や差出人が書かれていますよね。もしそのまま転送したら、途中のルーターが「あれ？この手紙、宛先が全然違う場所（分析サーバー）を向いてるぞ？」と混乱して捨ててしまうかもしれません。

そこで、「これはコピーですよ。中身はそのままにしておいてね」と書かれた大きな外箱（VXLANヘッダー）に元のパケットをすっぽり詰め込むのです。こうすれば、中身がどんなに特殊な形式であっても、無事に分析サーバーまで届けることができます。

—

AWSでトラフィックミラーリングを仕掛ける手順

実際にAWSでこれを設定する際は、以下の3つのステップを踏みます。パズルを組み立てるような感覚で進めていきましょう！

1. ターゲットの作成（コピー先の指定）

まずは、パケットのコピーを受け取る「分析サーバー」の場所を指定します。

# 分析用サーバーのENIを指定してターゲットを作成
aws ec2 create-traffic-mirror-target \
    --network-interface-id eni-1234567890abcdef0 \
    --description "分析サーバー用の受け皿"

2. フィルタの作成（どの通信をコピーするか）

全部の通信をコピーすると、データ量が膨大になって大変なことになります。必要なものだけを選別しましょう。

# ポート80（HTTP）の通信だけを拾うフィルタを作成
aws ec2 create-traffic-mirror-filter \
    --description "HTTP通信だけを覗く"

# フィルタにルールを追加（インバウンドのみ）
aws ec2 create-traffic-mirror-filter-rule \
    --traffic-mirror-filter-id tmf-0a1b2c3d4e5f6g7h8 \
    --traffic-direction inbound \
    --rule-number 100 \
    --rule-action accept \
    --destination-cidr-block 0.0.0.0/0 \
    --protocol 6 \
    --destination-port-range FromPort=80,ToPort=80

3. セッションの作成（開始！）

最後に、ターゲットとフィルタを組み合わせて「開始」の合図を出します。

# 監視対象のENIから、ターゲットへ流し込む！
aws ec2 create-traffic-mirror-session \
    --traffic-mirror-target-id tmt-111222333444555 \
    --traffic-mirror-filter-id tmf-0a1b2c3d4e5f6g7h8 \
    --network-interface-id eni-99988877766655544 \
    --session-number 1

—

現場で役立つアドバイス：使いすぎには注意！

最後に、SREとしての「現場の教訓」をお伝えします。

1. 帯域を食いつぶす: ミラーリングは通信量を倍増させます。監視対象のトラフィックが激しい場合、ネットワーク帯域の上限に達して通信が遅延することがあります。
2. コストを意識する: データ転送量に応じて課金が発生するため、「とりあえず全部キャプチャ」は禁物です。フィルタリングでピンポイントに絞り込みましょう。
3. セキュリティ: コピーされたデータには、認証情報や個人情報が含まれている可能性があります。分析サーバー側のセキュリティ設定は、本番環境と同等かそれ以上に厳重に行ってくださいね。

トラフィックミラーリングは、ネットワークの「健康診断」をするための非常に強力なツールです。仕組みさえ理解してしまえば、ネットワークトラブルという「見えない敵」を可視化する心強い味方になってくれます。

ぜひ、皆さんの環境でもまずは検証用環境で試してみてください。パケットがVXLANの封筒の中を駆け巡る様子を想像すると、ネットワークの世界がもっと面白く見えてきますよ！

それでは、良いクラウドライフを！