0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

#0169(2025/06/14)ARP解説

Posted at

1. はじめに

  • ARP (Address Resolution Protocol) は IPv4 ネットワークの L2–L3 ブリッジとして45年以上にわたり使われ続けています。
  • 本稿では、単なるプロトコル仕様の説明にとどまらず、OS 実装差・障害解析・セキュリティ脅威と防御・クラウド/DC における最適化手法を段階的に深掘りします。
  • 読者想定: ルータ/スイッチの CLI が扱え、Linux カーネルパラメータを調整しながらトラブルシュートできるレベルのエンジニア。

2. ARP の基礎再確認

  • 役割: IPv4 アドレスと同一ブロードキャストドメイン内の MAC アドレスをマッピングし、Ethernet フレームの宛先 MAC を決定。

  • パケット構造:

    • HTYPE (16bit) = 0x0001 (Ethernet)、PTYPE (16bit) = 0x0800 (IPv4)
    • HLEN (8bit) = 6, PLEN (8bit) = 4
    • OPER (16bit) = 0x0001: request, 0x0002: reply, 0x0003: RARP request, 0x0004: RARP reply
    • Payload フィールド: 送信者/宛先の MAC・IP の組み合わせが続く (合計28バイト)。
  • フレーム形式: Ethernet Type = 0x0806、宛先 MAC = ff:ff:ff:ff:ff:ff (request 時)

  • キャプチャ例 (tcpdump):

    $ sudo tcpdump -ennvvv arp
    12:00:01.123456 eth0 ff:ff:ff:ff:ff:ff > 00:11:22:33:44:55, ARP, Request who‑has 192.168.0.10 (Broadcast) tell 192.168.0.1, length 28
    
  • GC Algorithm: 「送信トリガ」「受信時自動学習」「GARP」によりキャッシュを生成し、時間経過でエージング。


3. ARP キャッシュの挙動と OS 実装差

  • Linux

    • デフォルト有効期限: net.ipv4.neigh.default.base_reachable_time_ms (30,000) × random\_factor (0.75–1.25) ≒ 22–37 秒。
    • 再試行インターバル: retrans_time_ms (1,000ms) を 3 回送信後 FAILED 状態。
    • gc_thresh1/2/3 によりエントリ数が溢れると GC が発動。
  • Windows (10 以降)

    • 未使用エントリ: 30 秒で削除。
    • 直近通信エントリ: 2 分。
    • REGEDIT: ArpCacheLife, ArpRetryCount で調整可能。
  • Cisco IOS

    • arp timeout コマンド (秒単位) で VLAN 毎に設定。
    • CPU で処理するため高スループット時の punt rate に注意。
  • JunOS / Arista EOS も同様に VRF またぎで個別に調整可能。

  • ポイント: マイクロバースト的に ARP が増えると CPU ポリシングが無い機器はスロットルが発生し、全体通信が巻き添えで落ちる。


4. Gratuitous ARP (GARP)

  • 定義: 送信元と宛先 IP が同一の ARP Request/Reply を自身へ向けてブロードキャストし、周囲キャッシュを同期。

  • ユースケース

    1. フェイルオーバ: VRRP/HSRP/GLBP がマスタ昇格時に 5 回 × 50ms 間隔で送信。
    2. IP 移設: 仮想マシン Live Migration 後、自動で新 MAC を通知。
    3. CAM 更新: L2 スイッチのポートフラップ後にブラックホールを防止。
  • 注意点: 無差別に垂れ流すとセグメント規模に比例してストーム化しうるため、DC 環境では EVPN ARP Suppression を併用。


5. Proxy ARP の内部動作

  • 仕組み: ルータが同一サブネット内のホストになりすまし ARP Reply を返答→ホストはルータ MAC を登録。

  • 典型シナリオ

    • /24 サブネットを 2 台のルータで分割広告せず、クライアント側は CIDR を意識せずに通信可。
    • Legacy IoT デバイスが IP 設定を変えられない場合の延命策。
  • 副作用

    • ネットワーク境界が不透明になり、ACL/FW ポリシングが困難。
    • ルータ CPU へ L2 処理が集中し、DDoS の標的になりやすい。
    • トラフィックエンジニアリング不可: 必ず Proxy ARP ルータ経由となりイコライゼーションが効かない。
  • ベストプラクティス: 近代 DC では IRB + EVPN(MAC/IP ルーティング) が主流で、Proxy ARP はレガシー移行期間に限定。


6. ARP スプーフィング/Poisoning 攻撃

6.1 攻撃フロー

  1. 悪意端末 A がターゲット T と GW に対し 偽 ARP Reply を無差別送信。
  2. T の ARP キャッシュ: GW IP→A MAC に更新。
  3. GW の ARP キャッシュ: T IP→A MAC に更新。
  4. A は MITM の位置を獲得し、パケットをリレー or 改竄。

6.2 再現ラボ (Linux)

# ターゲット 192.168.0.20, GW 192.168.0.1
sudo arpspoof -i eth0 -t 192.168.0.20 192.168.0.1
sudo arpspoof -i eth0 -t 192.168.0.1 192.168.0.20
  • 検証ポイント: arp -n で MAC が悪意端末のものへ瞬時に書き換わる。

6.3 緩和策

  • DHCP Snooping + Dynamic ARP Inspection (DAI)

    • Switch が DHCP Binding Table と照合し、IP↔MAC 不整合の ARP Reply をドロップ。
    • Cisco: ip dhcp snooping, ip arp inspection vlan <VLAN>
  • 静的 ARP: arp -s <IP> <MAC> (小規模 Only) → メリット: 簡単 / デメリット: 運用負荷。

  • SEND (Secure Neighbor Discovery) は IPv6 のみだが、同等発想の 802.1X + NAC で端末認可後に VLAN へステア。


7. ARP 応答制御とカーネルパラメータ

  • Linux

    • arp_ignore (0–8): 応答の選択ポリシー。一般に 1 or 2 で 不要応答を抑制
    • arp_announce (0–2): 送信側アドレスの選択。2 は 最適インタフェースのみ広告し、クロストークを防止。
    • 適用例: コンテナ/Kubernetes で CNI ブリッジが多層化する場合、arp_announce=2 が必須。
  • Windows

    • weakhostrecv/weakhostsend: 0 で強ホスト、1 で弱ホスト。強ホストにすることで IP 跨り応答を阻止。
  • nftables での L2 フィルタ

    table bridge arpfilter {
      chain prerouting {
        type filter hook prerouting priority -300;
        arp saddr set 0.0.0.0 drop # Gratuitous ARP Storm 緩和
      }
    }
    

8. トラブルシューティングの深掘り

  • キャプチャ Tips

    • tcpdump -i eth0 -nn -e -v arp or rarp → HW Addr を必ず表示。
    • Wireshark で "Duplicate IP address detected" Expert Info をサーチ。
  • sysfs/Event Log

    • Linux: dmesg | grep -i arp同一 IP 重複時のカーネルメッセージ確認。
    • Windows: Event ID 4199 (duplicate IP) に着目。
  • 再現テスト

    • arping -I eth0 -c 5 -A 192.168.0.5 (GARP)。周囲でキャッシュが即更新されるか観察。
    • FAILED エントリ: ip -s neigh flush failed で再解決を強制。

9. IPv6 への展開: Neighbor Discovery Protocol

  • ARP 非採用: IPv6 は ICMPv6 Neighbor Solicitation (NS)/Advertisement (NA) に置換。

  • 追加機能

    • DAD (Duplicate Address Detection)
    • SLAAC (Stateless Address Autoconfiguration)
    • RA (Router Advertisement) による MTU 配布 & Prefix 情報
  • セキュリティ: SEND (RFC 3971) + Cryptographically Generated Address (CGA) → 現実運用はハードル高/代替として RA Guard, ND Inspection がエンタープライズで普及。


10. モダンデータセンタと ARP 抑制

  • Overlay Network

    • VXLAN/GENEVE では VTEP が ARP を コントロールプレーン (BGP-EVPN) へオフロード。
    • "ARP suppression" 機構: Spine ルータが Type-5 (IP Prefix) ルートとして広告→ ブロードキャスト削減。
  • キャンパス・Fabrics

    • Cisco DNA Center, Juniper Apstra 等のファブリックは Anycast GW と EVPN を標準装備。
    • Host mobility が多くても GARP は Spine で吸収され、Leaf 間に氾濫しない。
  • クラウド (AWS)

    • VPC 内は AWS Hypervisor が ARP Proxy を行い、エンドデバイスは他インスタンス MAC を知らない。
    • Security Group が L3/L4 レイヤで適用されるため、ARP スプーフィングは不可能。

11. Hands‑On: Linux ネットワーク名前空間で再現

  1. 名前空間作成

    ip netns add ns1; ip netns add ns2
    ip link add veth1 type veth peer name veth2
    ip link set veth1 netns ns1; ip link set veth2 netns ns2
    ip -n ns1 addr add 10.0.0.1/24 dev veth1; ip -n ns2 addr add 10.0.0.2/24 dev veth2
    ip -n ns1 link set veth1 up; ip -n ns2 link set veth2 up
    
  2. ARP 交換確認

    ip netns exec ns1 ping -c1 10.0.0.2
    ip netns exec ns1 ip neigh show
    
  3. GARP 送信と反映

    ip netns exec ns2 arping -A -c1 -I veth2 10.0.0.2
    
  4. nftables で ARP Block

    ip netns exec ns1 nft add table bridge filter
    ip netns exec ns1 nft add chain bridge filter prerouting '{ type filter hook prerouting priority -300; }'
    ip netns exec ns1 nft add rule bridge filter prerouting arp op request drop
    

    → ns2 からの ARP Request がドロップされ、ping が失敗することを確認。


12. まとめと今後の展望

  • ARP はシンプルゆえに 「放置されやすいレイヤ」 だが、障害・セキュリティ両面で高リスク。

  • OS 実装差 / ネットワーク規模 / マルチテナント要件 を踏まえてチューニングしなければ、大規模化に伴う制御プレーン輻輳が顕在化。

  • 将来像としては

    1. IPv6 NDP 完全移行
    2. SDN/Fabric による レイヤ2コントロールプレーンの集中管理
    3. ゼロトラストにおける L2-L3 動的認可連携
      が不可避。
  • 本稿の検証コマンド/設定例を基に、読者各位の環境で 再現実験→パラメータ最適化→運用手順化 を進めていただきたい。


0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?