なぜ「宛先不明」で通信が消えるのか？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 eth02. 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ネットワークは嘘をつきません。パケットの挙動を理解すれば、どんな複雑なインフラのトラブルも、「どこで住所が辿れなくなったのか」というシンプルな問いに帰結します。
今日の学びが、皆さんの次なる運用・開発の一助となれば幸いです。また現場でお会いしましょう。
コメント