こんにちは。ネットワークの深淵を愛するインフラアーキテクトの私だ。
Web APIの設計やモダンなクラウドインフラの構築に日々奔走しているエンジニアの皆さん、ふと「L2の足元」を見つめ直したことはあるだろうか？「コンテナが通信できない」「APIサーバへの疎通が突然切れた」といったトラブルシューティングの果てに、原因がL2レイヤーの泥臭いセキュリティ機能の不備だった……なんて笑えない話は、現場では日常茶飯事だ。
今回は、そんなL2ネットワークの安全性を守る守護神、「DHCPスヌーピング（DHCP Snooping）」について徹底的に解説しよう。教科書的な仕様のなぞりではなく、パケットがスイッチのASICを通過する際のリアルな挙動や、現場で踏みがちなしっぺ返し（トラブル）まで、実務に直結する知見を余すところなくお伝えする。
—
なぜ現代のインフラにDHCPスヌーピングが必要なのか？
オフィスのフロアや、あるいはオンプレミスのデータセンターの一角。誰かが誤って（あるいは悪意を持って）小型の無線ルーターを社内スイッチに接続したとする。そのルーターのLAN側ポートがスイッチに刺さっていたらどうなるか？
ルーターのDHCPサーバ機能が暴走し、社内の正当なDHCPサーバよりも先に、不審なIPアドレスやデフォルトゲートウェイ（自身を指す）をクライアントに配り始める。結果はどうなるか。
1. 通信断（IPスプーフィング・中間者攻撃の温床）: クライアントは不正なゲートウェイを信じ込み、すべてのトラフィックが不正な端末を通過する（Man-in-the-Middle攻撃）。
2. IPアドレス枯渇攻撃（DHCP Starvation）: 攻撃者が偽のMACアドレスを無限に生成してDHCPリクエストを乱発し、正当なDHCPプールのIPを枯渇させる。
こうした「信頼できない野良DHCPサーバ」の脅威からL2ネットワークを物理的・論理的に隔離するのが、DHCPスヌーピングなのだ。
—
標準仕様と通信フロー：スイッチ内部で何が起きているか
DHCPスヌーピングは、RFCとして単一のドキュメントで定義されているわけではない。Cisco Systemsが提唱し、のちに業界標準として各社（Aruba, Juniper, ヤマハ等）のL2/L3スイッチに実装されたプロプライエタリ発祥のセキュリティ機能である。
スイッチのポートを以下の2つに厳格に分類することからすべてが始まる。
- 信頼ポート（Trusted Port）: 社内の正規DHCPサーバが接続されているポートや、アップリンク側のスイッチに繋がるポート。ここからのDHCPメッセージはすべてスルーされる。
- 不信ポート（Untrusted Port）: 一般のPCやIP電話、そして未知の端末が接続されるアクセスポート。デフォルトではすべてのポートがここに分類される。
DHCP DORAのシーケンスとスヌーピングの介入
正常なDHCPクライアントがIPアドレスを取得するプロセス（DORA）において、DHCPスヌーピングはパケットをどのように監視・制御しているのだろうか。
[Client] [Untrusted Port: Switch] [Trusted Port: DHCP Server]
| | |
|---- 1. DHCP Discover -------->| (転送: 不信ポートからのブロードキャスト) |
| |-------------------------------->|
| | |
| | <--- 2. DHCP Offer -------------|
| | (ここでチェック！) |
| | ※不信ポートからのOfferなら破棄!|
| | |
|<- 3. DHCP Offer (正当な場合) -| |1. Discover: クライアントがブロードキャストでDHCPサーバを探す。不信ポートであってもこれは通る（IPを持っていないため）。
2. Offer / ACK: サーバ側から応答が返る。ここでDHCPスヌーピングの真骨頂が発動する。もし不信ポート側から DHCP OFFER や DHCP ACK といった、サーバ側からしか発せられないはずのパケットが入ってきた場合、スイッチは即座にそのパケットをドロップ（破棄）するのだ。
—
「DHCPスヌーピングバインディングデータベース」の正体
DHCPスヌーピングが優れているのは、単に不正なパケットを捨てるだけではない。信頼できるポートを流れる DHCP ACK パケットをスヌーピング（盗み見）し、以下の情報を動的にキャッシュする。これが「DHCPスヌーピングバインディングデータベース」だ。
- クライアントのMACアドレス
- 割り当てられたIPアドレス
- リース期間
- 対応するVLAN ID
- 接続されているスイッチポート番号
このデータベースは、単なるメモ帳ではない。他のL2セキュリティ機能である DAI（Dynamic ARP Inspection） や IP Source Guard の「信頼の根拠（ソースオブトゥルース）」として、そのまま利用される。つまり、DHCPスヌーピングを制する者はL2セキュリティ全体を制すると言っても過言ではないのだ。
—
実践：Cisco IOS / Catalystスイッチでの設定例
実務で遭遇するCisco Catalystスイッチを例に、具体的な設定手順を見ていこう。コマンドの裏でスイッチのASICがどう動いているのか、コメントを熟読してほしい。
! 1. グローバルモードでDHCPスヌーピングを有効化
configure terminal
ip dhcp snooping
! 2. 対象のVLAN（ここではVLAN 10と20）に対してスヌーピングを適用
ip dhcp snooping vlan 10,20
! 3. オプション82（Relay Agent Information）の挿入動作を設定
! ※直下にDHCPリレーエージェントがいない場合、検証環境や構成によっては
! 「no ip dhcp snooping information option」を入れてパケット改変を無効化することが多い
no ip dhcp snooping information option
! 4. アップリンクポート（正規のDHCPサーバや上位スイッチへ繋がるポート）を信頼ポートに指定
interface GigabitEthernet0/1
description [Trusted] Connected to Core Switch or DHCP Server
ip dhcp snooping trust
! 5. エンドユーザーが接続するアクセスポート側は自動的に不信ポート（デフォルト）になるが、
! 念のためレートリミットを設定してDHCPスターベーション攻撃（DoS）を防ぐ
interface range GigabitEthernet0/2 - 24
description [Untrusted] Access Ports for End-Users
ip dhcp snooping limit rate 15 ! 1秒間に15パケットを超えるDHCPリクエストはポートをErr-disabledにする運用時の重要なTips：レートリミット（limit rate）の罠
上記の limit rate 15 は非常に強力だが、仮想デスクトップ（VDI）環境や、朝の一斉出社時に大量のPCが同時に立ち上がる環境では、正当なトラフィックであってもこの閾値を超えてしまい、ポートが Err-disabled に落ちる障害（いわゆる自爆テロ）を引き起こすことがある。
現場のサイジングでは、VLAN内の端末数やブロードキャストドメインの規模を計算し、適切な値を慎重にチューニングしてほしい。
—
トラブルシューティング：現場でパケットが見えないときの処方箋
「DHCPスヌーピングを入れた途端、特定のPCだけIPが取れなくなった」
インフラエンジニアが冷や汗をかく瞬間だ。こういうときは、感情を鎮めて以下のコマンドでスイッチの状態を精査する。
1. バインディングデータベースの確認
現在、スイッチがどの端末のIPとMACを正当なものとして記憶しているかを確認する。
# show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
----------------------------------------------------------------------------------
00:11:22:33:44:55 192.168.10.50 86400 dhcp-snooping 10 GigabitEthernet0/2
Total number of bindings: 1ここに該当の端末のMAC/IPが表示されていない場合、そもそもDORAのプロセスが途中でドロップされている可能性が高い。
2. 統計情報の確認とドロップ理由の特定
スイッチがどのパケットをなぜ捨てているのかは、以下のコマンドで一目瞭然となる。
# show ip dhcp snooping statistics
Stateless DHCP Snooping is disabled
Packet statistics
Total packets received: 1420
Forwarded packets: 1200
Dropped packets: 220
Detailed breakdown of dropped packets:
Interface name mismatch: 0
BOGUS DHCP messages: 220 <-- ここが増えている場合、不正なパケットと判定されている
Delayed DHCP messages: 0BOGUS DHCP messages がモリモリ増えている場合、ポートの信頼設定（trust）が漏れていないか、あるいは端末側が変なDHCPパケットを投げているかを疑うべきだ。
—
まとめ
DHCPスヌーピングは、派手なWeb APIやマイクロサービスの裏側で、地味ながらもL2ネットワークの「信頼の土台」を支える極めて重要な機能だ。
- 不信ポートからの
DHCP OFFER/ACKを物理的にブロックする。 - 動的なバインディングデータベースを作り、上位のセキュリティ機能（DAI等）へデータを供給する。
- レートリミットを適切に設定し、リソース枯渇攻撃を防ぐ。
ネットワークの基礎がしっかりしていなければ、その上で動くアプリケーションもいつ足元をすくわれるかわからない。ぜひ今回の知識を自身のインフラ環境の点検に役立ててほしい。
それでは、また次の深淵でお会いしよう。
コメント