こんにちは。ネットワークの深淵を愛するインフラエンジニアの皆さん。
APIの設計やマイクロサービスの構築において、私たちは日々「認証」や「認可」といったレイヤー7のセキュリティに頭を悩ませています。JWTの検証、OAuth 2.0のスコープ管理、CORSの設定……。しかし、どれほど洗練されたAPIを構築したところで、その土台であるL2/L3ネットワークが足元から揺るがされていたとしたらどうでしょう？
今回は、レイヤー2のスイッチングの世界において、IPアドレスの「なりすまし（IPスプーフィング）」を物理的・プロトコル的にねじ伏せる硬派な機能、IPソースガード（IP Source Guard: IPSG）について徹底的に解説します。
教科書的な仕様のなぞり書きではありません。現場のエンジニアが「なぜこれが必要なのか」「どうやって正しく実装し、どうやってトラブルシュートするのか」を、実例を交えてお伝えしましょう。
—
1. なぜIPソースガードが必要なのか？ L2の暗黙の信頼を断ち切る
現代の企業ネットワークやデータセンターにおいて、イーサネットフレームは「そこにいれば運ぶ」という善意で成り立っています。ARP（Address Resolution Protocol）には認証の概念がありませんし、IPパケットの送信元IPアドレス（Source IP Address）も、OSのネットワークスタックを直接叩くか、ローソケット（Raw Socket）を使えば、誰でも簡単に偽りの値を設定して送信できます。
ここで想像してください。
ある悪意ある、あるいは設定を誤ったエンジニアの端末が、社内基幹システムの管理用IPアドレスを自分のNICに手動設定（スタティック設定）し、不正なトラフィックを流し始めたらどうなるでしょうか。あるいは、ARPスプーフィングと組み合わせた中間者攻撃（MitM）が行われたら？
レイヤー3のルーターやファイアウォールに到達する前、まさに端末が最初に接続するアクセススイッチのポートの段階で、この不心得なパケットを問答無用でドロップできたらどれほど安心か。それを実現するのがIPソースガードです。
—
2. IPソースガードの仕組み：DHCPスヌーピングとの蜜月
IPソースガードは単体で動作する魔法の機能ではありません。その背後には、DHCPスヌーピング（DHCP Snooping）という強力な相棒が存在します。
仕組みの全体像
1. 信頼の起点（DHCPスヌーピング）: スイッチは、どのポートが信頼できるアップリンク（DHCPサーバー側）で、どのポートが信頼できないアクセスポート（エンドユーザー側）かを監視します。端末がDHCPでIPアドレスを取得する際、そのやり取り（DHCP DISCOVER から DHCP ACK まで）をスイッチが盗み見（スヌープし）、「どのMACアドレスの端末に、どのIPアドレスが、どのポートで貸し出されたか」をバインディングデータベース（DHCPスヌーピングバインディングデータベース）に記録します。
2. 検問（IPソースガード）: アクセスポートにIPソースガードが有効化されると、スイッチのASIC（ハードウェアパケット処理チップ）レベルで、ポートに入ってくるすべてのIPパケットが検査されます。
3. 判定: パケットの「送信元IPアドレス」「送信元MACアドレス」「受信ポート」の組み合わせが、DHCPスヌーピングデータベース（または手動設定されたスタティックバインディング）と完全に一致する場合のみ転送を許可し、一致しないものはハードウェアレベルで容赦なく破棄（Drop）します。
—
3. 実務で使う：Cisco IOS/IOS-XEスイッチでの設定例
それでは、実際のエンタープライズ環境（Catalystスイッチ等）を想定した設定手順を見ていきましょう。現場でよくある「うっかりミス」を防ぐためのポイントもコメントに添えています。
ステップ1: グローバルおよびVLANでのDHCPスヌーピングの有効化
IPソースガードのデータベースの源泉となるDHCPスヌーピングを有効にします。
! DHCPスヌーピング機能をグローバルで有効化
ip dhcp snooping
! 対象のVLAN（例: 社内クライアント用VLAN 10）でスヌーピングを有効化
ip dhcp snooping vlan 10ステップ2: アップリンクポートの信頼設定
DHCPサーバーが存在するネットワーク機器側のポートは、正当なDHCP応答（DHCPOVERやDHCPACK）を返すため、「信頼できるポート」として明示的に指定する必要があります。これを忘れると、正当なDHCPトラフィックまでブロックされてしまいます。
interface GigabitEthernet0/1
description === Uplink to Core Switch / DHCP Server ===
! このポートからのDHCPサーバーメッセージを信頼する
ip dhcp snooping trustステップ3: アクセスポートへのIPソースガードの適用
エンドユーザーが接続するポートに対して、IPソースガードを有効にします。ここでは、IPアドレスだけでなくMACアドレスも検証する ip verify source を使用します。
interface GigabitEthernet0/2
description === User PC Access Port ===
switchport mode access
switchport access vlan 10
! DHCPスヌーピングをこのアクセスポートでも有効化
ip dhcp snooping port-security
! 【核心】IPソースガードを有効化（IPとMACアドレスの両方を検証）
ip verify source tracking> シニアエンジニアからのTips:
> 従来の ip verify source はIPアドレスのみの検証でしたが、モダンなCisco IOSでは ip verify source tracking（または ip verify source にMACアドレス検証オプション）を使うことで、MACアドレスの偽装も同時に防ぐことができます。仮想マシン（VM）等を収容するポートでは、1つのポートから複数のIP/MACが出るため、対応するオプションの選定には注意が必要です。
—
4. スタティックIP環境（サーバー等）へのアプローチ
すべての端末がDHCPからIPを取得するわけではありません。データベースサーバーやルーターなどの固定IP（スタティックIP）を使用する機器が接続されるポートでは、DHCPスヌーピングのデータベースにエントリが作成されません。
そのため、管理者が手動でバインディングを定義（スタティックIPソースバインディング）してやる必要があります。
! MACアドレス 'aabb.cc00.1234'、IPアドレス '192.168.10.50' を、VLAN 10のポート Gi0/3 に固定紐付け
ip source binding aabb.cc00.1234 vlan 10 192.168.10.50 interface GigabitEthernet0/3
interface GigabitEthernet0/3
description === Static Server Port ===
switchport mode access
switchport access vlan 10
! スタティックバインディングをベースにIPソースガードを有効化
ip verify sourceこの設定により、DHCPを使わない静的設定のサーバーであっても、IPソースガードの保護下に置くことができます。
—
5. 現場のトラブルシューティング：動かないときのデバッグ手順
「IPソースガードを有効にした途端、特定の端末がインターネットにつながらなくなった！」
これはインフラエンジニアが冷や汗をかく瞬間ワースト上位に入るトラブルです。慌てず騒がず、以下の手順で原因を特定しましょう。
1. バインディングデータベースの確認
まず、スイッチが正しくIPとMACの対応を学習しているか確認します。
# DHCPスヌーピングのバインディング状況を確認
show ip dhcp snooping binding
# 期待するMAC/IPの組み合わせがここに存在するか？
# MACAddress IPAddress Lease(sec) Type VLAN Interface
# ----------------------------------------------------------------------------------
# AA:BB:CC:00:12:34 192.168.10.15 86392 dhcp-snooping 10 GigabitEthernet0/2ここに該当端末の情報がない場合、端末がDHCPの更新に失敗しているか、DHCPスヌーピングの「信頼ポート」の設定漏れが疑われます。
2. IPSGによるドロップパケットの確認
実際にIPソースガードによってパケットが破棄されているかは、以下のコマンドやログで確認できます（プラットフォームによりコマンドが異なりますが、Syslogや統計情報が手がかりになります）。
# インターフェイスごとのトラフィック統計やエラーを確認
show ip verify source interface GigabitEthernet0/2もし「IP静的設定に変えた途端につながらなくなった」という問い合わせがあれば、それはほぼ間違いなくスタティックIPソースバインディングの設定漏れ、あるいは古いDHCPリース情報が残っていることが原因です。
—
まとめ：レイヤー2からの鉄壁の守り
IPソースガードは、L2スイッチという「エンドユーザーに最も近い場所」で不正なIPパケットを根絶するための、非常に費用対効果の高いセキュリティ機能です。
APIの設計やアプリケーションレイヤーのセキュリティにどれだけ力を入れても、ネットワークの足元（L2/L3）がガラ空きであれば、ARPポイズニングやIPスプーフィングを起点とした巧妙な内部不正やセッションハイジャックの隙を与えてしまいます。
「DHCPスヌーピングとの組み合わせ」「動的と静的の使い分け」、そして「トラブル時のバインディング確認」。この3つを抑えておけば、あなたの管理するネットワークは、悪意あるパケットを寄せ付けない堅牢な城塞となるでしょう。
それでは、また次回の深淵なるネットワークの世界でお会いしましょう。
コメント