はじめに
こんにちは！
名古屋に引っ越してそろそろ二週間、
自炊を再開したBFT名古屋支店 インフラ女子（？）の山口です。
トラブルシュートは、経験を積むことによってレベルアップしますが 、実際にトラブルシュートを実践できる人は限られてきます。
トラブルシュートしながら設定変更をする場合、裏で誰かが想定外の変更してたらトラブルシュートにならないですよね。
この記事では、サーバにつながらない、という時にトラブルシュートで使う基本的なコマンドをご紹介し、いざ自分がやる、という時の助けになればと思っています。
また、基本的な用語の説明はしておらず、コマンドを使ったことあるけどそれをトラブルシュートにどう活かすか、でお悩みの方を対象としています。
トラブルシュートの前に
やみくもにやっても、身につかないのがトラブルシュートです。
あくまでも基本が大事です。
基本の考え方
OSI参照モデルを軸に考える
インフラエンジニアなら必ず一度は聞いたことがあるであろう、「OSI参照モデル」です。
トラブルシュートをする時は、このレイヤーの概念に沿って下から確認します。
慣れてくると上の層、下の層を順に確認しどこの層に問題があるのか、と絞り込んでいく確認の仕方もアリです。でもまずは、下から。これは鉄則です。
物理構成や論理構成を理解しておく
これを理解しないまま、トラブルシュートをすることはできません。
自分がアクセスしたいサーバまではどんなネットワークで、どんな構成なのかは普段から頭に入れておく必要があります。
これさえしておけばトラブルシュートの8割は終わっていると言っても過言ではない…
トラブルシュートしてみよう！
ではさっそくやっていきましょう！
レイヤー１～３の確認（pingコマンド）
元々つながっていた、構築中、など確認する時の状況はさまざまなのでやらない場合もありますが、pingコマンドを実行しておくとまずは第３層までは問題なしという切り分けができ安心します。
Windows、Linuxどちらも実行するコマンドは一緒です。
Linuxの場合はデフォルトで実行し続けるので、途中で Ctrl + Cで止めてください。
ping <宛先ホスト>
宛先ホストはできればホスト名ではなく、IPアドレスがオススメです。ホスト名になると名前解決も絡んでくるからです。
pingコマンドの実行に失敗する場合、原因は主に以下が考えられます。
- サーバの電源が入っていない
- サーバがネットワークに接続されていない（ケーブルが抜けている）
- 途中のルータ等で設定が抜けている
- 途中のネットワーク機器やプロキシでフィルタされている
- サーバ側で止められている（SELinux, firewalld）
- クライアント側で止められている（ファイアウォール設定）
会社内のネットワークからpingコマンドを実行する場合、4のケースは多いので、事前に確認しておくとよいです。
このpingコマンド、返ってくるメッセージである程度状況を確認できます。
一番よく見るのは、下図のような「宛先ホストに到達できません」ではないでしょうか。
（Linux だと「Destination Host Unreachable」ですね）
この実行結果から、途中のルータ等で宛先のIPアドレスへの経路を持っていないか、そのホストがネットワークに接続されていないということがわかります。
ちなみにここでipconfigコマンド（Linuxだとip addressコマンド）を実行することも多いです。つながらない原因が自分の端末の設定だった、ということはあるあるです。
自端末の設定を確認するポイントは以下の二点です。
- IPアドレスが適切に設定されている
- デフォルトゲートウェイが適切に設定されている
「適切に」と書いてあるところが最もミソなのですが、この辺りは別の記事で詳しく書こうと思います。
レイヤー４の確認（telnetコマンド）
宛先ホストが生きていることを確認したところで次に確認するのは対象のサービスが生きているか、ということです。
telnetコマンドはWindows, Linuxともに基本的には手動で導入する必要があります。組織のポリシー、構築するシステムのポリシーによって禁止されることもありますがtelnetクライアントは強力なトラブルシュートツールなので入れておくといいと思います。
こちらもWindows、Linuxどちらも実行するコマンドは一緒です。
telnet <宛先ホスト> <ポート番号>
宛先ホストをIPアドレスにすればつながるのに、ホスト名だと繋がらない場合は、最後のnslookupコマンドのところで確認しましょう。
ポート番号は、そのサーバが提供しているサービスのポートを指定してください。
ただし、何のポートで待ち受けているかはそのシステムの設計によります。通常であればWebサーバは80(HTTP)や443(HTTPS)ですが、変更していることも多いですね。
Windowsクライアントからtelnetマンドを実行してブランクな画面に切り替わればポートが開いている＝確認したサービスが起動している、とわかります。
接続できない場合は、以下のようにエラーが出力されます。
pingコマンドは通ってtelnetコマンドが通らない場合、原因は主に以下が考えられます。
- サーバ側でサービスが起動していない
- サーバ側でサービスは起動しているがポートに接続できない
- ポート番号が異なる
- CPU, メモリ使用率の高騰などで接続できない
- サービスの接続上限に達している
- 途中のネットワーク機器やプロキシでフィルタされている
- サーバ側で止められている（SELinux, firewalld）
- クライアント側で止められている（ファイアウォール設定）
telnetコマンドで接続できず、指定しているポートが間違いでなければ、この後はサーバ側の確認をします。
サーバ側の確認コマンドはまた次回。
名前解決の確認（nslookupコマンド）
つながらない原因としてあるあるなのが名前解決です。
IPアドレスだとつながるのに、ホスト名だとつながらないという時は名前解決の部分を重点的に確認します。
nslookup <宛先ホスト名>
このコマンドはDNSサーバへ宛先ホストのIPアドレスを問い合わせるのでどうやってそのホストの名前解決をするのか、は事前に確認しておく必要があります。
通常はhostsファイルを利用するか、DNSサーバを利用するかの二択です。
単純にシステムでDNSサーバを使っているからDNSサーバで名前解決する、ではないことに注意してください。
そのシステムの設計として、その宛先ホストはコマンドを実行している端末から(ここがポイント) どうやって名前解決するのかが大事です。
ここがうまくいかない場合、hostsファイルに宛先ホスト名とIPアドレスを記載し、pingコマンドやtelnetコマンドをホスト名で実行します（IPアドレスではないことに注意）。
単純にコマンドで宛先ホスト名が間違っていた、なんてこともあるあるです。
DNSサーバに登録するホスト名が間違っていた、そんなこともあると思います。
終わりに
トラブルシュートはシステムの全体像がわかっていることで問題解決にかかる時間を大幅に短縮することができます。
でもいざトラブルシュートするという時に一から把握はできないですよね。
普段からシステム全体を把握するようにしていると困った時に役に立ちます。
どうやってシステム全体を把握するのか、という疑問にはまた別の記事でお答えしていきますね！
