サーバトラブル解決のセオリー 第2回

サーバにアクセスできない時のはじめの一歩

まずはリモートでトラブルの原因を切り分けよう

ユーザーから「サーバにアクセスできない」という問い合わせが入った際、直接そのサーバを操作できる場合と、リモートで操作しなければならない場合では対処方法が異なる。最終的には直接そのサーバを操作することになるのだが、まずは別の拠点にあるサーバなど、直接操作できないケースから解説しよう。

リモートで調査する

　別の拠点にあるサーバや、運悪く出張中や自宅にいるときに緊急で対応しなければならない場合、リモートでサーバの状態を調査するしかない。その際、ユーザーからの第一報は重要な情報源だ。詳細かつ正確に状況を把握するためには、必要に応じて報告者に連絡を取れるようにしておかなければならない。もっとも、管理者から見ればユーザーは素人なので、必ずしも正確に情報を報告してくれるとは限らないことは、肝に銘じておこう。

pingとtracertは基本

　リモートでのトラブルシュートは、図1のような手順が基本になる。まずは定番中の定番であるpingコマンドから試そう。もちろん、ファイアウォールの設定でpingを拒否しないようになっていることが大前提だ。

図1　リモートでのトラブルシュートの基本手順

　DNS（Domain Name System）で名前解決できる環境であれば、ホスト名でもpingを試してほしい。もし、IPアドレスで応答があり、ホスト名でエラーになれば、DNSに問題がある（画面1）。

画面1　 DNSで名前が解決できるかどうかのチェックを兼ねて、ホスト名でpingしてみる

　ただし、pingでエラーになったからといって、即サーバがダウンしているとは判断できない。途中にルータがある場合、ルータに問題があって、サーバにアクセスできないのかもしれないからだ。念のため、tracertコマンド（Windowsの場合）も試してみよう（画面2）。tracertコマンドは、pingと同様にICMP（Internet Control Message Protocol）を利用して、目的のサーバへ達するまでに経由するルータの応答をチェックする。

画面2　 Windowsの場合は8文字以内に収まるよう「tracert」と末尾が省略されているが、Linuxの場合はフルスペルで「traceroute」となる

Telnetでサービスと会話する

　pingなどで問題がない場合、サーバによっては、Telnetを使った簡便な方法でサービスがダウンしていないかどうかを確認できる。

　たとえばメールサーバなら、ポート番号25（SMTP）と110（POP）にアクセスして、サービスが利用できるかどうかを試してみよう（画面3）。直接コマンドを入力し、サーバから正常応答がなければ、該当サービスがダウンしていると判断できる。改めてTelnetやSSHでサーバにリモートログインを試みて、サービスの稼働状況などを調べてみよう。もしリモートログインもできないようであれば、深刻な事態に陥っているかもしれない。

画面3　 Telnetの使用例

　リモートでの調査は、ここまでがひと区切りとなる。これ以上の詳細は、現地で直接サーバを調査しよう。

（次ページ、「直接サーバを調査する～まずは電源から～」に続く）