LANから外に出られない！？：コマンドを使ってトラブルシューティング（1）（2/2 ページ）

» 2004年11月27日 00時00分公開

[山本洋介，＠IT]

前のページへ 1|2 　　　　　　

LANから外に出たものの

　さて、時間を取られた分頑張って仕事して取り返すか、と思って律子さんはメールチェックしてみました。するとまたメールの送受信ができなくなってるではありませんか。

　自分のマシンの問題かと思って再起動してみたりしましたが、進展はありません。しかも、今回はほかのWebサーバなどにはアクセスできるようです。

　どうしようとあたふたしていると、狙ったように先輩がやって来ます。「管理者さん、メールが送れないのですけど」と、嫌みったらしいものです。

　こっちも一緒です、と怒鳴り付けたくもなりますが、おとなしく「何とかしますので、もう少し待っててください」と愛想笑いを浮かべながら答えてみたものの、原因がまだ分からないので内心は穏やかではありません。

　「ほかのサーバへアクセスできるのであれば、メールサーバの近くのルータに障害が発生しているに違いない」そう思った律子さんは先ほどと同様にtracertコマンドを使ってみることにしました。

再度、メールサーバに向けてtracertコマンドを実行

C:\>tracert mail.example.co.jp
Tracing route to mail.example.co.jp[220.111.37.180]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.72.1
2 2 ms 2 ms 2 ms 219.160.1.8
3 2 ms 3 ms 3 ms 219.160.1.1
4 6 ms 4 ms 4 ms 221.184.12.161
5 3 ms 3 ms 5 ms 222.146.39.149
6 4 ms 3 ms 3 ms 219.160.10.33
7 4 ms 3 ms 3 ms 210.254.187.14
8 9 ms 3 ms 4 ms 220.111.40.2
9 3 ms 5 ms 3 ms 220.111.40.14
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
（以下略）
Trace complete.

　先ほどのtracertした結果と見比べて見ると、どうやらサーバの手前で障害が発生しているようです。多分ホスティング会社のルータが落ちているのでしょう。

　律子さんはホスティング会社の担当者に電話してトラブルの原因を確認しつつストレスを解消しようと思ったのですが、落ちているのは本当にホスティング会社のルータかどうか自信がありません。

　電話しようかと悩んでいると、またまたメッセージがポップアップされてきます。

　　　　　「WebでIPアドレスの割り当て情報を調べることができますよ」

　そうでした。Web上の情報で特定のIPアドレスがどの組織に割り当てられているか知ることができるのでした。律子さんはタイムアウトしているルータのIPアドレスをwhoisで調べてみることにします。

　とはいえWindowsでwhoisは利用できません。そこで、律子さんはJPNICのWhoisGatewayを使うことにしました。

JPNICのWhoisGateway

http://whois.nic.ad.jp/cgi-bin/whois_gw

　使い方は至って簡単で、テキストボックスにIPアドレスを入れて、横にある「query」と書かれたボタンをクリックするだけです。

画面1：JPNICのWhoisゲートウェイでルータのIPアドレスを問い合わせる

　早速ルータのIPアドレスを検索してみると、このルータが割り当てられているIPアドレスはホスティングしている業者のようです。勇んで電話を入れたところ、案の定ルータが故障していたらしく平謝りです。これでトラブルの原因をつきとめ、障害対応を業者に任せられるので安心です。

　しばらくたつと復旧したと電話がかかってきました。tracertでもう一度経路を確認してみると、メールサーバまでの経路は正常なようです。そしてメールのやり取りもできるようになり、同僚や上司からの冷たい視線もようやくなくなりホッとしました。

正常に稼働しているときのtracertコマンドの結果

C:\>tracert mail.example.co.jp
Tracing route to mail.example.co.jp[220.111.37.180]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 2 ms 2 ms 2 ms 219.160.1.8
3 2 ms 3 ms 3 ms 219.160.1.1
4 6 ms 4 ms 4 ms 221.184.12.161
5 3 ms 3 ms 5 ms 222.146.39.149
6 4 ms 3 ms 3 ms 219.160.10.33
7 4 ms 3 ms 3 ms 210.254.187.14
8 9 ms 3 ms 4 ms 220.111.40.2
9 3 ms 5 ms 3 ms 220.111.40.14
10 3 ms 3 ms 3 ms 220.111.40.70
11 3 ms 3 ms 2 ms mail.example.co.jp [220.111.37.180]
Trace complete.

　それにしても、私にアドバイスをくれるのは誰？　未来からやって来た自分の子孫かしら、とドラえもんやバック・トゥ・ザ・フューチャーのことを考えながら律子さんの夜は更けていくのでした。

ちょっと解説

　この夏は猛暑でいろいろなことが起こりました。暑さで機械もバテバテになってしまったようで、交換機のトラブルによる回線障害やルータの故障が頻繁に起きて、胃が痛い思いをした管理者の方も多かったでしょう。

　経路上のルータなどが故障するとどこに原因があるか調べる必要が出てきますが、そのときに便利なのが今回使われたtracert（traceroute）コマンドです。

　tracertコマンドはTTLを1つずつ増やしながら対象ホストあてにICMP Echoパケットを送り、その応答時間を見ることでトラブルの個所を把握することができます。

　また、その後使っていたwhoisコマンドですが、ホスト名から管理者やネットワークの情報を引き出すだけでなく、IPアドレスからそのIPアドレスが誰に割り当てられているか調べることができます。どこでトラブルが起こっているか目星を付けることができるので、そのIPアドレスが誰の持ち物なのか調べたいときには役に立つでしょう。（筆者）

「次回」へ

「コマンドを使ってトラブルシューティング」バックナンバー