こんにちは。今日もパケットを追いかけていますか？ 現場で数々の泥臭いトラブルを解決してきたシニアネットワークエンジニアの「現場親父」です。
モダンなWebアプリケーションを開発していると、どうしても「HTTP/3」や「gRPC」、「Websocket」といったレイヤー7（アプリケーション層）の華やかな技術に目を奪われがちです。しかし、どれほど洗練されたAPIを設計しようとも、それらのデータは最終的に、数十年変わらない愚直な「IPパケット」という箱に詰め込まれ、物理的な光ファイバーや銅線、あるいは仮想ネットワークの荒波を越えて運ばれます。
今回は、インフラ運用やWeb API設計で「なぜか通信が届かない」「セキュリティグループの設定は合っているはずなのに」と頭を抱えている若手エンジニアのために、すべてのIP通信のナビゲーターである「IPヘッダー内のプロトコル番号（Protocol Number）」にスポットライトを当てます。
OSのカーネルが、毎秒数万、数十万と届くパケットをどのようにして「これはTCPだ」「これはUDPだ」と瞬時に見極め、適切なソケットへと仕分けしているのか。その深遠なる仕組みと、実務に効くデバッグ手法を伝授しましょう。
—
1. OSI参照モデルとTCP/IPモデルにおける「仕分け」の全体像
私たちが普段何気なく使っているネットワークは、厳密な「階層化」によって成り立っています。
まずは、OSI参照モデルとTCP/IPモデルの対応関係、そしてそれぞれのレイヤーで動作するプロトコルが「どのアドレス（識別子）」を使って次の階層へバトンを渡しているのかを整理しておきましょう。
| OSI参照モデル | TCP/IPモデル | 階層で使われる主なプロトコル | 上位層を識別するためのキー（識別子） |
| :— | :— | :— | :— |
| 第4層: トランスポート層 | トランスポート層 | TCP, UDP, SCTP | ポート番号 (Port Number) ※L7のアプリケーションを識別 |
| 第3層: ネットワーク層 | インターネット層 | IPv4, IPv6, ICMP, IPsec (ESP/AH) | プロトコル番号 (Protocol Number) ※L4のプロトコルを識別 |
| 第2層: データリンク層 | ネットワークアクセス層 | Ethernet, Wi-Fi, PPP | イーサタイプ (EtherType) ※L3のプロトコル（IPv4/IPv6等）を識別 |
データが送信されるとき（カプセル化）、上位のデータは下位のヘッダーで包まれます。逆に受信するとき（非カプセル化）は、下位のレイヤーから順に「皮」を剥いていくことになります。
ここで重要なのは、「自分より1つ上のレイヤーに何が格納されているか」を、ヘッダーの中に明記しておかなければ、受け取った側は次にどのプロトコルスタック（処理プログラム）にデータを渡せばいいのか分からないという点です。
—
2. IPヘッダー：プロトコル番号（Protocol Field）の正体
IPv4ヘッダーの「9バイト目」に位置する、わずか8ビット（0〜255）のフィールド。それが「プロトコル番号（Protocol Field）」です。
※なお、IPv6においては、同様の役割を果たすフィールドが 「ネクストヘッダー（Next Header）」 という名前で定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum | <--- ココ！(8bit)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+この8ビットの数値は、IANA（Internet Assigned Numbers Authority）によって厳格に管理されています。実務で遭遇する代表的なプロトコル番号を以下に示します。
1: ICMP (Internet Control Message Protocol)pingコマンドや、ネットワークの経路探索（traceroute）、エラー通知（Destination Unreachableなど）で使われます。L4のTCPやUDPは介さず、IPヘッダーの直後にICMPデータが載ります。6: TCP (Transmission Control Protocol)- HTTP/1.1、HTTP/2、SSH、database接続など、信頼性の高い通信の代名詞。
17: UDP (User Datagram Protocol)- DNSクエリ、NTP時刻同期、そしてHTTP/3（QUIC）などで使われる、高速・軽量なプロトコル。
50: ESP (Encapsulating Security Payload)- IPsec VPNなどで、パケットの暗号化や認証を行うために使われます。
115: L2TP (Layer Two Tunneling Protocol)- VPNのトンネリング技術で利用されます。
—
3. OSカーネル内部で行われる「仕分け（デマルチプレクシング）」のリアル
ネットワークカード（NIC）にパケットが着信してから、皆さんが書いたWebアプリケーション（PythonやNode.js、Goなど）にデータが届くまでの、OS内部の息を呑むような連携劇を見てみましょう。
+--------------------------------------------------------------------------------+
| [物理層/データリンク層] |
| NICがパケット受信 -> イーサネットヘッダーを解析 |
| |-- EtherType が "0x0800" (IPv4) であることを確認 |
+--------------------------------------------------------------------------------+
|
v (カーネルのIPスタックへ)
+--------------------------------------------------------------------------------+
| [ネットワーク層 (IP)] |
| IPヘッダーを解析 (チェックサム検証、宛先IPの確認) |
| |-- Protocol番号を確認: "6" (TCP) か "17" (UDP) か？ |
| |-- "6" の場合 -> カーネル内の tcp_v4_rcv() 関数へディパッチ |
| |-- "17" の場合 -> カーネル内の udp_rcv() 関数へディパッチ |
+--------------------------------------------------------------------------------+
|
v (トランスポート層スタックへ)
+--------------------------------------------------------------------------------+
| [トランスポート層 (TCP/UDP)] |
| L4ヘッダー（TCP/UDPヘッダー）を解析 |
| |-- 宛先ポート番号 (例: 443) を確認 |
| |-- ソケットテーブルから、該当ポートを Listen しているプロセス（PID）を特定 |
+--------------------------------------------------------------------------------+
|
v (アプリケーション層へ)
+--------------------------------------------------------------------------------+
| [アプリケーション層] |
| アプリケーションが `read()` または `recv()` システムコールでデータを受信 |
+--------------------------------------------------------------------------------+LinuxカーネルのC言語ソースコードを覗くと、この「仕分け」はハッシュテーブルや配列によって驚異的な速度で処理されています。
例えば、IPスタック（ip_rcv）は、登録されたプロトコルハンドラーの配列（inet_protos）から、IPヘッダーの protocol フィールドの値をインデックスとしてハンドラー（struct net_protocol）を引き当て、その受信関数（TCPなら tcp_v4_rcv）を呼び出します。
この仕組みがあるからこそ、OSは数ギガビットものトラフィックを、CPUを破綻させることなく処理できるのです。
—
4. 実務で直面する「プロトコル番号」が原因のトラブル
「Webエンジニアにプロトコル番号の知識なんて必要ある？」と思うかもしれません。しかし、クラウドインフラ（AWS、Azure、GCPなど）やオンプレミスのファイアウォール（Palo Alto、Fortinetなど）を運用する際、この知識がないと「一見完璧に見える設定なのに通信が通らない」という迷宮に迷い込むことになります。
よくあるトラブル例：IPsec VPNが繋がらない
オンプレミスとAWSをIPsec（VPN）で繋ぐ際、多くのエンジニアが「UDP 500番（IKE）とUDP 4500番（NAT-T）を開放した」ことで満足してしまいます。
しかし、いざVPNコネクションを確立しようとすると、フェーズ2のトンネル構築で通信が途絶します。
- 原因: 暗号化された実データが流れる ESP（プロトコル番号 50） の通過を、ファイアウォールやセキュリティグループで許可していなかったため。
- 教訓: 「ポート番号（L4）」だけではなく、「プロトコル（L3）」レベルでの制御が必要なケースが存在する。
—
5. 実践：デバッグとパケット検証の手法
現場のエンジニアたるもの、トラブル時にはツールを駆使して「パケットの真実」を暴く必要があります。ここでは、具体的な検証コマンドとPythonを用いたデバッグコードを紹介します。
① tcpdump によるIPプロトコル番号の抽出とキャプチャ
Linuxサーバー上で、特定のIPプロトコル番号のパケットだけをフィルタリングしてキャプチャしたい場合があります。
例えば、ICMP（プロトコル番号 1） のパケットだけをキャプチャする場合：
# インターフェース eth0 で、IPプロトコル番号 1 (ICMP) のパケットをキャプチャ
sudo tcpdump -i eth0 -nn proto 1TCP（プロトコル番号 6） のパケットだけをキャプチャする場合：
# "proto 6" は "tcp" と書いても同じですが、プロトコル番号を直接指定することで
# 特殊なプロトコルもピンポイントで指定できます
sudo tcpdump -i eth0 -nn proto 6② Python (Scapy) を使ったプロトコル番号の操作とパケットの自作
ネットワークの疎通確認や、ファイアウォールが特定のプロトコルをフィルタリングしているかをテストするために、Pythonの強力なパケット操作ライブラリである Scapy を使って、パケットを自作・送信してみましょう。
まずはライブラリのインストールです。
pip install scapy以下は、IPヘッダーの「プロトコル番号」を明示的に指定して、カスタムパケットを組み立てて送信するデバッグスクリプトです。
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
from scapy.all import IP, UDP, Raw, send
import sys
def send_custom_protocol_packet(target_ip):
print(f"[*] 宛先 {target_ip} へカスタムパケットの送信を試みます...")
# IPヘッダーを作成
# 'proto' 引数にプロトコル番号を指定します。
# 通常、UDPは 17 ですが、ここではファイアウォールの挙動テストなどのために
# 明示的に指定してパケットを組み立てます。
ip_header = IP(
dst=target_ip,
ttl=64,
proto=17 # 17 = UDP。ここを 6 にすればTCP（ただしL4ヘッダーもTCPにする必要あり）
)
# UDPヘッダーを作成 (送信元ポート: 50000, 宛先ポート: 8080)
udp_header = UDP(
sport=50000,
dport=8080
)
# ペイロード（データ）を定義
payload = Raw(load="Hello, Network Warrior!")
# レイヤーを重ねてパケットを組み立てる (L3 / L4 / Data)
packet = ip_header / udp_header / payload
# パケットの詳細をコンソールに表示
packet.show()
# パケットを送信 (L3パケットなので send() を使用)
try:
send(packet, verbose=True)
print("[+] パケットの送信に成功しました。")
except PermissionError:
print("[-] エラー: 生パケットの送信には管理者権限（sudo）が必要です。", file=sys.stderr)
if __name__ == "__main__":
# テスト対象のIPアドレス（適切なデバッグ用IPに変更してください）
target = "192.168.1.100"
send_custom_protocol_packet(target)このスクリプトを実行すると、カーネルの標準的なソケットAPIをバイパスし、L3（IPヘッダー）の各フィールドを直接制御してNICから送出できます。プロトコル番号を変更したときに、途中のルーターやファイアウォールでどのようにパケットがドロップされるかを検証するのに非常に強力なツールとなります。
—
6. まとめ：パケットの「目」を持つエンジニアになろう
現代のアプリケーション開発は、クラウドプロバイダーが提供するロードバランサーや、Kubernetesなどの高度な抽象化レイヤーの上で行われています。そのため、IPヘッダーの1バイトの数値にまで気を配る機会は激減しました。
しかし、システムが原因不明のパフォーマンス低下に陥ったとき、あるいはゼロトラストネットワークの設計でセグメンテーション（境界防御）を行うとき、「今、ネットワーク上を流れているパケットのヘッダーで何が起きているか」を脳内でビジュアライズできるエンジニアは圧倒的に強いです。
- EtherType がL3のプロトコル（IPv4/IPv6）を決める。
- IPプロトコル番号 がL4のプロトコル（TCP/UDP/ICMP/ESP）を決める。
- ポート番号 がアプリケーション（ソケット）を決める。
この「バトンリレー」の原則を常に胸に刻んでおいてください。次に「通信が繋がらない」という障害報告のチケットがあなたの手元に届いたとき、この知識が必ずやあなたの強力な武器になるはずです。
それでは、素晴らしいパケットの旅を！
コメント