パケットが語る真実：Gratuitous ARPの深層とエンタープライズネットワークの攻防
ネットワークの配管工やセキュリティエンジニアであれば、一度は夜中に鳴り響くアラートに飛び起き、tcpdumpの流れるログを睨みつけた経験があるはずだ。
「またIPアドレスの競合か……」
クラウド全盛の現代においても、ベアメタルサーバーの群れ、仮想化基盤のハイパーバイザー、そしてコンテナオーケストレーションが交錯するデータセンターの底流では、依然としてレイヤー2の原始的かつ強力なプロトコルがインフラの生死を握っている。その主役の一つが、今回スポットを当てる Gratuitous ARP（無償ARP / GARP） だ。
教科書的な定義を繰り返す気はない。「自身のIPアドレスを送信元IPとしてブロードキャストし、誰か使っていないか確認する」、あるいは「IPとMACのマッピングを強制的に更新させる」——そんな表面的な理解のままでは、大規模エンタープライズの複雑なネットワークや、ゼロトラスト時代のセキュアな境界防御において足元をすくわれる。
今回は、パケットの生々しい挙動から、Linuxカーネルの内部仕様、冗長化ルーターのフェイルオーバー、さらには悪意あるARPスプーフィングの脅威と回避策まで、極限のパフォーマンスとセキュリティの観点から徹底的に解剖していこう。
—
1. Gratuitous ARPのパケットレベルでの内部挙動とメカニズム
ARP（Address Resolution Protocol）は、通常「このIPアドレスを使っている奴のMACアドレスを教えてくれ（Who has …? Tell …）」という問いかけから始まる。しかし、Gratuitous ARPはこの原則をあえて歪める。
GARPフレームの構造を、イーサネットフレームから順に覗いてみよう。
- Destination MAC (宛先MAC):
ff:ff:ff:ff:ff:ff（ブロードキャスト） - Source MAC (送信元MAC): 送信端末のMACアドレス
- EtherType:
0x0806（ARP） - ARP Hardware Type:
0x0001（Ethernet） - ARP Protocol Type:
0x0800（IPv4） - 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アドレス（SPAと同一）
注目すべきは、SPA（送信元IP）とTPA（ターゲットIP）に同一のIPアドレスが格納されている点だ。パケットを受け取ったセグメント内のすべてのノードは、「おっ、自分のARPキャッシュを更新するか、あるいは……」とこのパケットを処理することになる。
[クライアントA (192.168.1.10)] --(GARP: SPA=192.168.1.10, TPA=192.168.1.10)--> [ブロードキャスト (FF:FF:FF:FF:FF:FF)]
|
+-----------------------------------------------------------------+
|
v
[スイッチ / ブリッジ] ---> セグメント内の全ホスト・ルーターにフラッディングなぜこれが「無償（Gratuitous）」と呼ばれるのか？
誰からも要求（Request）されていないのに、自発的に（Gratuitously）ネットワークへ向けて自身の存在を叫ぶからだ。この挙動には、主に2つの重大な目的が存在する。
1. IPアドレスの重複検知 (DAD: Duplicate Address Detection)
2. ARPキャッシュの強制アップデート（冗長構成・フェイルオーバー時の通知）
—
2. IP重複検知（DAD）とカーネルパラメータのチューニング
ネットワークに新しく参画するノードや、インターフェースを起動した瞬間のLinuxカーネルは、デフォルトでGARPをブロードキャストし、同じIPを使っている先住者がいないか確認する。もし、このGARPに対して誰かから「それは俺のIPだ！」という応答（ARP Reply）が返ってきた場合、カーネルは「IP Address Conflict」を検知し、ログに重篤なエラーを吐き出す。
しかし、ミッションクリティカルなエンタープライズ環境では、このデフォルトの挙動だけでは不十分なケースが多い。特に大規模なL2ドメインや、オートスケーリングする仮想環境においては、カーネルのARP挙動を厳密にチューニングする必要がある。
Linuxのsysctlで設定可能な、ARP関連の主要なパラメータを見てみよう。
# /etc/sysctl.d/99-arp-hardening.conf
# インターフェースが参加した際にGARPを送信する回数
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 2
# 受信したARPリクエストに対して、自身のサブネット外であっても
# 適切に応答するかどうか（通常は厳密なモデルである 1 または 2 を推奨）
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.default.arp_ignore = 1
# 不正なARPキャッシュの汚染を防ぐための設定
net.ipv4.conf.all.arp_accept = 0ここで arp_announce = 2 は非常に重要だ。これは、ARPリクエストの送信元IPアドレスとして、そのパケットが出ていくインターフェースに設定された最適なローカルIPアドレスを選択させる設定であり、マルチホーミング環境や複雑なルーティングテーブルを持つサーバーにおいて、誤ったIPでのGARP送信を防ぎ、正確なDADを担保する。
—
3. 高可用性（HA）クラスターとロードバランサーにおけるGARPの生命線
インフラエンジニアの真価が問われるのは、フェイルオーバーの瞬間だ。
Keepalived（VRRP）やPacemakerを用いたActive-Standby型の高可用性クラスター、あるいはBIG-IPなどのロードバランサーにおいて、仮想IP（VIP）がマスター機からバックアップ機へ瞬時に移動する際、GARPはなくてはならないキーストーンとなる。
マスター機がダウン、あるいは優先度の変動により、バックアップ機がVIPを自身のインターフェースにバインドした瞬間、バックアップ機は次のようなアクションを自動実行する。
1. 新しいMACアドレスとVIPの組み合わせを持つGARPパケットを連続して送出する。
2. スイッチや上位ルーター、クライアント群のARPキャッシュに刻まれていた「古いMACアドレス ＝ VIP」のエントリを強制的に上書きする。
このGARPの送出が遅延したり、スイッチ側のポートセキュリティやダイナミックARPインスペクション（DAI）によってドロップされたりするとどうなるか？
クライアントからのトラフィックは依然として「死んだ旧マスターのMACアドレス」に向かって送出され続け、ブラックホール化（通信断）を引き起こす。
Keepalivedの設定ファイルにおいて、このフェイルオーバー時の挙動を最適化するためのスニペットを確認してみる。
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
virtual_ipaddress {
192.168.1.100/24 dev eth0 label eth0:vip
}
# フェイルオーバー時に送信するGARPの回数と遅延の設定
garp_master_delay 1 # マスター昇格後のGARP送信までのディレイ（秒）
garp_master_repeat 5 # 連続して送信するGARPパケットの数（確実性を高める）
}この garp_master_repeat 5 というパラメータは、パケットロスが起こり得る物理・仮想ネットワークにおいて、上位機器のARPテーブルを確実にフラッシュさせるための現場の知恵である。
—
4. パフォーマンスの最適化：RTT削減とトランスポート層への影響
「たかがARP、されどARP」。GARPや通常のARP解決の遅延は、上位のトランスポート層（TCP）やアプリケーション層（TLSハンドシェイク）のレイテンシーに直結する。
考えてみてほしい。クライアントが新しいバックエンドサーバー群に対してHTTPS接続を確立しようとするとき、以下のシーケンスが裏で走っている。
1. DNS解決
2. ARPリクエスト / レスポンス（またはGARPによる事前学習）
3. TCP 3-wayハンドシェイク（SYN -> SYN-ACK -> ACK）
4. TLS 1.3ハンドシェイク（Client Hello -> Server Hello / Encrypted Extensions / Finished）
もし、直前にGARPが正常に処理されておらず、サーバー側への通信でARPの解決（Who has…）が挟まってしまうと、TCPの SYN パケットを送出する前に数十ミリ秒の遅延が発生する。これがクラウド環境やマイクロサービス間の通信であれば、ミリ秒単位の積み重ねが全体のスループットを大きく削り取る。
また、TCPバッファチューニングやウィンドウサイズの最適化を行っていても、L2の名前解決がボトルネックになっていては意味がない。GARPによって事前にネットワーク全体のARPキャッシュをフレッシュな状態に保つことは、「TCPの初期RTO（Retransmission TimeOut）やスロースタートを無駄な待ち時間で汚染させない」ための極めて効果的な前処理なのだ。
—
5. セキュリティの暗黒面：ARPスプーフィングとゼロトラストでの対策
ここまではGARPの美徳を語ってきたが、セキュリティエンジニアの視点に切り替えると、GARPは「攻撃者にとって最も魅力的で、かつ悪用しやすいプロトコル」に変貌する。
GARPの仕様上の致命的な欠陥は、「認証機構が一切存在しない」という点に尽きる。
受信側は、誰がそのGARPを送ってきたのかを暗号学的に検証するすべを持たない。つまり、悪意ある攻撃者が自端末から「私はデフォルトゲートウェイのIPを持っているぞ！」という偽のGARP（あるいはGARPを利用したARPポイズニング）を流し続ければ、セグメント内のすべてのトラフィックを自身の端末に引き込むこと（中間者攻撃: MitM）が容易にできてしまう。
ゼロトラストアーキテクチャの基本思想は「決して信頼せず、常に検証せよ（Never Trust, Always Verify）」だが、レガシーなL2ネットワークにおいてこれを実現するためには、ネットワーク機器側でのハードウェアベースの防御が不可欠となる。
実務で必須のセキュリティ対策パラメータと設定
スイッチングハブ（Cisco CatalystやAristaなど）のレイヤーで実装すべき、ARP偽装を防ぐための鉄板設定を確認する。
# Cisco IOSでのDynamic ARP Inspection (DAI) と DHCP Snooping の設定例
# 1. 信頼されたアップリンクポート（正当なルーターやDHCPサーバーに接続するポート）の定義
interface GigabitEthernet0/1
description Trust Uplink to Router
ip dhcp snooping trust
ip arp inspection trust
# 2. クライアント収容ポートの設定（レートリミットをかけ、異常なGARP/ARPを検知・ドロップ）
interface range GigabitEthernet0/2 - 24
description Access Ports for Endpoints
ip dhcp snooping limit rate 15
ip arp inspection limit rate 10
# 3. VLANごとのDAI有効化
ip dhcp snooping vlan 10
ip arp inspection vlan 10ダイナミックARPインスペクション（DAI） は、DHCPスヌーピングによって作成されたバインディングデータベース（IPとMACとポートの正当な対応表）と、流れてくるARPパケット（GARP含む）の内容を突き合わせ、一致しないものを即座にドロップする。これにより、偽のGARPを用いたキャッシュポイズニングやIPハイジャックを根絶やしにすることができる。
さらに、Linuxホスト側でも不正なARPキャッシュの書き換えを防ぐために、前述の arp_accept や、ブリッジ環境におけるebtables/nftablesを用いたフィルタリングを組み合わせるのが、プロフェッショナルのアプローチだ。
—
結びに代えて
Gratuitous ARPは、一見すると地味なパケットのやり取りに過ぎない。しかし、その数バイトのペイロードの裏側には、ネットワークの可用性を守るためのフェイルオーバーの仕組みがあり、パフォーマンスを極限まで高めるための基盤があり、そして一歩間違えれば組織全体を危うくするセキュリティの脆弱性が同居している。
パケットの挙動を愛し、カーネルのソースコードやスイッチの挙動にまで思いを馳せること。それこそが、真に堅牢で高速なインフラストラクチャを構築するための唯一の王道なのだ。次の夜間作業で tcpdump を開いたとき、そこを駆け抜けるGARPの群れが、単なるノイズではなく「ネットワークの鼓動」に聞こえるようになったなら、あなたもすでにこちら側の人間である。
コメント