この記事は少々ニッチな内容を含みます。ご了承ください。

はじめに

F5 BIG-IPのClonePool機能で転送したパケットをRiverbed AppResponseで解析する方法を紹介します。

記事の前半は、BIG-IPからAppResponseにどのようにパケットを転送したか
記事の後半は、AppResponseで解析したか
について紹介しています。

BIG-IPでパケットキャプチャを取得する方法をこちらの記事で整理しましたが、
tcpdumpによるパケットキャプチャ取得方法は大容量通信を取り続けるには適していません。

理由としては、tcpdumpを利用した場合はBIG-IPの容量を気にする必要があり、かつ、内部に保存したファイルを外部へ転送してWireshark等で別途解析する必要があるためです。

ClonePool機能は、Virtual Server単位で指定したPool(Pool Memberと指定した宛先)へVirtual Server前後のパケットを転送することができます。

この記事では、単にBIG-IPからパケットを転送して別の機器でキャプチャ取得するだけではなく、AppResponseに転送することでアプリケーション通信の健全性を視覚的に解析した例です。

Riverbed社AppResponse
https://www.riverbed.com/ja/products/alluvio-appresponse/

1. ネットワーク構成

今回のテスト構成を以下に示す

2. BIG-IP設定

BIG-IPからGREカプセル化して転送する

BIG-IPのClonePoolはMACアドレスを書き換えてBIG-IPと同一セグメントの機器に転送する機能であるため、AppResponseが別セグメントにある構成を前提でBIG-IPからGREカプセル化して転送します

Virtual Server設定

項目	入力内容	説明
Type	Standard
Service Port	443	SSL(HTTPS)終端
Protocol	TCP
HTTP Profile	http-xff	X-forwarded-forヘッダー(送信元IP)を含む
SSL Profile (Client)	clientssl	SSL(HTTPS)終端
Source Address Translation	Auto Map	サーバ戻り通信を経由させるため
Pool	pool-server
Clone Pool (Client)	None
Clone Pool (Server)	pool-appresponse	暗号化されていないHTTP通信を複製転送

Tunnel/Self IP/Pool/HTTP Profile設定

項目	項目詳細	入力内容	説明
Tunnnel	name: Profile: Local Address: Remote Address:	tunnel-appresponse gre 10.1.30.21 10.1.20.191
Self IP	IP Address: Netamsk: Tunnel:	10.1.100.21 255.255.255.0 tunnel-appresponse	GREトンネルを経由させるための送信元IP 10.1.100.0/24は同セグメント
Pool	name: Member IP:	pool-server 10.1.30.180	HTTP ServerのIPアドレス
Pool	name: Member IP:	pool-appresponse 10.1.100.191	GREトンネルを経由させるための架空の宛先IP
HTTP	Insert X-Forwarded-For	Enabled	X-forwarded-forヘッダー(送信元IP)を含む

BIG-IPからGREパケットを転送する流れは下記

BIG-IPは、Clone Poolの設定によりpool-appresponse(10.1.100.191)へ転送
10.1.100.0/24に接続するSelf IP(10.1.100.21)からpool-appresponse(10.1.100.191)へ転送
Self IP(10.1.100.21)が属するtunnel-appresponseへ転送
Tunnel Local IP であるSelf IP(10.1.30.21)からTunnel Remote IP(10.1.20.191)へパケットを送信

（※実際には存在しないTunnel上のIPへ送信することでTunnelを経由させることがポイント）

3. AppResponse設定

AppResponseのインタフェース

AppResponseには3つのインタフェースがあります。

	インタフェース	IPアドレス	キャプチャ可否	用途
1	primary	有	GRE/VXLAN可 (先頭100Byteまで)	管理インタフェース
2	aux	有	不可	管理インタフェースの代替
3	monitor	無	可 (Byte制限なし)	通信をモニターするポート

primary もしくは monitor インタフェースでパケットキャプチャが可能です。

キャプチャ・ジョブ設定

Capture Jobs/Interfacesにて、どのインタフェースでパケットキャプチャを実施するかを設定します。
デフォルトでは、monitor インタフェース(mon0)でのみパケットキャプチャが開始されます。

GRE受信設定

今回はBIG-IPからGREカプセル化してパケットを転送するため、
AppResponseのモニターインタフェースのpriamry-gre を有効(Enable)に設定します。

Capture Jobs/Interfaces > Monitoring Interface > primary-gre > Enabledにチェック

BIG-IPからAppResponseのPrimaryインタフェースへGREパケットを転送した結果、Primary-greの受信バイト/数が増加することを確認

4. AppResponseでの解析

AppResponseのHome画面

AppResponse > HOME > All Traffic > Server IPsタブ (もしくはClient IPs)

上記画面のようにAppResponseのAll Trafficでは、
・Monitorインタフェースに転送されたパケットの送信元/宛先IPアドレスが確認可能
・Primaryインタフェースに転送されたGREパケットの送信元/宛先IPアドレスが確認可能
・Tunnel Client IP/ Tunnel Remote IPのみが表示され、GREカプセル化内部のIPは確認できない

GREカプセル化内部のIPを確認する方法
a) GRE Inner Server IP : Web Server IPsの画面で確認可能
b) GRE Inner Client IP : Web Client IPsの画面で確認可能

HTTPヘッダー内のX-Forwarded-forのIPを確認する方法
c) HTTP X-Forwarded-for のIP　： Web User IPsの画面で確認可能

a) 宛先IPでの確認

NAVIGATOR > Web Server IPs にて、GREカプセル化内部(実際に通信している)の宛先IPを確認できる

b) 送信元IPでの確認

NAVIGATOR > Web Client IPs にて、GREカプセル化内部(実際に通信している)の送信元IPを確認できる

下記画面では、送信元IPとしてBIG-IPのSNAT Automapで指定したFloating IP(10.1.20.23)が記録されている

c) 送信元IP(XFF:実際の送信元IP)での確認

NAVIGATOR > Web User IPs にて、GREカプセル化内部(実際に通信している)の送信元IPを確認できる

下記画面では、送信元IPとしてBIG-IPがHTTP HeaderのX-Forwarded-for(XFF)に挿入したClientのIPアドレスが記録されている

5. AppResponseからパケットをダウンロードする

AppResponse上でダウンロードしたい通信を選択し、右クリック > Download Packetsを選択

ダウンロードする条件を選択

Wiresharkにてキャプチャファイルの内容を確認したが、primaryインタフェースでは100Byteまでしかキャプチャできないため、HTTP HeaderのX-forwarded-forの部分までしか含まれていなかった。

今回のテスト構成ではPrimary/Monitorともに同じPortGroup(VLAN)としたため、Promiscuousモードを許可(Accept)に設定し、Monitorでキャプチャできるように変更

上記設定部分の詳細は下記記事をご参照ください。

AppResponse VM版を使ってみた
https://qiita.com/aktech/private/82ef52042c5e2eed4c8c

Wiresharkにて、GREヘッダーおよび HTTP XFF が含まれていることを確認

6.AppResponseでの解析方法

送信元IPアドレスによる解析

アプリケーション通信で問題が発生した場合にアプリケーション側のログ等から送信元IPアドレスが特定できる場合がある
AppResponseでは、送信元IPアドレスから当時の通信状況(遅延等)やキャプチャファイルを確認することができる

AppResponseの右上の検索窓に調査したい送信元IPアドレスを入力すると検索結果が表示される。
検索時に検索期間の指定を行う必要がある（デフォルトは1hで検索される）

上記画面で「Web User IP」のリンクから個別のFavoritesのページを開くことで詳細を確認できる。

該当IPアドレスが、アクセスしたリソースやResponseのStatus Code、応答時間を確認することが可能

また該当通信のパケットキャプチャーをダウンロードし、Wireshrak等で通信内容を確認することができる。

AppResponse解析による通信内容のヘルスチェック

例えば正常時にサーバーが応答するHTTP Status Codeが200である場合、それ以外のStatus Codeの応答は障害の可能性が考えられる。
HTTP Status Codeが200以外の通信をフィルタリングして、その通信状況を調査することが可能

例：応答されたStatus Codeが200の場合

例：応答されたStatus Codeが200以外であった場合（下記は404の場合、404sをクリックした状態)

(参考) AppResponse VM(ESXi)版を利用した際のTips

VMへのセカンダリ・ハードディスクの追加

AppResponseに届いたパケットをAppResponse上で解析するだけではなく、AppResponse内に格納してPacket Capture ファイルをDownloadできるようにするためには、AppResponse Virtaul Machineに2つ目のハードディスクの追加が必要

AppResponse 11 Virtual Edition Installation Guide より抜粋

Preparing the ESXi server
After you have deployed the OVA package to the server, you can add more virtual components:
one additional hard disk for packet storage of size 100GB

Adding a hard disk
The preconfigured AppResponse 11 has only one hard disk, the operating system disk. To have space for packet storage, you need to configure a second hard disk.

ESXi上のPortの設定

ESXi上のPort Groupは、タグ有・タグ無の全ての通信を受信できるように設定

設定項目	入力内容	説明
Port Group VLAN ID	ALL(4095)	タグ有・タグ無の全ての通信を受信
	xxx	特定VLANタグの通信のみ受信
Promicuous Mode	許可(Accept)	同セグメントの全てのフレームの受信を許可
	拒否(deny)	宛先IPのフレームの受信を許可

今回の構成の場合、同セグメントである管理通信(Prmary/Aux)を含む全てのトラフィックがキャプチャ対象となる（⇒不要な通信もキャプチャーしてしまう）

	PortGroup (VLAN/Promiscuous)	説明
Primary	10 / 拒否
Aux	10 / 拒否
Monitor	ALL(4095) / 許可(Accept)	Primary/Auxに届いたフレームを受信する

管理通信(今回は管理通信にAux利用)をキャプチャーしないようにするため、Aux経由のみキャプチャされないようにする設定例

	PortGroup (VLAN/Promiscuous)	説明
Primary	10 / 許可(Accept)
Aux	20 / 拒否
Monitor	10 / 許可(Accept)	Primaryに届いたフレームを受信する

参考URL

Riverbed社AppResponse
https://www.riverbed.com/ja/products/alluvio-appresponse/