【実務・中級編】 pingコマンドの基本仕様とICMP Echo Request/Replyパケットの構造 – トラブルシューティング＆ネットワーク運用監視実践ガイド

なぜ「pingが通らない」と焦るのか？—熟練エンジニアが紐解くICMPの真実

深夜3時、アラートメールが鳴り響く。監視システムが「Host Unreachable」を叫んでいる。そんな時、君たちが最初に叩くコマンドは何だ？間違いなく ping だろう。

しかし、ただ漫然と ping を打って「応答なし」を見て絶望するだけでは、ただのオペレーターだ。ネットワークの深淵を覗くエンジニアなら、その裏で何が起きているのか、パケットがどこで息絶えたのかを、頭の中でパケットキャプチャしてイメージしなければならない。

今日は、ネットワーク運用における「最後の砦」であり、同時に「最も誤解されやすい」プロトコル、ICMP（Internet Control Message Protocol）の深淵に迫ろう。

—

1. ICMPは「IPの影の軍隊」である

よく勘違いされるが、ICMPはOSI参照モデルの第3層（ネットワーク層）に位置するプロトコルだ。TCPやUDPのようなポート番号という概念を持たない。IPヘッダーの中に、プロトコル番号「1」として格納される。

ping の正体は、RFC 792で定義された Echo Request（タイプ8）と Echo Reply（タイプ0）のやり取りに過ぎない。この非常にシンプルな仕組みが、なぜこれほどまでに強力なのか。それは、IPネットワークの「ヘルスチェック」を、通信のアプリケーション層に依存せずに行えるからだ。

パケット構造のリアル

Echo Request パケットを解体すると、こうなっている。

IPヘッダー: 送信元と宛先のIPアドレス。
ICMPタイプ: 「8」が入る。これが「おい、生きてるか？」という合図だ。
コード: 通常は「0」。
チェックサム: パケットの破損を検知する。
識別子とシーケンス番号: ping コマンドを複数実行した際、どの応答がどのリクエストに対するものかを判断するためのタグだ。

ここを見れば分かる通り、ICMPには「接続状態を維持する」ためのセッション管理がない。だからこそ、ファイアウォールの設定一つで容易に遮断されるし、逆にいえば、疎通確認が取れないときに「ICMPが許可されているか」を疑うのは、トラブルシューティングのイロハの「イ」なのだ。

—

2. 実務で差がつくコマンドパラメーター

単に ping 8.8.8.8 と打つだけでは、現場の障害調査は終わらない。特にクラウド環境やVPN越しの通信では、以下のオプションが命を救う。

# -c: 回数を指定（デフォルトは無限なので必ず指定する習慣を）
# -i: インターバル（デフォルトは1秒だが、監視時は短くすることもある）
# -s: パケットサイズ（MTUの境界値を探る際に必須）
# -W: タイムアウト秒数（遅延の激しい環境でレスポンスを待つ）

ping -c 4 -s 1472 -W 2 192.168.1.1

シニアからの教訓: MTU（最大転送単位）を意識せよ。もし ping が小さいサイズでは通るのに、大きいサイズだと通らないなら、経路上のどこかのルーターでパケットがフラグメント（断片化）しようとして失敗しているか、DF（Don’t Fragment）ビットが立っている可能性がある。これはVPNのオーバーヘッドを見落とした際に発生する典型的なトラブルだ。

—

3. コードで再現する「ヘルスチェック」の作法

Web APIの監視などで「疎通確認」をコードに落とし込む場合、ping を叩く代わりに socket を使うのが一般的だが、あえてPythonでICMPの挙動を理解するための最小構成を示す。

import socket
import struct
import time

# ICMPパケットのヘッダーを作成する関数（簡易版）
def create_packet(id):
    # タイプ8(Echo Request), コード0, チェックサム0
    header = struct.pack("!BBHHH", 8, 0, 0, id, 1)
    data = b"abcdefghijklmnopqrstuvwabcdefghi" # 32バイトのペイロード
    # 本来はここでチェックサムを計算する必要がある
    return header + data

# 実際の運用ではライブラリを使うのが賢い選択
# ただし、raw socketの概念を理解しておくことは、
# セキュリティエンジニアとしての必須教養だ。

Webサービス運用の現場では、単純なICMP疎通だけでなく、curl を用いた「アプリケーション層の疎通」もセットで考える必要がある。

# ICMPは通るが、HTTPポートが閉じているケースは山ほどある
curl -Iv https://api.example.com/health

—

4. トラブルシューティングの極意：何を見るべきか

最後に、トラブルシューティング時の心構えを伝授しよう。

1. 「pingが通る」＝「通信が正常」ではない:
ICMPは優先度が下げられることも多い。pingが通らなくてもTCP通信ができることはあるし、その逆もある。
2. 往復時間（RTT）の変動を見ろ:
急なパケットロスやレイテンシの揺らぎ（ジッター）は、物理層のケーブル劣化や、ルーターのCPU負荷増大の予兆だ。
3. tracerouteとセットで:
ping がどこで消えたのかを特定するには、traceroute（Windowsなら tracert）で経路を追跡し、どのホップでタイムアウトするかを確認する。

現場で「pingが通らない」と報告が上がったら、まずは「物理的な断線か？」「ファイアウォールのポリシーか？」「そもそも宛先サーバーのOSがICMPをドロップしているのか？」を冷静に切り分けろ。

ネットワークは生き物だ。コマンドの先に、必ず誰かの書いた設定ファイルと、物理的なサーバーが存在している。その「実体」を想像できるようになれば、君も一人前のエンジニアだ。

さあ、次のアラートが鳴った時、君が冷静に tcpdump を叩けることを期待している。