IPソースガード（IP Source Guard）の深淵：L2スイッチで「身元」を強制する技術
ネットワークエンジニアとして現場を長く歩いていると、「なぜIPアドレスというものは、こんなにも簡単に偽装できてしまうのか？」という事実に、何度か絶望させられることがあります。
IPアドレスは信頼の証明ではありません。ただの「自己申告」に過ぎないからです。攻撃者が自身のPCで ifconfig や ip コマンドを叩き、許可されたサーバのIPを割り当てれば、スイッチはそれを疑うことなくパケットを転送します。これがIPスプーフィングの入り口です。
今日は、そんな「性善説に基づいたネットワーク」を物理的に矯正する機能、IPソースガード（IP Source Guard: IPSG）について、現場の視点から深掘りします。
—
IPソースガードとは何か？――「名札」の偽造を物理レベルで防ぐ
IPソースガードは、スイッチのポート単位で「IPアドレス」「MACアドレス」「VLAN ID」の三位一体を厳格に紐付け、合致しないパケットをハードウェア（ASIC）レベルで黙殺する機能です。
この機能のキモは、単体で動作するのではなく、DHCPスヌーピング（DHCP Snooping）という強力な相棒と連携している点にあります。
1. DHCPスヌーピングが、クライアントとDHCPサーバ間のやり取りを盗み聞きし、「どのMACがどのIPをリースされたか」をデータベース（バインディングテーブル）に記録します。
2. IPソースガードがそのテーブルを参照し、ポートに届いたパケットの送信元IPがデータベースと一致するかを検査します。
3. もし一致しなければ、パケットは即座にドロップ。CPUに負荷をかけることなく、ASICが高速で仕分けを行います。
—
シスコスイッチでの設定：実戦的なアプローチ
論よりコードです。一般的なL2/L3スイッチ（Catalyst等）での設定例を見てみましょう。
# 1. まずDHCPスヌーピングを有効化する（これがないとIPSGは機能しない）
ip dhcp snooping
ip dhcp snooping vlan 10,20
# 2. 特定のアクセスポートにIPソースガードを適用する
interface GigabitEthernet0/1
description "エンジニア用ワークステーション"
switchport mode access
switchport access vlan 10
# ここでDHCPスヌーピングを有効化
ip dhcp snooping limit rate 100
# IPソースガードの適用（IPとMACの整合性をチェック）
ip verify source vlan dhcp-snooping port-securityここで重要なのは port-security というオプションです。これを付けることで、IPアドレスだけでなく、MACアドレスの詐称も同時に防ぐ「鉄壁の防御」が完成します。
—
現場で遭遇する「罠」とトラブルシューティング
IPソースガードは強力ですが、運用を間違えるとネットワークを即座に分断する「諸刃の剣」でもあります。私がこれまで見てきたトラブルの傾向をいくつか共有します。
1. 静的IPアドレス（固定IP）の端末
サーバやプリンタなど、DHCPを使わない端末を接続している場合、そのままではIPSGが「未登録の通信」とみなしてすべてドロップします。この場合、手動でバインディングテーブルに静的エントリを追加する必要があります。
# 静的エントリの追加（IP、MAC、VLANをハードコーディング）
ip source binding 0011.2233.4455 vlan 10 192.168.10.50 interface Gi0/12. リンクの切り替わりとリース時間
DHCPのリース時間が極端に短い場合、更新に失敗すると通信が切れます。また、スイッチの再起動時にバインディングテーブルが揮発すると、クライアントが再接続するまで通信できない「デッドロック」が発生します。 ip dhcp snooping database を有効にして、フラッシュメモリ等にキャッシュを保存しておくのが鉄則です。
—
開発者が知っておくべき「API通信への影響」
Web APIを設計する際、バックエンド側でクライアントのIPベースの認証やレートリミットを実装している場合、IPSGが有効なネットワーク環境では、IP偽装による攻撃が物理的に防がれているという「安心感」を前提にコードを書くことができます。
しかし、テスト環境等で curl を使ってIP偽装のテストを行いたい場合は注意が必要です。
# 例えば、特定のIPになりすましてリクエストを投げる試験をしても…
curl -H "X-Forwarded-For: 192.168.10.100" http://api.internal/v1/data
# 物理層でドロップされている場合、パケット自体がスイッチから出て行かない。
# 「サーバが応答しない」のではなく「通信路が遮断されている」状態になる。もしアプリケーション側で疎通確認を行いたい場合は、ping や traceroute が通るか以前に、スイッチの show ip verify source コマンドで、現在そのポートがどのIPと紐付いているかを必ず確認してください。
—
まとめ：ネットワークの信頼を担保するために
IPソースガードは、決して万能なセキュリティではありません。しかし、内部不正や侵害された端末による横展開（ラテラルムーブメント）の初期段階を、L2という「一番近い場所」で止めることができます。
「IPアドレスは簡単に偽装できる」。この事実を知っているエンジニアが、物理層でそれを封じ込める設定を行う。この積み重ねこそが、強固なインフラを支える礎になります。
トラブルシュートの際は、まずは show ip dhcp snooping binding を叩く。ここからすべてが始まります。皆さんのネットワークが、今日も静かに、そして安全にパケットを運び続けることを願っています。
コメント