AWS VPCトラフィックミラーリングの深層：VXLANカプセル化とパケット抽出のメカニズムを解剖する
クラウドネイティブなインフラストラクチャにおいて、ネットワークトラフィックの可視化とセキュリティ監査は、SREやセキュリティエンジニアリングチームにとって永遠の課題です。従来の物理ネットワークであれば、スイッチのSPANポート（Port Mirroring）やTAP（Test Access Point）を物理的に挟み込むことでパケットをキャプチャできましたが、仮想化されたパブリッククラウドの抽象化された世界では、そう単純にはいきません。
AWSのVPC環境において、この「仮想的なパケットの盗み見」を実現する強力なプリミティブが 「VPCトラフィックミラーリング（VPC Traffic Mirroring）」 です。今回は、Elastic Network Interface（ENI）レベルでのパケット抽出から、VXLANによるカプセル化、そしてターゲットインスタンスに至るまでのパケットの旅路を、Linuxカーネルとクラウドのハードウェアオフロードの境界線を見据えながら徹底的に解剖します。
—
1. パケットレベルの内部挙動：ENIタップとVXLANカプセル化の裏側
VPCトラフィックミラーリングの挙動を理解するためには、AWSの基盤レイヤー（Nitroシステム）がどのようにネットワークパケットを処理しているかを知る必要があります。
従来の仮想化レイヤーでは、ハイパーバイザー上のソフトウェアスイッチがパケットのコピーを行っていましたが、現代のAWSインフラを支える AWS Nitro System では、この処理は専用のハードウェア（Nitroカード）にオフロードされています。
パケット抽出からカプセル化までのライフサイクル
1. パケットのキャプチャ（Tapping）:
ミラーリング元（Source）として指定されたENIを通過するすべてのインバウンドおよびアウトバウンドパケット（フィルタリング設定に基づく）が、Nitroカード上のハードウェア回路レベルで非破壊的に複製されます。元のパケットのルーティングやレイテンシには影響を与えません。
2. VXLANカプセル化（Encapsulation）:
複製された元のパケット（L2〜L7ペイロード全体）に対し、新たなUDPヘッダー、IPヘッダー、そして VXLAN（Virtual eXtensible LAN）ヘッダー が付与されます。
- VXLAN VNI（Virtual Network Identifier）: ミラーリングセッションを一意に識別するための24ビットのIDが付与され、どのミラーリング元からのパケットであるかをターゲット側で識別可能にします。
- 外側UDPポート: デフォルトでは宛先ポートとして
4789が使用されます。
3. ターゲットへの転送:
カプセル化されたパケットは、通常のVPCルーティングテーブルに従って、ミラーリングターゲット（Target）であるEC2インスタンスのENIへとルーティングされます。
+------------------------------------------------------------+
| [ 元のパケット (L2 - L7) ] |
+------------------------------------------------------------+
↓
+------------------------------------------------------------+
| [ 外側IPヘッダー ] + [ 外側UDP (4789) ] + [ VXLANヘッダー(VNI) ] |
| +--------------------------------------------------------+ |
| | [ 元のパケット (L2 - L7) ] | |
| +--------------------------------------------------------+ |
+------------------------------------------------------------+
↓
[ ミラーリングターゲット (EC2) で受信・解析 ]—
2. 構築と設定の実践：AWS CLIによるトラフィックミラーリングの構築
理論を理解したところで、実際にVPCトラフィックミラーリングを構築するための具体的なAWS CLI手順を見ていきます。ここでは、特定のデータベースサーバー（Source）のトラフィックを、セキュリティ分析用のIDS/IPSインスタンス（Target）へ流し込むシナリオを想定します。
ステップ 1: ターゲットとフィルターの作成
まずは、パケットの受け皿となるターゲット（内部的にはターゲットENIやNLBを指定可能）と、どのパケットを抽出するかを定義するフィルターを作成します。
# 1. ターゲットの作成 (セキュリティ分析用EC2インスタンスのENIを指定)
aws ec2 create-traffic-mirror-target \
--network-interface-id eni-0123456789abcdef0 \
--description "Security Analysis IDS Target ENI"
# 2. フィルターの作成 (すべてのTCPトラフィックをキャプチャする例)
aws ec2 create-traffic-mirror-filter \
--description "Capture all TCP traffic"
# 3. フィルターのルール追加 (方向: INBOUND, プロトコル: TCP(6))
aws ec2 create-traffic-mirror-filter-rule \
--traffic-mirror-filter-id tmf-0123456789abcdef0 \
--traffic-direction "ingress" \
--rule-number 100 \
--rule-action "accept" \
--protocol 6 \
--destination-cidr-block 10.0.1.0/24 \
--source-cidr-block 0.0.0.0/0ステップ 2: セッションの結びつけ
フィルターとターゲットが用意できたら、ソースとなるENIと結びつけてミラーリングセッションを有効化します。
# 4. トラフィックミラーリングセッションの作成
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 "Mirror DB Server Ingress Traffic to IDS"—
3. ターゲットインスタンス側のLinuxカーネルチューニングとパケット処理
ミラーリングされたVXLANパケットを受け取るターゲットインスタンスは、膨大なトラフィックの二重化処理（通常の自機宛てパケット ＋ ミラーリングパケット）に晒されます。そのため、Linuxカーネルのネットワークスタックとバッファのチューニングが極めて重要になります。
VXLANデカプセル化とCPU負荷の軽減
ターゲットインスタンスのOS（例: Amazon Linux 2023）では、受信した 4789 ポートのVXLANパケットをカーネルが効率的に処理できるよう、RSS（Receive Side Scaling）やRPS/RFSの設定、そしてNICのオフロード機能を適切に有効化する必要があります。
以下のカーネルパラメータチューニングを /etc/sysctl.d/99-traffic-mirror.conf として配置し、パフォーマンスを最適化します。
# カーネルのネットワーク受信バッファの最大値を拡大 (高スループット対策)
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.rmem_default = 33554432
net.core.wmem_default = 33554432
# ネットワークデバイスのバックログキューを拡張 (パケットロス防止)
net.core.netdev_max_backlog = 250000
# TCP受送信バッファの自動チューニング範囲を設定 (最小, デフォルト, 最大)
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432反映コマンド：
sudo sysctl --systemターゲット側でのパケットキャプチャ確認
ターゲットインスタンス側では、標準的なパケットキャプチャツールである tcpdump や Wireshark を用いて、VXLANカプセル化されたパケットを観測できます。
# ポート4789 (VXLAN) に到着するミラーリングパケットをキャプチャ
sudo tcpdump -i eth0 -nnvvS udp port 4789出力結果の中で、VNI（Virtual Network Identifier）や、カプセル化された内側の元のパケットヘッダーが正しくカプセル化されていることを確認します。
—
4. 極限のパフォーマンスとセキュリティ：RTT削減、スループットの限界、そして脆弱性の回避
トラフィックミラーリングを本番環境に導入する際、インフラアーキテクトが直面する現実的なボトルネックと、それを回避するための設計知見を共有します。
1. 帯域幅のサイジングとスループットの罠
トラフィックミラーリングは、ソースENIを通過するトラフィックをそのまま複製して流すため、ターゲット側のネットワーク帯域幅は「通常の業務トラフィック ＋ ミラーリングトラフィック」を処理できるキャパシティが必要です。
- ソースがギガビット超の通信を行っている場合、ターゲット側も
Enhanced Networking（ENA）が有効化されたインスタンスタイプ（例:c6i.4xlarge以上）を選択し、十分なPPS（Packets Per Second）処理能力を確保しなければなりません。 - ミラーリングデータ自体はAWSの内部ネットワークを経由しますが、同一AZ内であっても転送量に応じたコストが発生する点に注意してください。
2. MTU（Maximum Transmission Unit）とフラグメンテーションの回避
VXLANカプセル化を行うと、元のパケットに50バイト以上のオーバーヘッド（外側Ethernet(14) + IP(20) + UDP(8) + VXLAN(8)）が追加されます。
- 標準的なVPCのMTUは
9001バイト（ジャンボフレーム）に設定されているため、通常サイズ（1500バイト）のパケットであれば問題なくカプセル化・転送されます。 - しかし、もしソース側やその途中の経路でパケットサイズが
9001バイトに近い巨大なパケットを扱っている場合、VXLANヘッダーが付与されることでジャンボフレームの制限を超過し、IPフラグメンテーションが発生するリスクがあります。これが原因でターゲット側でのデカプセル化コストが増大し、CPU使用率が跳ね上がる現象が現場でよく見られます。 - 対策: ソース・ターゲット間の経路、および解析ツールのMTU設計を慎重に行い、可能であればパスMTUディスカバリー（PMTUD）が正常に機能する状態を維持してください。
3. セキュリティとプライバシーのガバナンス
トラフィックミラーリングは非常に強力である反面、「平文の機密データ（データベースのクエリ、セッションID、個人情報など）」をそのまま別のインスタンスへコピーして転送する仕組みです。
- ミラーリングされたトラフィックが流れる経路（VPC内）への不正アクセスを防ぐため、ターゲットENIがアタッチされたセキュリティグループは厳格に制限し、許可された監視ツール以外のアクセスを完全に遮断（Deny）する必要があります。
- また、コンプライアンス要件（PCI DSSやGDPRなど）において、機密データの複製が意図しないストレージやログ基盤に保存されないよう、セッションのスコープを最小限のフィルタリングルールで絞り込むことが、セキュリティアーキテクトとしての必須要件となります。
—
5. まとめ
AWS VPCトラフィックミラーリングは、ハードウェアオフロード（Nitro）の恩恵を受けながら、ハイパーバイザーのオーバーヘッドを最小限に抑えてネットワークパケットを安全に抽出できる現代的なモダナイゼーションの結晶です。
しかし、その背後にあるVXLANカプセル化の仕組み、MTUのサイジング、そしてLinuxカーネルレベルのバッファチューニングを理解していなければ、予期せぬパケットロスやスループットの低下、さらにはセキュリティインシデントを引き起こす両刃の剣でもあります。
パケットの挙動をミクロな視点で愛し、マクロなクラウドアーキテクチャ全体を俯瞰する――それこそが、我々SREやインフラエンジニアが追い求める「真の可観測性」へのアプローチなのです。
コメント