こんにちは！NOC（ネットワークオペレーションセンター）で日々、モニターの向こう側で暴れ狂うパケットたちとなだめすかしながら格闘しているシニアエンジニアです。
皆さんは、ネットワークの調子が悪いときに一番最初に何をしますか？ そう、おそらくほとんどの人が ping コマンドを叩くはずです。「おーい、そこにいるかー？」と宛先に声をかけ、「おう、いるぞ！」と返事が返ってくるかを確認する、ネットワーク診断の基本中の基本ですよね。
でも、その ping の裏側で、一体どんなやり取りが行われているか気になったことはありませんか？ 「パケットが飛んでいっている」と言われても、目に見えないからピンと来ないですよね。
今回は、そんな ping の主役である ICMPエコー要求（タイプ8） と ICMPエコー応答（タイプ0） の世界へ、皆さんと一緒に出発したいと思います。難しいビット数や英単語の羅列はできるだけ置いておいて、身近な例えを交えながら一歩ずつ紐解いていきましょう！
—
1. 郵便配達で例える ping の世界
ネットワークの世界を覗くとき、一番分かりやすいのは「手紙のやり取り（郵便配達）」です。
あなたが遠くに住む友人に手紙を出したいとします。そのとき、あなたは何をしますか？
1. 便箋にメッセージを書く（「元気？」）
2. 封筒に友人の住所と、自分の住所（返送先）を書く
3. 切手を貼ってポストに投函する
ネットワークの世界でも全く同じことが起きています。あなたが叩く ping 8.8.8.8 というコマンドは、まさに「手紙を出して生存確認をする」というアクションなんです。
ここで登場するのが、今回の主役である ICMP（Internet Control Message Protocol） という郵便屋さんのようなプロトコルです。ICMPの中にもいくつか「手紙の種類」があり、その番号（タイプ）によって用途が決まっています。
- タイプ 8（Echo Request）： 友人に宛てた「元気ですか？」というエコー要求の手紙。
- タイプ 0（Echo Reply）： それを受け取った友人があなたに送る「こっちは元気だよ！」というエコー応答の手紙。
ネットワークエンジニアの私たちは、ルーターやPCの画面越しに、この手紙がちゃんと相手に届いて返ってきているかを日々監視しているわけですね。
—
2. ICMPパケットの中身を覗いてみよう
「パケット」なんて聞くと難しそうに聞こえますが、要するにデジタルな封筒のことです。ICMPの封筒（ヘッダー）の中には、郵便局員（ルーターやOS）が仕分けをするための大切な情報がいくつか詰まっています。
初心者の方がまず押さえておきたい大切な項目は、次の3つです。
1. タイプ（Type）： 手紙の種類を表す番号です。ここが 8 なら要求、0 なら応答になります。
2. コード（Code）： タイプの中の「詳細な状態」を表します。例えば、普通の正常なエコー要求・応答であれば、このコードは必ず 0（親愛なる友よ、異常なし）になります。
3. チェックサム（Checksum）： 手紙が途中で破れたり、インクがにじんで文字が読めなくなったりしていないかをチェックするための「算術の答え」です。
チェックサムってなに？（どうやって検証するの？）
「チェックサム」という言葉、響きが少し難しそうですよね。でも、これも身近な例えで一瞬で理解できます。
例えば、あなたが数字の「1234」というメモを子供に渡して、「この数字の合計（1+2+3+4 = 10）も一緒に書いておいてね」と頼んだとします。子供がメモを運んでいる途中で、風に飛ばされて「1235」に変わってしまったとしましょう。
受け取った人が計算し直すと「1+2+3+5 = 11」になります。あれ？ 同封されていた合計は「10」なのに、計算すると「11」になるぞ……。「おや、途中で数字が書き換わったな（エラーだ！）」と気づくことができますよね。
ICMPのチェックサムもこれと全く同じです。
送信側のPCがパケットの中身を計算して「チェックサムはこれだよ」と封筒に書き込み、受信側のPCは届いたパケットをもう一度自分で計算します。計算結果が封筒の値と一致すれば「よし、途中で誰も手紙を書き換えていないな（データが壊れていないな）」と安心して処理を進めることができるのです。
—
3. 実践！CLIでパケットの往復を観察してみよう
百聞は一見にしかず。実際に私たちのパソコンからどんなやり取りが行われているか、シンプルなコマンドを使って確認してみましょう。
皆さんのパソコン（Windowsならコマンドプロンプト、MacやLinuxならターミナル）を開いて、以下のコマンドを打ってみてください。
# GoogleのパブリックDNSサーバーに対して、パケットを3回だけ送信してみる
# (-c 3 は送信回数を3回に制限するオプションです ※Windowsの場合は -n 3 になります)
ping -c 3 8.8.8.8実行すると、次のような結果が返ってくるはずです。
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=11.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=11.8 ms
--- 8.8.8.8 ping statistics ---
3回送信、3回受信、パケットロス0%この画面に表示されている icmp_seq=1 というのは、「エコー要求のシーケンス番号（何通目の手紙か）」を表しています。そして time=12.4 ms は、手紙を出してから返事が返ってくるまでの往復時間（ミリ秒）です。
ネットワークアナライザー（Wireshark）で中身を覗く
もし、さらに深くパケットの挙動を観察したい場合は、パケットキャプチャツールである Wireshark を使ってみるのが一番の近道です。
Wiresharkを起動して ping を実行し、フィルターに icmp と入力してみてください。すると、次のような美しい（？）パケットの対話がリアルタイムで表示されます。
1. No.1 (タイプ 8): あなたのPC $\rightarrow$ 8.8.8.8 「おーい！（Echo (ping) request）」
2. No.2 (タイプ 0): 8.8.8.8 $\rightarrow$ あなたのPC 「おっす、元気だよ！（Echo (ping) reply）」
ここでパケットの詳細を展開してみると、ちゃんと Type: 8 (Echo (ping) request) や Checksum: 0x... [correct] といった文字を確認できます。もし実務で「あれ、パケットが片方向しか流れていないぞ？」というときは、このTypeの数字やチェックサムのエラーを見ることで、ファイアウォールがブロックしているのか、経路のどこかでデータが壊れているのかを鋭く切り分けることができるのです。
—
4. 現場のシニアエンジニアからのアドバイス
最後に、インフラの現場で私たちがいつも気をつけているポイントを少しだけシェアさせてください。
ping は非常にシンプルで強力なツールですが、すべてのネットワーク機器が親切にタイプ0の返事を返してくれるとは限りません。セキュリティ上の理由（DDoS攻撃や不要なスキャンを防ぐため）あえてICMPのエコー要求を無視（ドロップ）するように設定されているサーバーやルーターもたくさん世の中には存在します。
「あれ？ ping が通らないからこのサーバーは落ちているんだ！」と早合点して現場に駆けつけたら、単にファイアウォールでICMPが弾かれていただけだった……なんていうのは、新米エンジニアが通る懐かしい登竜門の一つです（私も昔、やらかしたことがあります笑）。
だからこそ、パケットが「なぜタイプ8を送り、なぜタイプ0を返すのか」という根本的な仕組み（プロトコルの作法）を理解しておくことが、いざという時の冷静なトラブルシューティングに繋がるのです。
一歩ずつ、焦らず、目の前のパケットと仲良くなっていきましょうね。それでは、また次回のNOCブログでお会いしましょう！
コメント