はじめに

いつの間にかGCP(Google Cloud Platform)でもGCEのVMインスタンスのネットワーク通信を
フルパケットキャプチャできるサービスがBeta版で公開されていましたので簡単に評価してみました！

Azureは以前よりVMのパケットキャプチャするサービスがあり、パブリッククラウドベンダーの中では
先行している印象でしたが、6月にAWSのTraffic Mirroringが登場しているので
これで大手IaaSベンダーでネイティブにパケットキャプチャができるようになったのは、嬉しい限りです^^

【参考】
・Azure Network Watcherの可変パケットキャプチャの概要
・AWS VPC Traffic Mirroring

利用環境

VM Name	Zone	Network	Subnetwork	Instance Type	image	用途
ping-vm	us-central1-a	vpc1	subnetwork1(10.128.0.0/20)	g1-small	centos-7-v20191115	Ping実行用VM
mirrored-vm	us-central1-a	vpc1	subnetwork1(10.128.0.0/20)	g1-small	centos-7-v20191115	ミラー対象VM
capture-vm1	us-central1-a	vpc2	subnetwork2(10.129.0.0/20)	n1-standard-1	windows-server-2016-dc-v20191112	コレクターVM
※キャプチャされる側をミラー対象VM、キャプチャする側をコレクターVMと呼びます。

・本番利用を想定し、ミラー対象VMとコレクターVMを別VPCとしています。(vpc1とvpc2をVPC Peering接続)
・コレクターVMは、GUIで分かり易く表現するため、WindowsにWiresharkを入れてます。

【構成図】

※ミラー対象VMとコレクターVMは同一リージョンにある必要があります。(今回は、us-central1)

GCP Packet Mirroringとは

GCPのVPCネットワーク内のVMインスタンス(GCE)のNICを流れる通信を複製し
別のVMインスタンスに内部ロードバランサ経由で転送するサービスです。
(ミラー対象VMを、①サブネット、②ネットワークタグ、③VMインスタンスのいずれかで指定します)

これまでのオンプレミス環境では、ネットワーク機器のスイッチにミラーポートを設定して
キャプチャ用のマシンや機器を接続して、パケットデータの解析をしていたと思います。
主な用途は、「ネットワークトラブルシューティング」や「IDSやWAFでのセキュリティ監視」だと思います。

GCP Packet Mirroringの主な特徴は、以下だと思います。
・料金は、ミラー対象トラフィックのネットワーク転送料のみです。
・ミラー対象VMのNICには複製される通信も乗るため、性能を考慮し必要な通信のみにフィルタできます。
　(デフォルトは全てのトラフィックがミラー対象となります。)
・同一リージョン内であれば、単一VPCや異なるVPC間、共有VPC内でのパケット複製が転送できます。
・キャプチャ成功と失敗したパケット数やバイト数をモニターできます。(これは嬉しい)

詳細は、以下の公式ドキュメントを参照ください。

【参考】
・パケットミラーリングの概要
・パケットミラーリングの使用
・パケットミラーリングの監視

実施内容

以下のステップで設定を実施しました。

ファイアウォールルールの作成
キャプチャ用VMインスタンスの作成
インスタンスグループの作成
パケットミラーリングの作成
Wiresharkでのパケットキャプチャ

1. ファイアウォールルールの作成

ミラー対象のトラフィックをコレクターVMで受信できるようにファイアウォールルールを作成します。

今回は、以下のような内容でルールを作成しています。

名前	タイプ	ターゲット	プロトコル/ポート	アクション	優先度	ネットワーク	適用VM	用途
allow-ssh-ingress	上り	vpc1-ssh	tcp:22	許可	10	vpc1	ping-vm	ping-vmへのログイン用
allow-icmp-ingree	上り	vpc	icmp	許可	1000	vpc1	mirrored-vm	mirrored-vmへのICMP用
allow-capture-ingress	上り	capture	all	許可	10	vpc2	capture-vm1	コレクターVMのミラー通信受信
allow-rdp-ingress	上り	vpc2-rdp	tcp:3389	許可	10	vpc2	capture-vm1	コレクターVMへのログイン用

2. キャプチャ用VMインスタンスの作成

[GCPメニュー] > [Compute Engine] > [VMインスタンス]でインスタンスを作成します。
リージョン:us-central1 (アイオワ)、ゾーン:us-central1-aでインスタンスを
Windows Server 2016 Datacenterで構築しています。

下の[ネットワーキング]タブでネットワーク:vpc2、サブネットワーク:subnetwork2(10.129.0.0/20)を
忘れずに指定してください。(指定しないとdefalutネットワーク行きになります)

3. インスタンスグループの作成

[GCPメニュー] > [Compute Engine] > [インスタンスグループ]でインスタンスグループを作成します。
今回はシンプルに新しい非マネージドインスタンスグループで作成しています。
VMインスタンスにcapture-vm1を指定します。

4. パケットミラーリングの作成

[GCPメニュー] > [VPCネットワーク] > [パケットのミラーリング]でポリシーを作成します。
ポリシー名:pm-mirror (何でもOK)、リージョン:us-central1で続行します。

今回はVPC間で複製しますので
ミラーリングされるソースとコレクタの宛先が別々のピアリングされたVPCネットワークにある
にチェックを入れます。
ミラーリングされるソースVPCネットワーク:vpc1、コレクタの宛先VPCネットワーク:vpc2で続行します。

今回は、対象VMをmirrored-vmのみとするため、``個々のインスタンスを選択するをチェックを入れて 選択`をクリックします。

ここで内部ロードバランサを作成します。create new L4 internal load balancerをクリックします。

名前はcapture-bs (何でもOK)とし、バックエンドの設定を行います。

リージョン:us-central1、ネットワーク:vpc2、
インスタンスグループ:collector-ig1 (us-central1-a)を指定します。
ヘルスチェックは新規に作成して、指定します。今回はcollector-healthchaeck (TCP)を作成しています。

フロントエンドの設定は、名前:capture-fr (何でもOK)、サブネットワーク:subnetwork2を指定します。

最後にミラーリング対象のトラフィックの絞り込みになりますが
今回は10.128.0.0/20内のICMP、TCP、UDP通信としています。

これでパケットミラーリングの設定は完了です。

5. Wiresharkでのパケットキャプチャ

ping-vmにSSHログインし、pingコマンドを実施します。
(特に意味ないですが、最大サイズの1432バイトで実施しています。)

[*********@ping-vm ~]$ ping 10.128.0.3 -s 1432
PING 10.128.0.3 (10.128.0.3) 1432(1460) bytes of data.
1440 bytes from 10.128.0.3: icmp_seq=1 ttl=64 time=1.63 ms
1440 bytes from 10.128.0.3: icmp_seq=2 ttl=64 time=0.361 ms
1440 bytes from 10.128.0.3: icmp_seq=3 ttl=64 time=0.324 ms
1440 bytes from 10.128.0.3: icmp_seq=4 ttl=64 time=0.335 ms
^C
--- 10.128.0.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 0.324/0.663/1.634/0.561 ms
[*********@ping-vm ~]$

capture-vm1にリモートデスクトップ接続します。
Wiresharkを起動し、パケットキャプチャを開始します。(Wiresharkは別途インストール)
icmpでフィルタすると10.128.0.2(ping-vm)から10.128.0.3(mirrored-vm)への
PING通信が絞り込めます。(ちゃんと取れてますね笑)

また、GCPコンソール上でもミラーリングの状態が確認することができます。
ミラー対象VMの[VMインスタンスの詳細]でモニタリングをクリックします。

すると成功と失敗のバイト数とパケット数がグラフで追うことができます。(これステキ！)

まとめ

さて、いかがでしたでしょうか？

これでパブリッククラウドにおいてもこれまで以上に多くの情報が
パケットの中から判断できるようになりましたね！

半構造化されたデータからStackdriver loggingで多くのことが自動出来たりしますが
より詳細な情報が必要になるシーンでは大いに役に立つのではないでしょうか ^^/