ネットワークの現場で最も血の気が引く瞬間の一つ――それは、社内ネットワークに繋がれた謎のPCから突如として間違ったゲートウェイIPがばらまかれ、フロア全体の通信が完全に沈黙した時です。
Web APIの設計やモダンなクラウドインフラの構築に日々奔走するエンジニアであっても、その土台を支えるL2/L3の挙動、特に「誰がIPアドレスを配っているか」という根源的なトラストの崩壊には無力になりがちです。DHCPは初期設定があまりにも「おせっかいで親切」であるがゆえに、ネットワーク内に一匹でも狼（不正なDHCPサーバー）が紛れ込むと、たちまちディザスターを引き起こします。
今回は、そんなL2の無法地帯に秩序をもたらすシールド、「DHCPスヌーピング（DHCP Snooping）」の深淵へ皆さんをご案内しましょう。教科書的な定義のななめ上を行く、パケットの生々しい挙動と現場のリアルな設定ノウハウを紐解いていきます。
—
1. なぜDHCPスヌーピングが必要なのか？（根本原因の解剖学）
DHCP（Dynamic Host Configuration Protocol）のプロトコル自体には、サーバーの正当性を検証する仕組みが備わっていません。クライアントがブロードキャストで投げた DHCPDISCOVER に対し、一番最初に返事をしたサーバーの DHCPOFFER を無条件で信じ込んでしまいます。
この仕様の隙を突くのが、悪意あるユーザー（あるいは設定ミスでルーター機能を有効にしたままの家庭用無線AP）による不正DHCPサーバー（Rogue DHCP Server）です。
これが引き起こす実害は深刻です。
1. IPスプーフィングと通信傍受（Man-in-the-Middle攻撃）: 偽のデフォルトゲートウェイを指すIPを配ることで、トラフィックを一度攻撃者の端末に経由させ、通信を丸裸にする。
2. サービス妨害（DoS）: 枯渇攻撃（DHCP Starvation）により正当な端末がIPを取得できなくなる。
これを防ぐための防波堤となるのが、スイッチのASICレベルでDHCPトラフィックを監視・制御するDHCPスヌーピングです。
—
2. DHCPスヌーピングのメカニズムと信頼の境界線
DHCPスヌーピングは、スイッチのポートを厳格に2つに分類することから始まります。
- 信頼ポート（Trusted Port）: 正当なDHCPサーバーが接続されているアップリンクポートや、コアスイッチ間を接続するポート。このポートを通るDHCPメッセージはすべてスルーされます。
- 不信頼ポート（Untrust Port）: 一般のPCやプリンタ、そして潜在的な不正DHCPサーバーが接続されるアクセスポート。ここからのパケットは厳しく検閲されます。
パケットが駆け抜ける瞬間：DORAプロセスの裏側
スイッチがDHCPスヌーピングを有効にすると、不信頼ポートにおいて以下の劇的なフィルタリングが実行されます。
1. DHCPDISCOVER / DHCPREQUEST: 不信頼ポートからのこれらのリクエストは通過を許可されます。
2. DHCPOFFER / DHCPACK（ここが重要）: なんと、不信頼ポートから流れてきたサーバー側の応答メッセージは、すべてスイッチが即座にドロップ（破棄）します。不正なサーバーがどんなに声を大にしてIPを配ろうとしても、スイッチの入り口で物理的に握りつぶされるわけです。
—
3. DHCPスヌーピング・データベース（Binding Table）の爆誕
DHCPスヌーピングが優れているのは、単に不正サーバーを遮断するだけではありません。信頼されたトランザクションを監視し、「どのMACアドレスの端末が、どのIPアドレスを、どのポートで借りているか」を動的にマッピングしたDHCPスヌーピング・データベース（Binding Database）を裏で自動生成します。
このデータベースは、のちに学ぶ「DAI（Dynamic ARP Inspection）」や「IP Source Guard」といった、より高度なL2セキュリティ機能の強力な「情報源（ソースオブトゥルース）」として機能します。APIの認可サーバーにおけるトークン管理のようなものが、L2のハードウェアレベルで行われているとイメージしてください。
—
4. 実務で直面する設定とデバッグの作法
それでは、Cisco Catalystスイッチを例に、実務でそのまま使えるコンフィギュレーションを見ていきましょう。ただコマンドを並べるだけでなく、現場でハマりがちなポイントに注釈を入れます。
ネットワーク構成の前提
GigabitEthernet0/1: 正当なDHCPサーバー（または上流のL3スイッチ）が接続されているポート ＝ 信頼（Trusted）GigabitEthernet0/10 - 24: エンドユーザー（PCやIP電話）が接続するアクセスポート ＝ 不信頼（Untrust・デフォルト）- 対象VLAN:
10
1. スイッチ全体およびVLAN単位での有効化
! グローバルでDHCPスヌーピングを有効化
ip dhcp snooping
! 対象のVLAN（ここではVLAN 10）でスヌーピングを有効化
ip dhcp snooping vlan 10
! （重要）スイッチ再起動時などにデータベースを失わないよう、外部サーバーやフラッシュに保存する設定
ip dhcp snooping database flash:dhcp_snooping.db2. ポートの信頼性（Trust）の定義
! 上流のDHCPサーバーに繋がるポートを信頼ポートに指定
interface GigabitEthernet0/1
description === Uplink to Core Switch / DHCP Server ===
ip dhcp snooping trust
! エンドユーザー側ポートはデフォルトでUntrustなので明示的に設定不要だが、
! トラブルシューティング時は念のため確認する
interface range GigabitEthernet0/10 - 24
description === User Access Ports ===
no ip dhcp snooping trust3. レートリミット（負荷対策）の調整
不信頼ポートから大量の DHCPDISCOVER を送りつけられてスイッチのCPUが圧迫されるのを防ぐため、帯域（パケット数）制限をかけます。
interface range GigabitEthernet0/10 - 24
! 1秒あたり15パケットを超えるDHCPリクエストは不正（または異常）とみなし、ポートをエラーディセーブルにする
ip dhcp snooping limit rate 15—
5. トラブルシューティング：現場でパケットの挙動を追う
「設定した途端に、特定のフロアのPCがIPを取れなくなった！」――インフラエンジニアなら冷や汗が出る瞬間です。こういう時こそ、感情を排してCLIからパケットの生死を確認します。
ステータスとバインディングテーブルの確認
まずは、スイッチが正しくデータベースを築いているか確認します。
Switch# 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/10
Total number of bindings: 1ここで目的のクライアントのMAC/IPが表示されていれば、DORAのプロセスは正常にスヌーピングを通過しています。
偽サーバー遮断の証拠を掴む
もし「不正サーバーを遮断したログ」が見当たらない、あるいは正当なサーバーの返事まで弾かれている疑いがある場合は、カウンターを覗き見ます。
Switch# show ip dhcp snooping statistics
Statutes:
Packets forwarded: 1250
Packets dropped: 3 <-- ここがカウントアップしているか？
- 信頼できないポートからのDHCPOFFER: 3
- レートリミット超過による破棄: 0もし Packets dropped が増え続けている場合、「信頼ポート（Trust）に指定し忘れたポートから、正当なDHCPサーバーのパケットが入ってきている」という典型的なコンフィグミスを疑ってください。
—
まとめ：L2の足元を固める美学
Web APIやマイクロサービスの世界では、OAuth 2.0やmTLSといった洗練されたアプリケーション層のセキュリティに目が行きがちです。しかし、それらの通信が流れる物理・データリンク層が「野良DHCP」によっていとも簡単にハイジャックされてしまっては、上位層のセキュリティは砂上の楼閣となります。
DHCPスヌーピングは、スイッチのポート単位で「誰が信用できるか」を定義する、極めてシンプルかつ強力な境界防御です。泥臭いL2の挙動を理解し、トラフィックの流れる道筋をコントロールすること――それこそが、障害に強いインフラストラクチャを作り上げるシニアエンジニアの美学といえるでしょう。
さあ、次のメンテナンスウィンドウでは、あなたのオフィスのスイッチコンフィグを見直してみませんか？
コメント