以前、新卒入社２年目のエンジニアに
「pingが通るか確認お願い！」と依頼したことがありました。
しかし、その当時、彼はpingを使ったことがなく知らなかったということがありました。
体系立った教育をしてなかったと反省しました。
そんな経験からpingコマンドを説明する記事を用意しておきたいと思いました。
ついでにtracertコマンドも学びましょう！
勤怠の打刻ができない！
その頃、社内で利用していた勤怠管理アプリは、
ハードウェアをオフィスの入口に設置して利用するタイプのものでした。
社員は出社時にカードをかざして打刻し、その情報が社内ネットワークを通じて勤怠管理サーバに送られる仕組みです。
ある朝、数名の社員から「打刻できない」という報告が立て続けに入りました。
「アプリが落ちてる？」「サーバが止まった？」とざわつく中、ネットワークの疎通確認から調査を始めることにしました。
Step 1：まずはpingで生きているか確認
最初に確認したのは、勤怠管理サーバ（192.168.10.20）にpingが通るかどうか。
ping 192.168.10.20
結果は…
Request timed out.
Request timed out.
あれ、応答がない。
でも、ここで慌てて「サーバが死んでる！」と決めつけるのは早いです。
pingが通らない理由は、以下のようにいくつかあります：
- サーバが本当に落ちている
- ネットワーク経路の途中で止まっている
- ファイアウォールでICMP（ping）が遮断されている
Step 2：tracertでどこまで届いてるかを確認
次に使ったのが tracert（Windowsの場合）です。
これは、目的地までの経路を一段ずつ調べてくれるコマンド。
※Linuxの場合、tracerouteコマンドがあります。
tracert 192.168.10.20
結果はこんな感じ：
1 <社内ルーター> 192.168.10.1
2 <？？？> 要求がタイムアウトしました。
ルーターまでは届いてるけど、その先で止まってる。
この情報から「ルーター以降のネットワークに問題があるかも」と仮説を立てられます。
Step 3：仮説と対処
このときは、以下のような対応を順に試しました：
- 勤怠管理サーバの電源とLANケーブルを確認 ⇒ 問題なし
- ルーターの再起動 ⇒ 効果なし
- サーバ側のファイアウォール設定を確認 ⇒ ICMPが遮断されていた！
つまり、pingが通らなかったのは「サーバが死んでいた」のではなく、
ファイアウォールでpingがブロックされていました。
さらに調査を進めたところ、ファイアウォールの設定ミスで、ICMPだけでなく他の通信も止められていたことが判明！
設定を直し、勤怠管理アプリは無事に復活しました！
pingとtracertの違いと使い分け
| コマンド | 目的 | 使いどころ |
|---|---|---|
ping |
相手が生きてるか確認 | 疎通確認、応答速度の測定 |
tracert |
経路のどこまで届いてるか確認 | 経路調査、途中の障害特定 |
どちらもICMPというプロトコルを使っていますが、
pingは「届いたかどうか」、tracertは「どこまで届いたか」を教えてくれます。
※Linuxには、tracerouteというコマンドがあります。
デフォルトでUDPパケットを使う等、Windowsのtracertとは仕様が異なります。
そのため、ファイアウォールの設定やネットワーク環境によって、両者の結果が異なる場合があります。
新人教育の反省と学び
pingとtracertはネットワークの聴診器のような存在。
pingコマンドすら知らないで、ネットワークトラブルに対するのは素手で立ち向かうようなもの。
使い方を知っているだけで、トラブル対応の初動がまったく変わります。
もちろん独学で習得されている人もいると思いますが、そのような知識があるか確認してもいいのかもしれないと思いました。
そうそう、「ping」の正しい読み方は「ピン」ですが、日本の開発現場では「ピング」と呼ばれることが多いと思います。
（僕自身「ピン」と言ったことがないです）
また、冒頭の「pingが通るか確認お願い！」みたいに、「通る」「通らない」みたいな表現をすることも多いと思います。
このようなことに言及してもいいかもしれませんね。
まとめ
- まずはpingで疎通確認
- 通らなければtracertで経路を調べる
- トラブルの原因は様々、決めつけない
- 新人教育では「pingって知っている？」から始めよう！
え？社内にサーバーがあるなら、まずサーバーを見にいきなさいよ？そんな野暮なツッコミは不要です。
なお、本記事はフィクションであり、実在する団体とは何も関係ありません。