IPソースガードの深層：MAC/IPバインディングとスイッチハードウェアの裏側で何が起きているのか
ネットワークエンジニアとして幾度となく修羅場をくぐり抜けてくると、「レイヤー2の信頼」がいかに儚いものであるか痛感させられる。ARPスプーフィング、DHCPスターベーション、そしてIPスプーフィング。これらは古典的な攻撃手法でありながら、内部ネットワークのセキュリティ境界が曖昧になった現代においても、L2セグメントにおける最も厄介な脅威として君臨し続けている。
ポートセキュリティ（Port Security）はMACアドレスの学習数を制限し、DAI（Dynamic ARP Inspection）はARPキャッシュの毒入れを防ぐ。しかし、それだけでは足りない。パケットのペイロードを運ぶIPレイヤーの「顔（ソースIPアドレス）」を偽装された場合、スイッチのASIC（Application-Specific Integrated Circuit）はどう判断するべきか。
ここで登場するのが IPソースガード（IP Source Guard: IPSG） だ。
今回は、教科書的な機能説明は最小限に留め、ASICのTCAM（Ternary Content-Addressable Memory）レベルでの挙動、DHCPスヌーピングとの不可分な関係、そして極限のトラフィック環境下におけるセキュリティとパフォーマンスのトレードオフについて、プロの視点から徹底的に解剖していく。
—
1. パケットレベルで見るIPソースガードのメカニズム
IPソースガードが有効なアクセスポートにホストからのフレームが着信した瞬間、スイッチのASIC内部ではミリ秒（あるいはナノ秒）単位のハードウェア処理パイプラインが走る。
通常のL2スイッチングは、着信フレームの宛先MACアドレス（DA）をL2転送テーブル（MACアドレステーブル）と照合して出力ポートを決める。しかし、IPソースガードが有効なポートでは、送信元MACアドレス（SA）、送信元IPアドレス、そしてVLAN IDの3要素（あるいはこれにポート番号を加えた4要素）が厳密に検証される。
[ホスト] -> ( Ethernetフレーム: SA=AA:BB:CC:... / SIP=192.168.1.50 ) -> [IPSG有効スイッチポート]
|
+-----------------------+
| ASICハードウェア検証 |
+-----------------------+
| 1. L2/L3バインディングDB照会
| 2. TCAMエントリとの一致確認
+-----------------------+
/ \
(一致: 正常転送) (不一致: 即座にDrop)もし、悪意あるユーザーが自身のPCのIPアドレスを勝手に 192.168.1.100 （ゲートウェイや重要サーバーのIP）に書き換えてトラフィックを送出したとしよう。ソースMACアドレスは自身の本物であっても、IPソースバインディングデータベース（後述のDHCPスヌーピングデータベース等）に登録されている「このポートに許可されたIP」と一致しないため、ASICはパケットを即座にハードウェアレベルでドロップ（Deny）する。
CPUに処理を渡すことなくラインレート（Line-rate）で破棄されるため、CPU使用率を跳ね上げることもなく、DDoSの踏み台化を根底からへし折ることができる。
—
2. DHCPスヌーピングとの共依存関係
IPソースガードを語る上で欠かせないのが、DHCPスヌーピング（DHCP Snooping）だ。
IPソースガードのバインディングデータベースは、主にDHCPスヌーピングが動的に学習したリース情報（IPアドレス、MACアドレス、リース期間、VLAN、ポート）を参照して構築される。
Cisco CatalystやNexus、あるいはLinuxベースのブリッジ環境（ebtables / nftables）において、このバインディングがどのように機能するか、具体的な設定例を見てみよう。
以下は、Cisco IOSにおける標準的なIPソースガード（IP + MACバインディング検証）の構成例だ。
! --- 1. グローバルでDHCPスヌーピングを有効化 ---
ip dhcp snooping
ip dhcp snooping vlan 10,20
! --- 2. アップリンク（信頼できるルーター側）ポートの設定 ---
interface GigabitEthernet0/1
description Trust_Port_to_Core_Router
ip dhcp snooping trust
! --- 3. エンドホスト接続ポートでDHCPスヌーピングとIPソースガードを有効化 ---
interface GigabitEthernet0/2
description Access_Port_for_Client_PC
switchport mode access
switchport access vlan 10
ip dhcp snooping limit rate 15
ip verify source port-securityここで注目すべきは ip verify source port-security というコマンドだ。
このコマンドを指定することで、IPソースガードは単なるIPアドレスの検証だけでなく、ポートセキュリティと連動し、ソースMACアドレスの整合性まで同時にチェックするようになる。DHCPを使用しない静的IP環境の場合は、手動でバインディングエントリ（ip source binding）を静的に流し込む必要がある。
—
3. 実務で直面する罠：静的IP環境とパフォーマンスのトレードオフ
「セキュリティを厳格にしたいから、すべてのポートでIPソースガードを有効にする」というのは、インフラアーキテクトの初期衝動としては理解できるが、現場の運用を見据えるといくつかの深刻な落とし穴が存在する。
トラブルシューティングの文脈：DHCPを使わない機器の存在
工場ラインのPLC、ネットワークプリンター、あるいは静的IPが必須なレガシーサーバーを接続した瞬間、IPソースガードは容赦なくそれらの通信をブラックホール送りにする。DHCPパケットをやり取りしないため、バインディングデータベースにエントリが登録されず、すべてのトラフィックがドロップされるからだ。
これに対する現場の処方箋は、スタティックバインディングの明示的な定義である。
! DHCPを使わない固定IPサーバー（IP: 192.168.10.50, MAC: 00:11:22:33:44:55）をGi0/24に収容する場合
ip source binding 0011.2233.4455 vlan 10 192.168.10.50 interface GigabitEthernet0/2数百台規模の静的IPデバイスがある環境でこれを手動運用するのは、ヒューマンエラーの温床であり、エンジニアのメンタルをすり減らす原因になる。APIやAnsible等を用いた構成管理（IaC）のパイプラインに組み込むことが実務上必須となる。
ASIC資源（TCAM）の枯渇問題
ハイエンドなスイッチであっても、ハードウェアのTCAMサイズには物理的な限界がある。IPソースガードが有効なポートが増え、バインディングエントリが爆発的に増加すると、スイッチのハードウェアリソースを圧迫する。
特に、仮想化基盤（VMware ESXiのvSwitchやKVMのブリッジ）の下で多数の仮想マシン（MAC/IPのペア）が頻繁にライブマイグレーションや動的生成・消滅を繰り返す環境では、バインディングの追従遅延やTCAMフラグメンテーションを引き起こすリスクがある。
したがって、アーキテクトは「どのレイヤーまでセキュリティを強制すべきか」の境界線を明確に見極めなければならない。一般的には、アクセスレイヤー（L2スイッチの端点）でIPソースガードをかけ、ディストリビューションやコアレイヤーではルーティングとACLによる大局的なフィルタリングに任せるという役割分担が定石である。
—
4. Linuxカーネル / 仮想スイッチにおけるIPソースガードの再現
Cisco等の専有ハードウェアだけでなく、現代のコンテナやクラウドネイティブ、あるいはLinuxルーターベースの環境でも、同様の概念（IP/MACスプーフィング防止）は極めて重要である。
例えば、Linuxのブリッジ環境や仮想化基盤において、ebtables や nftables、あるいはブリッジの hairpin_mode や rp_filter（リバースパスフィルタリング）を組み合わせることで、ソフトウェア的に同等の保護を実装できる。
以下は、Linuxのブリッジインターフェイスにおいて、特定のMACとIPのペア以外の送信元パケットをドロップする ebtables / iptables の概念的なアプローチの断片である。
# ブリッジ環境において、特定のMACアドレスからの偽装IPパケットをブロックする例
# 1. まずMACアドレスベースでフィルタリング（ebtables）
ebtables -A FORWARD -p IPv4 --source-mac ! 52:54:00:12:34:56 -s 192.168.100.10 -j DROP
# 2. カーネルレベルでのリバースパスフィルタリング（RPフィルター）の有効化
# 送信元IPが、ルーティングテーブル的にそのインターフェイスから到達可能か厳密に検証
sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.eth0.rp_filter=1クラウド環境（OpenStackやAWS等のセキュリティグループ / VPCテナント分離）でも、ハイパーバイザー側のvSwitch（OVS: Open vSwitchなど）で同様のアンチスプーフィング（Port Security）がデフォルトで有効化されている。これらはすべて、L2/L3のバインディング検証というIPソースガードと同一の思想に基づいている。
—
5. まとめ
IPソースガードは、派手さはないが、エンタープライズネットワークの足元を固める極めて堅牢な礎である。
「動かない」というトラブルシューティングの多くは、DHCPスヌーピングの信頼ポートの設定漏れや、静的IPデバイスに対するバインディングの欠落という、基本に起因する。しかし、その内部挙動（ASICによるラインレートでのステートレス検証）を正しく理解していれば、パケットキャプチャを開いた瞬間に「あ、これはバインディングテーブルのミスマッチだ」と秒速で原因を特定できるはずだ。
プロトコルの深淵を愛する者として、私たちは単に「おまじない」のように機能を有効化するのではなく、パケットがスイッチのシリコン内部でどのように解釈され、どのように裁かれているのかを常に脳内ビジュアライズできなければならない。
セキュアで冗長なネットワークの構築は、こうした泥臭いレイヤーの積み重ねの上にのみ成り立つのである。
コメント