【実務・中級編】 ARP要求(Request)と応答(Reply)のパケット構造 – ネットワーク基礎とWebセキュリティ実践ガイド

なぜ「宛先不明」で通信が消えるのか？ARPという名の「住所録」を徹底解剖する

ネットワークエンジニアとして現場を渡り歩いていると、若手から「Web APIを叩いているのに、なぜかパケットがL2スイッチで止まるんです」という相談をよく受けます。

多くのエンジニアは curl や Fetch API でリクエストを送る際、上位層である HTTP や TCP のコネクション確立に意識を奪われがちです。しかし、実はその遥か足元で、無数の ARP（Address Resolution Protocol）パケットが必死に「MACアドレス」という名前の住所を問い合わせているのです。

今日は、教科書的な説明を飛び越えて、パケットの裏側で何が起きているのか、泥臭いトラブルシューティングの観点から解説します。

—

ARPは「名前」を「物理住所」に変える魔法

OSI参照モデルにおいて、IPアドレスは論理的な住所ですが、実際にLANケーブルの上を流れるのは「イーサネットフレーム」であり、そこには MACアドレス が必要です。PCやサーバーが「あのIPアドレスの奴は、どの物理ポートに繋がっているんだ？」と叫ぶとき、その喉元から飛び出すのが ARP Request です。

ARPヘッダーの「勘所」

ARP のパケット構造を覗くと、無機質なフィールドが並んでいますが、実務で注目すべきは以下の4点です。

Hardware Type (2オクテット): 通常 1 (Ethernet)。
Protocol Type (2オクテット): 0x0800 (IPv4)。ここがズレるとそもそも通信になりません。
Opcode (2オクテット): ここが重要です。1 なら「教えてくれ（Request）」、2 なら「俺がそのIPだ（Reply）」。
Sender/Target MAC & IP: 送信元とターゲットの住所録。

実務上、パケットキャプチャ（tcpdump や Wireshark）を眺めているとき、この Opcode が 1 なのに Reply が返ってこない、あるいは Reply が別のIPから飛んできている（ARPスプーフィングの兆候）といった異常検知を行うのが、熟練の腕の見せ所です。

—

ARP解決のシーケンス：通信の舞台裏

例えば、192.168.1.10 のクライアントが 192.168.1.1 のルーターに HTTP GET リクエストを送る際、内部では以下のドラマが展開されています。

1. ARP Request: 「192.168.1.1 のMACアドレスを知っているか？俺は 192.168.1.10 (AA:BB:CC:DD:EE:FF) だ」と、ブロードキャスト（FF:FF:FF:FF:FF:FF）で叫びます。
2. ARP Reply: 192.168.1.1 が「俺だ（11:22:33:44:55:66）。お前の要求は受け取った」とユニキャストで返します。

このやり取りが完了して初めて、OSの ARPキャッシュ にMACアドレスが登録され、TCPの3ウェイハンドシェイクが開始されます。Web APIのレイテンシが異常に高い場合、この ARP 解決に時間がかかっている（またはルーターが応答をドロップしている）可能性を疑うべきです。

—

実践：ARPをデバッグ・操作するTips

現場で「疎通は取れるはずなのに通信できない」という状況に陥ったとき、皆さんはどうしますか？私はまず、このコマンドでキャッシュの状態を確認します。

1. ARPキャッシュを確認する (Linux/macOS)

# 現在のOSが把握しているARPテーブルを確認
arp -an

# 特定のインターフェースを指定して確認（インフラ構築の必需品）
ip neighbor show dev eth0

2. PythonでARPパケットを模倣する（攻撃調査・テスト用）

セキュリティの検証や、特殊なネットワーク環境のテストで、Scapy を使ってARPを自作するのは非常に有効です。

from scapy.all import Ether, ARP, sendp

# ARP Requestを作成する
# 宛先MACをブロードキャスト、ターゲットIPをルーターに指定
packet = Ether(dst="ff:ff:ff:ff:ff:ff") / ARP(pdst="192.168.1.1")

# インターフェースを指定して送信
sendp(packet, iface="eth0")

※悪用厳禁です。あくまで自身の管理下のネットワークで、トラブルシューティングのために利用してください。

—

エンジニアへのアドバイス：境界防御の視点から

ゼロトラストアーキテクチャを語る上で、この ARP の挙動を軽視してはいけません。社内ネットワークのLANセグメントにおいて、ARPは非常に無防備なプロトコルです。誰かが悪意を持って Gratuitous ARP（自称・なりすましARP）を流せば、中間者攻撃が成立してしまいます。

L2スイッチの設定: Dynamic ARP Inspection (DAI) を有効にして、不正なARPパケットを遮断する設定は、エンタープライズの現場では必須です。
Web API開発の視点: APIが「繋がらない」と文句を言う前に、ネットワーク層で ARP が正常に解決されているか、tcpdump で確認する癖をつけてください。

# 特定のホストへのARP要求だけをフィルタリングして追跡
sudo tcpdump -i eth0 arp or icmp

ネットワークは嘘をつきません。パケットの挙動を理解すれば、どんな複雑なインフラのトラブルも、「どこで住所が辿れなくなったのか」というシンプルな問いに帰結します。

今日の学びが、皆さんの次なる運用・開発の一助となれば幸いです。また現場でお会いしましょう。