この記事は少々ニッチな内容を含みます。ご了承ください。
はじめに
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以外であった場合(下記は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/