L2の「境界線」を設計せよ：プライベートVLANが守るマルチテナントの聖域
ネットワークエンジニアとしてキャリアを積んでいくと、必ず一度はぶつかる壁がある。それは「同一サブネット内のホスト間通信をどう制御するか」という課題だ。
通常、L2スイッチにおいて同一VLAN内のホストは、ARPを介して直接通信できてしまう。セキュリティ要件が厳しいデータセンターや、顧客ごとに環境を分ける必要があるプロバイダ環境において、これは致命的な脆弱性になり得る。ここで登場するのが プライベートVLAN (PVLAN) だ。
今日は、教科書的な定義をなぞるのではなく、パケットがスイッチのASICをどう通過し、なぜこれが「最強のL2分離」と言われるのか、現場の視点から紐解いていこう。
—
1. PVLANの「3つの顔」を理解する
PVLANを理解する鍵は、VLANに「階層」という概念を持ち込んだ点にある。従来のVLANがフラットな空間だったのに対し、PVLANは以下の3つの役割を定義する。
- Primary VLAN: 外部ネットワーク（ルーターやゲートウェイ）と通信するための「親」。
- Isolated VLAN: 孤島。同じVLAN内の他のポートとは通信できず、常に
Primaryとだけ通信可能。 - Community VLAN: 同じコミュニティIDを持つポート同士なら通信可能だが、他のコミュニティとは隔離される。
これらを組み合わせることで、「外とは話せるが、隣とは話せない」という、クラウド環境におけるマルチテナント分離の基本要件をL2レベルで強制できるのだ。
—
2. 現場で役立つCisco Catalyst設定の勘所
PVLANの設定でハマりやすいのが、Promiscuous（混在）ポートの扱いだ。これは一般的にルーターやファイアウォールのインターフェースを接続する。「何でも受け入れる」ポートであり、ここを通らなければ外には出られない。
以下は、VLAN 10 を Primary とし、VLAN 100 を Isolated として設定する典型的な例だ。
# 1. Primary VLANの作成とマッピング
vlan 10
private-vlan primary
private-vlan association 100 # 100を紐付ける
# 2. Isolated VLANの設定
vlan 100
private-vlan isolated
# 3. インターフェースへの適用（物理ポート設定）
interface GigabitEthernet0/1
description Router_Uplink
switchport mode private-vlan promiscuous
switchport private-vlan mapping 10 100 # PrimaryとIsolatedを紐付け
interface GigabitEthernet0/2
description Tenant_Server_A
switchport mode private-vlan host
switchport private-vlan host-association 10 100 # サーバーはここに参加ここで重要なのは、switchport private-vlan host-association を忘れると、疎通が取れないばかりか、トラブルシューティングでパケットがどこで捨てられているかを探す羽目になることだ。show interface status でポートの状態を常に確認する癖をつけておこう。
—
3. 実務的な検証：Pythonで疎通を確認する
インフラ運用において、「疎通確認」は自動化の第一歩だ。特定のテナントが意図通りに隔離されているかを確認するスクリプトを書いてみよう。Isolated な環境であれば、同じサブネット内の別のIPに対して ping や curl を打っても、タイムアウト（または ARP 解決失敗）になるはずだ。
import os
import subprocess
def check_reachability(target_ip):
# pingで疎通確認。Isolated環境なら失敗するのが正解
response = subprocess.run(["ping", "-c", "2", "-W", "1", target_ip],
capture_output=True)
if response.returncode == 0:
print(f"[!] 警告: {target_ip} への到達が確認されました。分離設定を確認してください。")
else:
print(f"[OK] {target_ip} への通信はブロックされています。期待通りの挙動です。")
# 同一VLAN内の他のサーバーIP
target_server = "192.168.10.50"
check_reachability(target_server)Web APIの開発者であれば、この背後にあるネットワーク構造を意識してほしい。あなたのサービスが Isolated な環境に配置されている場合、マイクロサービス間の通信は直接行うのではなく、必ず Primary VLAN（あるいはゲートウェイ経由）での通信を前提とした設計が必要になる。
—
4. トラブルシューティングの極意
PVLANで通信ができないとき、私が最初にチェックするのは以下の3点だ。
1. ARPテーブルの汚染: スイッチを跨ぐ場合、古いMACアドレステーブルが残っていないか？ clear mac address-table dynamic を迷わず実行せよ。
2. VTPモード: VTPのバージョンが古いと、Private VLAN の情報を正しく同期できないことがある。基本は VTP Transparent モードでの運用を強く推奨する。
3. トランクポートの許可: Primary と Isolated を別のスイッチに跨いで接続する場合、トランク側で両方のVLANが allowed されているか？ どちらか片方でも欠ければ、通信は即座に寸断される。
まとめ：L2を制する者は、クラウドを制す
PVLANは、高度なルーティングやファイアウォールを導入する前の「最後の一線」として非常に強力だ。設計の美しさは、シンプルであること。必要以上に複雑なCommunity VLANを重ねるよりも、まずは Isolated で物理的に分離し、必要な通信だけをルーター経由で許可する（Hairpinning）という設計が、運用フェーズでのトラブルを激減させる。
ネットワークのパケットは嘘をつかない。理論を理解し、CLIで設定を叩き、Pythonで挙動を検証する。この泥臭いプロセスの先にこそ、盤石なインフラが構築できるのだ。
さあ、次はあなたのスイッチで設定を確認してみよう。意図しない通信が流れていないことを確認する、それがプロフェッショナルの第一歩だ。
コメント