Bluecoat SGでのパケットキャプチャと障害解析

(1)概要
SGではパケットキャプチャをすることができる。とても便利な機能で障害解析には欠かせないが、使用にあたってはいくつか注意が必要となる。殆どの場合はインターフェースにALLを指定し、保存したキャプチャファイルをダウンロードしてWireSharkで読み込んで解析する。

(2)TCP Segmentation Offload機能
SGでキャプチャしたパケットを見ると、MTUより大きいサイズのパケットがある。
SGはサイズの大きなパケットを送信する際、TCP Segmentation Offload機能によりIPパケットを分割する。ただし、SG上のPCAPでは分割前のデータをキャプチャしているため、セグメンテーション分割する前のフレームが記録されるとのこと。つまり、WireSharkではサイズ超過に見えるが、実際には分割されて送信するため、外部のスイッチで確認すれば1518Byte未満になっている。

(3)Encrypted-tapのパケット
復号化したパケットがキャプチャデータに混ざっていると、解析しにくい事が多い。
その場合はencrypted-tapの出力データは送信先MACアドレスが決まっているのでそのアドレスをパケットキャプチャから特定してフィルタして保存しなおしたほうが良い。

3.障害ケース
プロキシは様々なケースの障害が発生する。発生要因を区分し、整理することが重要となる。
最初に大きな区分として、サーバで発生したエラーなのか、通信で発生したエラーなのかを切り分ける。

(1)サーバで発生する障害としてよくあるケース
401 Unauthorized プロキシ認証をしている場合には間違えやすいが、これはサーバの認証。プロキシ認証は407となる。
403 Forbidden
404 Not Found
503 Service Unavailable
これらは基本的にサーバ側でアクセス制限をかけている場合や、サーバのエラーなどに起こるものであり、一次切り分けとしてはSGの要因を除外する。だが、プロキシを設置したら発生したと言われる事も多い。その理由のほとんどはインターネット上のサーバから見える送信元IPアドレスが変わったため。外部プロキシのIPアドレスが変わる場合には事前の周知をしつこいくらいやったほうが良い。

(2)通信で発生する障害としてよくあるケース
SSLエラー、TCPエラー
WEBブラウザに表示されるSSLエラーは主に証明書関連の問題と思われる。TCPエラーには様々な要因があり、サーバの要因かSGの要因か判断がつかない。SSLの問題や、プロキシ経由だとダウンロードやアップロードが遅いなどのケースは解析が難航するケースがある。通信が遅い原因はTCPの問題であるケースが多い。クライアント側もしくはサーバ側のどちらかの通信で問題が生じていないかチェックする。Delayed Ackに起因する場合も多い。SSLの問題を疑う場合にはClientKeyExchangeでPreMaster Secret を送っているかどうかをチェックする。

プロキシサーバが応答しない
WEBブラウザにこのように表示されることがあるが、実際にはSGが全く応答していないというケースは少ないと思われる。TCPのハンドシェイクはできているが、サーバ側のコネクションに問題があってクライアントにデータを渡せないということもある。これもパケットキャプチャを解析する必要がある。

(3)SGのポリシー
policy dennied
SGのポリシーで弾かれているので、要件とポリシーを見直す必要がある。通信先がリダイレクトされていないかどうかにも注意する。