tcpdumpのいろは(2)

ひえぇえええ、すごく間が空いてしまった。

さてさて、tcpdumpだがまずはデータを取得しなくてはいけない。そう、tcpdumpの解析は「まずダンプが取れて何ぼ」なのだ。

で、最初に一言重要な事を

tcpdumpが気楽に取れると思うな

一例を挙げよう。1Gbpsのネットワークカードが1枚あって、そいつが通信しているさまを取得したいとする。どうやるのかはともかく、どういう原理かはともかく、それができるとしよう。

すると、1Gbpsなので、全力全開でデータ通信されると、1Gbps…つまり8秒で1Gbyteのデータが取れる計算になる。もちろん、実際はネットワーク利用効率の問題とか、そもそもパケットをキャプチャするソフトがそんなに早く動作するのか、とかいろいろ要因はあってそこまでのデータ増量にはならないのだが、それでも 10-12秒で1Gbyteの量にはなるのだ。

当たり前だが、HDDもその速度に対応しなくてはいけない。PCのバス(PCI-Expressとか xPCIとか)は、NICの流量とHDDの流量の両方を流せるだけの速度が必要になる。同様にメモリだってかなりの容量がないと瞬間風速に耐えられないし、そのメモリはかなり速くなくてはいけない…。なので、普通はEthernet Switchの高いのを間に噛ませて、パケット duplication (パケットを別のポートにもべたコピーで送る機能がある、高いスイッチを使うということだ)した上で、パケットキャプチャ専用マシンを用意する。

ちゃんとしたプロは^*データ取得用に Raid0 を組んだり、SSD(Solid State Disk)つまり RamDiskの化け物を用意したりする。そうしないと意味のあるデータが取れないのだ。HDDの速度に引っ張られてNICの送受信速度が変化してしまい、結果としてtcpdumpを取得しなかった場合には起こっていた現象が起こらなくなった…と言うのでは本末転倒だ。

*) 「ちゃんとしたプロは」と言うということは、「ちゃんとしていないプロ」が世の中に満ち溢れていて、全然役に立たないデータを取ってきて「さぁ、見てくれ」と言う馬鹿者が多い事をも意味する。

つまり、こういう特別な環境が無い場合、disk cache がどうにか対処できる時間程度しかパケットキャプチャはできない事を意味する。かなりリッチな環境でも5分取れたら良い方だろう。5分程度、負荷がかなり軽い環境であっても数Gbyteのデータにはなる。

高速なHDD (USB2接続なんか論外だ)を、きちんとデフラグした上で(できればファイルシステムを再フォーマットするのが望ましい)、キャプチャ専用に準備して欲しい。


今回は別件が忙しいので、とりあえずここまでっ!!

tcpdumpのいろは(1)

/.Jのokky の日記に書いたようにtcpdumpの基本についてお客様に説明するためにまとめた。結局その資料は使えなかったわけではあるが、まとめたおかげでイヤンなバグを発見する事ができた。

で、そのままだともったいないので、まとめたものについて再度まとめなおしてここに掲載してみる事にした。もしかしたら他の人の役に立つかもしれないし、最低限でも自分の役には立つから (^^;)。同じ資料を作り直す事自体はともかく、構成から考え直すのはしんどいので。それに運がよければ、ここへのポインタだけ張っておけばOKとかいう手抜きができる場合も…。

さて、この話は大きく3つに分ける事ができる。

1. tcpdumpの物凄く大雑把な基本原理。どうやってパケットはキャプチャされているのか、どういう制限があるのか、等。ようするに基本データが持っている特性を理解するって事ですね。あと、どういう風に取るべきかとかも。
2. tcpdumpの結果の解析方法。ただし、今は Wireshark というとても賢いソフトがあるので、そいつに押し付けられる部分は説明しません。
3. multi sessionを利用するプロトコルを解析する上での注意点。まぁ、よく知られている例として FTP なんぞを。多分、読んでいる分には当たり前の話に聞こえると思いますが、たまに忘れるので。

もうすでに出てきたが、Wireshark程度は扱えるようになっていることを前提とする。どうもWindows版のWiresharkにはフィルターロジック周りに微妙なバグがあるんじゃないか…と思うことがあるが…同じロジックを Linux 上の Wireshark に与えたときと結果が違うし…その辺りはあまり深く突っ込むつもりは無い。細かい話は確か何冊か Wireshark の使い方に関する本が出ているので、そちらを参照する事。ただし、内容に関しては保障しない。まだ読んでいないので。

Wiresharkはものすさまじくメモリ(仮想アドレス)を消費する。Windowsの32bit版ではあまり大きなキャプチャファイルの解析はできないだろう。64bit版OS…Linuxとか…が動いている環境を用意し、その上で 64bit版バイナリの Wireshark を利用する事をお勧めする。editcapとかを使って、キャプチャファイルを一旦分割し、tshark を使ってそれぞれにフィルタをかけ、最後に mergecapを使って結合しなおす…というノウハウは説明しない。ただ、この場合も結局テキストコンソールの環境がリッチな Linux の方が便利なので(でなければ、cygwin とかね)、やはりそれ系の環境を整えておく事をお勧めはする。


Ethernetの動作原理だの、ルーティングアルゴリズムだの、そういうことは説明しない。実はパケットをキャプチャする上でこれらの知識は必須なのだが、対象があまりにも広大すぎる上に、殆どの人にとって使う知識はその中のごく一部だから。
ただし、殆どの人が使う共通の項目がある、という意味ではない。AさんとBさんはそれぞれが全体の 0.1%ぐらいしか必要としないが、重なる部分は殆ど無い、と言う意味だ。これは、必要な知識のうち大半が Cisco とその他、WAN と LAN の違い、などに起因するからで、そんな環境を個人で持っている人は、こんなドキュメントは読む必要すらないからだ。

最後に。「これはうちの話じゃないか?!」と思う人がいるかもしれないが、完全に気のせいです。ネットワーク障害と言うのは、はっきりいうとどこでも、ここでも、そこでも同じように起こるもんです。もう一つついでに言うと、機材が分散しているためでしょうか、複数の機器間で設定が破綻して通信がおかしくなる、というケアレスミス・人的ミスはその道のプロのかたがたの環境の方が頻繁に起こるぐらいです。パケット解析を必要とする状況というのはそんなものです。

では、行ってみることにしましょう。