【入門編】 pingコマンドの基本動作とICMP Echo Request/Replyメッセージフォーマット – トラブルシューティング＆ネットワーク運用監視実践ガイド

「pingが返ってこない！」と焦る前に。ICMPの仕組みを“郵便配達”で完全攻略しよう

ネットワークエンジニアの仕事をしていると、深夜2時に呼び出されるようなトラブルの9割は「あれ、繋がらない！」という悲鳴から始まります。そんな時、皆さんがまず最初に叩くコマンドが ping ですよね。

でも、ちょっと待ってください。「なんとなく打っているそのコマンド、裏側で何が起きているか説明できますか？」

今日は、インフラ初心者の皆さんが避けて通れない、だけど意外と深掘りされていない「ICMP（Internet Control Message Protocol）」の正体について、現場の泥臭い経験を交えながら、優しく紐解いていきましょう。

—

ping の仕組みを理解する一番の近道は、「手紙のやり取り」に例えることです。

あなたが誰かに手紙を送る時、届いたかどうか不安になりますよね？そこで「届いたら必ず返事をください」という付箋を貼って出す。これが ping の正体です。

このやり取りがネットワーク上で一瞬のうちに行われています。この時、IPアドレスという「住所」を指定して送るわけですが、このやり取りの裏側には、実はもっと細かい「管理番号」が書き込まれているんです。

—

ICMPのパケット構造は、専門書だとビット単位の羅列で頭が痛くなりますが、封筒の中身だと思えばシンプルです。

「これはどの手紙の返事かな？」を区別するための番号です。例えば、あなたのPCで複数の ping を同時に実行しても、どのウィンドウに対する返事なのかを間違えないようにするための「整理番号」です。

これは「順番」です。1通目、2通目、3通目……と番号を振ることで、「あ、3通目が抜けてるから途中でパケットが消えたな（パケットロス）」ということが判断できるわけです。

—

教科書通りの ping 8.8.8.8 だけでは、現場では物足りないことが多々あります。状況に合わせてオプションを使い分けましょう。

サーバーを再起動している最中など、「復帰したら即座に知りたい！」という時は -t オプションが便利です。

# 8.8.8.8に対してCtrl+Cを押すまでpingを打ち続けます
ping 8.8.8.8 -t

MTU（最大転送単位）サイズが原因でパケットが断片化し、通信が不安定になるトラブルがあります。そんな時はパケットの大きさを変えてテストします。

# 1472バイトのペイロードを送って確認（ヘッダー分を足すと1500バイトになる）
ping -s 1472 192.168.1.1

—

ここで、新人の頃に必ずぶつかる壁があります。「pingが通らないから回線断だ！」と大騒ぎして駆けつけたら、実はただのファイアウォール設定だった、というケースです。

最近のセキュリティ機器やOSのデフォルト設定では、「悪意のある攻撃を避けるために、あえてping（ICMP）には返事をしない」という設定が一般的です。

現場の知恵: ping が通らない時は、まず「相手が意図的にICMPを拒否していないか？」を疑いましょう。その場合は telnet や nc (netcat) コマンドを使って、特定のポート（例えばWebサーバーなら80番や443番）に対して直接通信を試みるのが定石です。

# 80番ポートが空いているか確認する（pingがダメでもこれが通れば生きている！）
nc -zv 192.168.1.1 80

—

ネットワークトラブルの現場では、コマンドの結果は単なる文字列ではなく、「パケットがどこで息絶えたのか」という物語として見えてくるようになります。

ping は最もシンプルで、最もパワフルな診断ツールです。まずは今日、自宅のルーターや、いつも使っているWebサイトに対して ping を打ってみてください。「今、自分のパケットが光の速さで往復してきているんだな」とイメージするだけで、トラブルシューティングの第一歩は完璧ですよ！

もし ping の結果で「Request timed out」や「Destination Host Unreachable」と出たら、それはネットワークがあなたに「ここが怪しいよ！」とヒントをくれている証拠です。怖がらず、一歩ずつ追いかけていきましょうね。

それでは、また次回の現場でお会いしましょう！