夜になるとネットワークが遅くなる？：コマンドを使ってトラブルシューティング（10）（2/3 ページ）

[山本洋介，＠IT]

通信量をルーターに教えてもらう

　さて、どうすればいいのでしょう。

　封筒にはもう1枚紙が入っていました。相変わらず焦っていた律子さんは見落としていたのです。そこにはこんな風に書いてあります。

　　　「mrtgを使えばルータの統計情報が取れますよ」　　　

　mrtgを使えばルータにアクセスして勝手にグラフを作ってWebブラウザで見られるようにしてくれることを教えてくれてます（参照記事：MRTGによるサーバ監視システムの構築）。

　早速インストールしなくちゃ、と思い調べてみると、すでに動いているようです。前任の人がネットワークのチェックのために動かしていたようです。まったく見落としていましたが、引き継ぎがまったくないとこういうところで困ったことが出てきます。

　mrtgの結果はWebブラウザからからアクセスできるので、ブラウザから確認してみると、確かに毎日のトラフィックは安定しているものの、1日のデータを見ると夜のトラフィックだけがすごい量になっています。

グラフ1　mrtgをグラフ化して1日のトラフィックを確認すると……

　夜は大体の人が帰っているはずなのに……、なぜ？　誰がこんなにトラフィックを発生させているのでしょう。夜中に大量のバッチ処理が発生しているのではないかと思いましたが、律子さんの会社でそんなことをしているという話は一度も出たことがありません。

　もしかすると、知ってはいけない会社の秘密を見つけてしまったのかしら。そんな怖い考えが律子さんの頭に浮かびます。

　もしかすると会社の秘密組織に殺されてしまうかも、そんなことを考えていると仕事もちっとも手に付かず、進ちょくが遅れていくばかりです。勘違いだと思えるようになるにはこの大量アクセスの犯人を知る必要があるのですが、mrtgのグラフだけでは誰からそのアクセスがあったのか分かりません。

　ああ、どうしよう。すっかり途方に暮れた律子さんです。

　机でため息をついていると、コンソールにメッセージが送られてきています。律子さんは何が起こったか分かりませんが、どうやら相手はtalkコマンド（参照記事：Linux Tips チャットをするには）を使っているようです。そこには、以下のようなメッセージが書かれています。

　　　　　「tcpdumpでパケットが取得できますよ」　　　　　

とメッセージが書かれています。

　ああ、そうだ、tcpdumpを使うと個々のパケットを捕捉できるんだった。

　会社の秘密データのやりとりでないことを明らかにして、背後を気にしなくて済むようにするためにも、一刻も早くやらないと。そう思った律子さんは、早速tcpdumpを使ってすべてのパケットのやりとりを監視することにします（※Windowsだとwindump）。

tcpdumpを使ってすべてのパケットのやりとりを監視する

# tcpdump > dump1.log
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN100MB (Ethernet), capture size 96 bytes

　tcpdumpを動かすと、そそくさと律子さんは家に帰っていきました。

　よし、これで大丈夫、と律子さんは会社を後にして、朝まで待つことにしますが、気になって夜も眠れません。

　眠れなかったのもあって、次の日の朝、いつもより早めに出社して、早速データを見てみることにします。

　「さーて、誰がパケットばらまいてるのかな？」

昨夜のトラフィックデータ

$ cat dump1.log
 
00:02:23.801189 IP 192.168.0.9.netbios-ns > 192.168.0.127.netbios-ns: NBT UDP PA CKET(137): QUERY; REQUEST; BROADCAST 
00:02:24.551211 IP 192.168.0.9.netbios-ns > 192.168.0.127.netbios-ns: NBT UDP PA CKET(137): QUERY; REQUEST; BROADCAST 
00:02:36.522002 IP 192.168.0.9.netbios-ns > 192.168.0.127.netbios-ns: NBT UDP PA CKET(137): QUERY; REQUEST; BROADCAST 
00:02:37.271142 IP 192.168.0.9.netbios-ns > 192.168.0.127.netbios-ns: NBT UDP PA CKET(137): QUERY; REQUEST; BROADCAST 
00:02:38.021163 IP 192.168.0.9.netbios-ns > 192.168.0.127.netbios-ns: NBT UDP PA CKET(137): QUERY; REQUEST; BROADCAST 
00:03:20.290582 arp who-has 192.168.0.17 tell 192.168.0.1 
00:03:20.290616 arp reply 192.168.0.17 is-at 00:11:24:76:ce:50 
00:03:21.243689 arp who-has 192.168.0.100 tell 192.168.0.2 
00:03:27.243793 arp who-has 192.168.0.100 tell 192.168.0.2 
00:03:33.243908 arp who-has 192.168.0.100 tell 192.168.0.2 
00:03:46.398101 IP 192.168.0.17.50171 > 239.255.255.253.svrloc: UDP, length: 36 
00:03:46.398393 IP 192.168.0.17.50172 > 239.255.255.253.svrloc: UDP, length: 36 
00:03:46.398740 IP 192.168.0.17.50173 > 239.255.255.253.svrloc: UDP, length: 36 
（長いので抜粋です）

　期待に胸をふくらませて、ログを見てみましたが、ブロードキャストあてのデータばかりしかキャプチャできていません。

　ああ、スイッチだと、LANが分割されてしまい、ほかのポートあてのデータは取れないんだった（参照記事：VLANの基本的な仕組みを攻略する）。この1日が無駄になってしまいました（※ミラーポートが付いているスイッチなら取得可能です）。

　失敗したなあ。

　律子さんはめげずに会社の引き出しの奥から、すでに使われなくなったリピータを取り出して、現在のスイッチを交換して、再びパケットをキャプチャしてみることにします。

スイッチをリピータに取り替えて、ほかのポートあてのデータも監視

# tcpdump > dump2.log
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN100MB (Ethernet), capture size 96 bytes

　さて、今度こそ。今度はすべてのインターネット向けパケットをキャプチャすることができているはずです。