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

ARPの深淵：IPとMACの境界線で何が起きているのか

ネットワークエンジニアとして数多くのインフラ設計やセキュリティインシデントの現場に立ち会ってきたが、いまだにエンジニアたちの間で誤解されがちなプロトコルがある。それが ARP（Address Resolution Protocol） だ。

「L2とL3の接着剤」「IPアドレスからMACアドレスを引く仕組み」――教科書的にはそれ以上でも以下でもない。しかし、ゼロトラストの思想が浸透し、コンテナオーケストレーションやSDN（Software-Defined Networking）が当たり前になった現代のエンタープライズ環境において、ARPの挙動をパケットレベルで把握していないエンジニアは、いざという時に深い泥沼にはまる。

今回は、ARPヘッダーの構造から、Linuxカーネル内部のキャッシュ機構、そしてARPスプーフィングといった古典的かつ現在進行形の脅威に対する防御策まで、プロトコルの核心を骨の髄まで解剖していこう。

—

1. パケット構造の解剖：ARPヘッダーの真実

まず、L2イーサネットフレームの中に包まれたARPパケットの素顔を見てみよう。Wiresharkを立ち上げ、ワイアーの向こう側を流れる生のバイナリを想像してほしい。

ARPは、OSI参照モデルの厳密な意味ではL2（データリンク層）とL3（ネットワーク層）の間に位置する、あるいはL2の枠内で動作する特異なプロトコルだ。イーサネットフレームのタイプフィールドに 0x0806 がセットされているパケットを見つけたら、それがARPの合図である。

ARPパケットの基本構造は以下のフィールドで構成されている。

  • ハードウェアタイプ (Hardware Type: HTYPE): 通常はイーサネットを示す 0x0001（2バイト）が入る。
  • プロトコルタイプ (Protocol Type: PTYPE): 上位層のプロトコルを指定する。IPv4であればインターネットプロトコルを示す 0x0800（2バイト）が格納される。
  • ハードウェアアドレス長 (Hardware Address Length: HLEN): MACアドレスの長さ。イーサネットなら 6 バイト。
  • プロトコルアドレス長 (Protocol Address Length: PLEN): IPアドレスの長さ。IPv4なら 4 バイト。
  • オペコード (Operation Code: OPER): ARPパケットの種別を定義する（2バイト）。
  • 1: ARPリクエスト（要求）
  • 2: ARPリプライ（応答）
  • （参考）RARP等では 3 や 4 も存在するが、現代ではほぼ使われない。
  • 送信元ハードウェアアドレス (Sender Hardware Address: SHA): 送信者のMACアドレス。
  • 送信元プロトコルアドレス (Sender Protocol Address: SPA): 送信者のIPアドレス。
  • 対象ハードウェアアドレス (Target Hardware Address: THA): リクエスト時は 00:00:00:00:00:00（不明のため）、リプライ時は宛先のMACアドレス。
  • 対象プロトコルアドレス (Target Protocol Address: TPA): 解決したい相手のIPアドレス。

ブロードキャストの嵐とユニキャストの美学

ARPリクエストの送信時、イーサネットヘッダーの宛先MACアドレスには ff:ff:ff:ff:ff:ff（ブロードキャスト）が使用される。セグメント内のすべてのホストがこのパケットを受け取り、自身のIPアドレス（TPA）と一致するかをカーネル内で評価する。

一致したホストだけが、オペコード 2（リプライ）を立て、送信元MACアドレス（SHA）に自身のMACを書き込み、リクエスト元のMACアドレス宛てにユニキャストで返答する。この「ブロードキャストで問いかけ、ユニキャストで結ぶ」という非対称なハンドシェイクこそがARPのアイデンティティだ。

—

2. カーネル内部の現実：ARPキャッシュとLinuxの挙動

パケットがどれほど美しくとも、毎回ブロードキャストを飛ばしていてはネットワークの帯域が無駄に消費される。そこで登場するのが ARPキャッシュ（ARP Table） だ。

Linuxカーネルは、一度解決したIPとMACの対応関係を一定期間メモリ上に保持する。手元のLinux環境で現在のARPキャッシュを確認してみよう。

# 現在のARPキャッシュ（近傍キャッシュ）を詳細に表示する
ip neighbor show

出力結果の末尾にある REACHABLE や STALE といった状態（NUD: Neighbor Unreachability Detection）こそが、インフラの安定性を左右する隠れたパラメータだ。

LinuxカーネルにおけるARPパラメータのチューニング

高トラフィックなWebサーバーやコンテナ基盤では、デフォルトのARPタイムアウト設定では不十分な場合がある。/etc/sysctl.conf や sysctl コマンドでチューニングすべき主要なパラメータを見てみよう。

# /etc/sysctl.d/99-arp-tuning.conf

# ARPキャッシュのエントリがガベージコレクションされるまでの基本時間（秒）
net.ipv4.neigh.default.gc_stale_time = 60

# キャッシュエントリの最大数（大規模環境では枯渇に注意）
net.ipv4.neigh.default.gc_thresh3 = 4096
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh1 = 1024

# ARPリクエストの再送回数
net.ipv4.neigh.default.ucast_solicit = 3

特にマルチテナント環境やKubernetesのCNI（Container Network Interface）が頻繁にIPを再割り当てする環境では、gc_stale_time の適切な調整が、古いMACアドレスへのパケット送信（パケットロスト）を防ぐ生命線となる。

—

3. セキュリティの暗部：ARPスプーフィングとゼロトラストの対峙

セキュリティスペシャリストとして避けて通れないのが、ARPプロトコルの致命的な設計思想の欠陥だ。ARPには「認証」という概念が一切存在しない。

誰かが「俺がそのIPアドレスの持ち主だ」と嘘のARPリプライ（Gratuitous ARP含む）を送りつければ、受信側のカーネルは疑うことなくARPキャッシュを書き換えてしまう。これが ARPスプーフィング（ARPなりすまし） であり、中間者攻撃（MitM: Man-in-the-Middle）の古典的かつ強力な手口である。

攻撃のメカニズム

1. 攻撃者が、ゲートウェイ（ルーター）のIPアドレスと「攻撃者のMACアドレス」を紐付けた偽のARPリプライを標的PCに送りつける。
2. 同時に、標的PCのIPアドレスと「攻撃者のMACアドレス」を紐付けた偽のARPリプライをゲートウェイに送りつける。
3. 標的PCとゲートウェイ間のすべてのトラフィックが攻撃者を経由するようになり、通信の盗聴や改ざんが可能になる。

現代のインフラにおける防御策

境界防御が崩壊し、ゼロトラストアーキテクチャが叫ばれる現在でも、L2レベルの脆弱性は依然として脅威だ。これを防ぐためには、ネットワーク機器側とホスト側の双方で多重の対策を講じる必要がある。

1. スイッチ側での対策：DAI（Dynamic ARP Inspection）

Cisco等のエンタープライズ向けスイッチでは、DHCPスヌーピングのデータベースと連携し、正当なIP-MACバインディング以外を破棄する DAI を有効化する。

[Switch (DAI Enabled)]
  ├─ 正常なARPパケット → 転送許可
  └─ 偽装されたARPパケット → 即座にドロップ ＆ ログ出力

2. Linuxホスト側での対策：静的ARPエントリとignore設定

重要サーバーにおいて、ARPキャッシュの動的な書き換えを禁止したい場合は、静的エントリを登録する。

# 特定のIPに対して静的なMACアドレスをバインド（ARPキャッシュの固定）
sudo ip neighbor add 192.168.1.1 lladdr 00:11:22:33:44:55 dev eth0 nud permanent

# 登録された静的エントリの確認
ip neighbor show dev eth0

さらに、不要なGratuitous ARPを受け入れないように、カーネルパラメータを絞ることも有効だ。

# /etc/sysctl.d/99-arp-security.conf

# 自身のインターフェースに割り当てられていないIPに対するARP要求への応答を制限 (ARPレスポンスの厳格化)
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.default.arp_ignore = 1

# ARPキャッシュの更新において、より厳格な検証を行う
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 2

—

4. パフォーマンスとスケーラビリティの極限：ARPブロードキャストストームの回避

大規模なデータセンターやクラウド環境において、ARPプロトコルが引き起こす最大の性能問題が ブロードキャストストーム だ。

数千台の仮想マシンやコンテナが同一のL2セグメント（ブロードキャストドメイン）に存在する場合、各ホストが定期的に発するARP要求（および未知の宛先への解決要求）がネットワーク全体のCPUと帯域を蝕む。

解決アプローチ：L3化とオーバーレイネットワーク

1. ルーテッドアクセス（Routed Access / IP-unnumbered）:
サーバーの直近（ラックトップスイッチ等）までL3ルーティングを持ち込み、サーバー間をL3で接続する。L2セグメントを極限まで小さくし、ARPの爆発的拡散を防ぐ。
2. VXLAN等のオーバーレイネットワーク:
パケットをUDPでカプセル化してL3網を越える際、ARPリクエストをマルチキャストやコントロールプレーン（Bess/EVPNなど）で代理応答（ARP Proxy / ARP Suppression）させ、L2のブロードキャストを完全に排除する。

—

結びにかえて

ARPは、インターネットの黎明期から存在する極めてシンプルで枯れたプロトコルだ。しかし、そのシンプルさゆえに、パケットの挙動、カーネルのメモリ管理、そしてセキュリティの脆弱性がダイレクトにインフラのパフォーマンスと安全性に跳ね返ってくる。

「動いているから触らない」ではなく、「パケットがどう流れ、カーネルがどう処理し、どこにリスクが潜んでいるか」を解像度高く理解していること。それこそが、トラブルシューティングの現場で迷うことなく真実を導き出す、真のインフラエンジニアの武器となる。

スポンサーリンク

コメント

タイトルとURLをコピーしました