【入門編】 IPヘッダー：プロトコル番号(Protocol Number)の定義と上位層の識別 – ネットワーク基礎とWebセキュリティ実践ガイド

こんにちは！ネットワークの裏側を覗き見るのが大好きな、技術メディアの主筆ライターです。

インフラの世界へ足を踏み入れたばかりの頃、「パケット」という目に見えないデータの塊が、世界中のコンピュータを行き交っていると言われても、なんだかピンとこないですよね。「一体どうやって、自分のPCに届いたデータが、Webブラウザのものなのか、それとも裏で動いているチャットアプリのものなのかを判別しているんだろう？」そんな疑問を抱いたことはありませんか？

今回は、ネットワークの基礎中の基礎でありながら、実はOSの心臓部でめちゃくちゃ重要な役割を果たしている「IPヘッダーのプロトコル番号」にスポットを当てて、一歩ずつ優しく紐解いていきたいと思います。

難しい専門用語に圧倒されそうになっても大丈夫。身近な例えを交えながらじっくり解説していきますので、コーヒーでも飲みながらリラックスして読み進めてくださいね！

—

1. 宛先は合っているのに…届いた手紙を「誰」に渡すべき？

ネットワークの世界を、よく「郵便配達」に例えることがありますよね。

私たちのパソコンには、現実世界の住所と同じように 192.168.1.10 のような「IPアドレス」が割り振られています。世界中から送られてきた手紙（パケット）は、このIPアドレスという宛先を頼りに、無事にあなたのパソコンの玄関口まで届きます。

ここで、ちょっと想像してみてください。
あなたの自宅のポストに、色々な種類の郵便物が届きました。

水道料金の請求書
友だちからの手紙
通販で買った分厚いダンボール箱

ポストからこれらを取り出したとき、お母さんやあなたが「これはリビングの机に置く」「これは私の部屋」「これはすぐに開封して仕分けする」と、中身の種類に合わせて適切な担当者や場所へ振り分けますよね。

もし、この仕分けルールがなかったらどうなるでしょう？大切な請求書を子供のおもちゃ箱に放り込んでしまったり、逆にラブレターをゴミ箱に直行させたりと、大混乱になってしまいます。

コンピュータの世界もこれと全く同じです。
ネットワークカードからOSの基本ソフト（カーネル）にパケットが到着したとき、OSは「このデータは、一体どのアプリ（プロトコル）に渡せばいいんだ？」という運命の分かれ道に直面します。

ここで華麗に登場するのが、今回主役となるIPヘッダーの中にある「プロトコル番号（Protocol Number）」という小さな目印なんです！

—

2. IPヘッダーの「プロトコル番号」ってなに？

パケットは、いくつかの「層（レイヤー）」の箱がマトリョーシカのように重なってできています。一番外側にあるのが、ネットワーク層の案内状である「IPヘッダー」です。

IPヘッダーの中には、差出人のIPアドレスや宛先のIPアドレスなど、迷子にならずに目的地へ届くための大切な情報がぎっしり詰まっています。その中の一角に、たった8ビット（0から255までの数字が入る小さなスペース）だけ割り当てられた、「次に来るデータの中身（上位層のプロトコル）はこれだよ！」と教えるための番号が存在します。これが「プロトコル番号」です。

OSのネットワークスタック（通信の処理係）は、パケットを受け取ると、まずこのIPヘッダーをペラっとめくり、「おっ、ここのプロトコル番号は 6 だな」と確認します。

そして、脳内でこう変換するのです。
「よし、番号が 6 だから、これはお馴染みの TCP だな！だったら、TCPの処理担当チームにこの荷物を丸ごと引き渡そう！」

—

3. 代表的なプロトコル番号の顔ぶれ

このプロトコル番号、実はインターネットの生みの親たちによって厳格にルール（IANAという組織の管理下）が決められています。普段私たちが何気なく使っている通信も、裏ではこの番号でしっかりと区別されているんです。

実務やトラブルシューティングでよく見かける代表的な番号をいくつか覗いてみましょう。

このように、たった一つの数字が、パケットを全く異なる性格の通信プログラムへと振り分けるための「運命の分水嶺」になっているんですね。

—

4. 現場の裏側：Wiresharkでプロトコル番号を覗き見してみよう！

百聞は一見にしかず。実際のネットワークの世界で、このプロトコル番号がどのようにやり取りされているのか、パケット解析ツール（Wiresharkなど）を使ったときの見え方をイメージしてみましょう。

パケットの内部構造をダンプすると、IPヘッダーの中に次のようなフィールドが存在します。

Internet Protocol Version 4, Src: 192.168.1.15, Dst: 93.184.216.34
    版本: 4
    Header Length: 20 bytes
    ...
    [中略]
    Time to Live: 64
    Protocol: TCP (6)  <--- ★ここがIPヘッダーのプロトコル番号！
    Header Checksum: 0x2a1b (validated)
    Source Address: 192.168.1.15
    Destination Address: 93.184.216.34

Wiresharkなどの優秀なツールは、親切に TCP (6) と人間が読みやすいように翻訳して表示してくれますが、実際の生データ（バイナリ）では、この部分は単に 0x06 という小さな1バイトのデータとして流れています。この1バイトを見るだけで、OSは瞬時に「次はTCPの処理だ！」と判断できるわけです。

—

5. 実務での応用：ファイヤーウォールやパケットフィルターでの活用

インフラエンジニアとして働いていると、このプロトコル番号の知識がそのままセキュリティ対策やトラブルシューティングに直結します。

例えば、Linuxの標準的なパケットフィルタリングツールである nftables や iptables、あるいは企業向けの次世代ファイアウォール（NGFW）を設定する際、「どの通信を許可し、どの通信をブロックするか」をこのプロトコル番号をベースに制御します。

以下に、Linuxのパケットフィルター設定（擬似的なイメージ）の例を見てみましょう。ここでは、TCP（Webなど）とUDP（DNSなど）を明示的に許可し、それ以外の不審なプロトコルを弾くようなイメージを持ってみてください。

# ==========================================
# Linuxファイアウォール設定のイメージ例
# ==========================================

# 1. 信頼された内部ネットワークからのTCP通信（Web等、プロトコル番号: 6）を許可する
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# 2. DNSの名前解決に必要なUDP通信（プロトコル番号: 17）を許可する
iptables -A INPUT -p udp --dport 53 -j ACCEPT

# 3. ネットワークの疎通確認に必要なICMP（プロトコル番号: 1）を許可する
iptables -A INPUT -p icmp -j ACCEPT

# 4. 上記以外の予期せぬプロトコルや怪しいパケットはすべて破棄（ドロップ）する
iptables -A INPUT -j DROP

※設定ファイル内で -p tcp や -p udp と指定していますが、内部的にはシステムが自動的にそれぞれ 6 や 17 というプロトコル番号に読み替えてカーネルに指示を出しています。

もし、このプロトコル番号の概念を知らなかったら、「なぜファイアウォールでTCPとUDPを個別に設定しなければならないのか」「そもそもネットワーク層とトランスポート層はどうやって連携しているのか」という疑問の霧が晴れず、セキュリティ設定もただの「おまじない」になってしまいますよね。

—

6. おわりに：一歩ずつ、確かな技術の土台を築こう

今回は、IPヘッダーの片隅で静かに、しかし絶大な影響力を持っている「プロトコル番号」について解説しました。

IPヘッダーのプロトコル番号は、届いたパケットを上位層（TCPやUDPなど）の誰に引き渡すかを決める「運命の仕分け人」
代表的なものとして、TCP（6）、UDP（17）、ICMP（1）などがある
この仕組みがあるおかげで、OSは多様なアプリケーションのデータを綺麗に交通整理できている
インフラのセキュリティ設定（ファイアウォール等）でも、この番号を意識した制御が基本になる

ネットワークの世界は、一見すると複雑で難解な暗号のよう思えるかもしれません。でも、一つひとつのフィールドが「なぜ存在しているのか」「現実世界のどんな仕組みを模しているのか」を紐解いていくと、実にシンプルで美しい論理で作られていることに気づかされます。

これからも、焦らず一歩ずつ、確かな技術の引き出しを増やしていきましょう！
あなたのインフラ・ネットワーク学習の旅を、これからも全力で応援しています。それではまた次回の記事でお会いしましょう！