1. EC2上でパケットをミラーリング
安川 健太
Solutions Architect
Amazon Data Services Japan

2. 自己紹介
名前
• 安川 健太
• アマゾンデータサービスジャパン
ソリューションアーキテクト
好きなAWSのサービス
• CloudFormation
ソーシャル
• @thekentiest
• www.facebook.com/kenta.yasukawa
趣味
• 車いじり
• パケットキャプチャ

3. 本日の発表
EC2の上でレイヤーの低いところでいろいろ試してみた
体験談を皆さんと共有
• せいぜいL3とかL2とかくらいです
• L1までは行きません
（行けません）

4. ある日こんな質問を頂きました
パケットキャプチャ型のアクセス解析
• HTTPのリクエストとレスポンスをスヌーピングしてWebアクセ
ス解析
• 一般的にはポートミラーリングしてパケットをキャプチャ
パケットキャプチャ型のアク
セス解析ソフトを使っている
システムがあってAWS移行考
えてるんだけどどうにかなら
ない？
古いシステムの移行だから出来
れば手を入れたくないんだよね
とはいえ、EC2ではポートミラーリングも何も。

5. というわけで、考えてみる
こうすれば通過するパケット全部取れるけど
Availability Zone Availability Zone
Web Web
パケットコレクタ兼リバースプロキシ
とてもこんなシステム本番に投入できません！

6. ならばWebサーバに仕込むか
Webサーバからパケットの複製をコレクタに送る
Availability Zone Availability Zone
Web Web
DNS RR等
コレクタ
• これならコレクタ障害時もサービスは継続可
• コレクタはENIの付け替え等でフェイルオーバー可
• コレクタのパケット取りこぼしリスクはポートミラーリングでも同様

7. どうするのがシンプルか考えてみる
iptablesのteeターゲットを使えばパケットを集めるのは簡単
• リクエストパケットはちゃんと取れそう
• But, レスポンスパケットは無意味なデータに
ならパケットコピーしてL2で送りつけるか
• Classic EC2じゃ無理
• VPCだとしてもサブネット越えられない罠
GET Web コレクタ
fe:ff:ff:ff:ff:ff …
GET
200OK200OK
クライアントIPアド
レスが残らない

8. L3トンネル掘るしかないですかね
とはいえ
• オーバーヘッドは最小限にしたい
• 特別なソフトウェアは入れたくない
• カーネルで処理を完結させたいのが人情
IP-in-IPにしましょうか

9. IP-in-IPでコレクタにパケットを集める
図にしてみると
コレクタ
Web 1
Web 2
GET
192.168.1.10
192.168.1.100 192.168.1.101
200OK
ENIのSource/Destinationチェックは外すこと！
200OK
GET
192.168.1.10 192.168.1.20
GET
GET
192.168.1.10 192.168.1.20
Dst Src

10. IP-in-IPトンネルを作って
tcでパケットのコピーを流し込むよう設定
Webサーバ側
コレクター側
# ip tunnel add ipip0 mode ipip remote 192.168.1.20 local 192.168.1.10 ttl 64
# ip tunnel add ipip0 mode ipip remote 192.168.1.10 local 192.168.1.20 ttl 64
# tc qdisc add dev eth0 root handle 10: prio
# tc filter add dev eth0 parent 10: prio 10 protocol ip u32 match ip protocol 6
0xff match ip sport 80 0xffff flowid 10:1 action mirred egress mirror dev ipip0
# tc qdisc add dev eth0 ingress
# tc filter add dev eth0 parent ffff: prio 10 protocol ip u32 match ip protocol 6
0xff match ip dport 80 0xffff flowid 10:1 action mirred egress mirror dev ipip0

11. 早速検証開始！
コレクタで tcpdump -n -i ipip0
手元のPCで curl http://<web serverのIPアドレス>
カーネルが刺さる。。。

12. パケットキャプチャしてみると
# tcpdump -n -i ipip0
listening on ipip0, link-type RAW (Raw IP), capture size 65535
bytes
06:20:11.189928 IP 54.248.89.97.43276 > 192.168.1.133.http:
Flags [S], seq 3142846341, win 14600, options [mss
1460,sackOK,TS val 41435115 ecr 0,nop,wscale 4], length 0
06:20:11.189961 unknown ip 0
なんだこれ？

13. もう少し詳しく見てみると
あれ？IPヘッダがこ
んなところから始
まってる
１４ octets
なんだ、Ethernetの
ヘッダじゃないか
ご丁寧に次がIPヘッ
ダって書いてあるし
ループバックや物理I/Fには出ないトンネルI/Fだけに出る挙動 … バグ？

14. 仕方ないのでコードを書く
元のIPパケットを新しいIPパケットのペイロードに
新しいIPヘッダを生成
プロトコル番号を4 (= IP in IP)にセット

15. 期待通り動きました
やってみまーす！
よかったらこちら
で検証などを

16. ところでVPCならL2も自由になります

17. VPCならいろいろL2を使ったトリックが使
えそう
L2 NAT （ebtablesとか）
DSR (Direct Server Return)
なんちゃってブロードキャスト/マルチキャスト
• ブロードキャストEthernetフレームをユニキャストで送り直す

18. まとめ
IP-in-IPを使えばパケットを集めてキャプチャするよう
なユースケースも実現出来る
但し、IP-in-IP + tc on Linuxは要注意
VPCならL2まで自由が利く
人から聞いた「クラウドだと○○は出来ない」は鵜呑みに
せず試してみるのが大事