【実務・中級編】 プライベートVLAN(Private VLAN / PVLAN)のアーキテクチャ:Primary、Isolated、Community VLAN – インフラ・物理&L2/L3ネットワーク基礎実践ガイド

プライベートVLAN(PVLAN)の深層:同一セグメントの「隣人」を完全に隔てるL2セキュリティの極意

ネットワークの現場に長く身を置いていると、「なぜか同じサブネットにいるサーバー同士が見えてしまうのが気持ち悪い」「マルチテナント環境で、お隣の客にこちらのブロードキャストトラフィックを見られたくない」といった、L2(データリンク層)ならではの切実な要件に幾度となく直面する。

通常、VLAN(IEEE 802.1Q)を切ればサブネット単位でトラフィックは完全に分離される。しかし、クラウド基盤、ホスティングサービス、あるいは厳格なPCI DSS準拠が求められる金融系システムではどうだろう。「同じアプリケーション層のグループだから同一セグネットに入れたい。けれど、サーバー同士の直接通信(L2横方向の通信:東西トラフィック)はセキュリティ上、絶対に遮断したい」――この矛盾する要求を鮮やかに解決するのが、今回解説するプライベートVLAN(Private VLAN / PVLAN)だ。

教科書的な定義をなぞるだけでは、実務の現場でハマる。今回は、Ciscoを中心としたエンタープライズスイッチの実装をベースに、Primary/Isolated/Communityの各ポートロールがパケットをどう料理しているのか、そのアーキテクチャの深淵を紐解いていこう。

—

1. PVLANの基本アーキテクチャ:なぜVLANをさらに「細切れ」にするのか?

従来のVLANは、いわば「一軒家を壁で区切る」ようなものだ。部屋(VLAN)を分ければ中は見えないが、同じ部屋にいる人間同士は自由に会話ができる。

これに対し、PVLANは「一つのVLANという共同生活スペースの中に、鍵付きの個室と、特定の仲間だけが集まるリビングルームを作る技術」だと言えばイメージしやすいだろう。PVLANでは、1つのVLANを以下の2つの要素に分解・再定義する。

  • Primary VLAN(プライマリVLAN): 外部ネットワーク(ルーターやL3スイッチのSVI)と接続するための「大元のVLAN」。外部から見ると、これは普通のVLANにしか見えない。
  • Secondary VLAN(セカンダリVLAN): プライマリVLANの下位にぶら下がり、実際に端末が収容される「細分化されたVLAN」。ここにはさらに2つの性格(ロール)が存在する。
  • Isolated VLAN(アイソレーテッドVLAN): 「完全なる孤島」。同じIsolatedポートに接続された端末同士は、お互いに一切のL2通信ができない。通信できるのは、唯一アップリンク(Promiscuousポート)側だけだ。
  • Community VLAN(コミュニティVLAN): 「同窓会グループ」。同じCommunityに属するポート同士はL2通信が可能だが、他のCommunityやIsolatedのポートとは通信できない。

この階層構造によって、同一のIPサブネットを維持したまま、L2のスイッチングテーブルレベルでトラフィックのルーティングを強制的にコントロールできるようになるのだ。

—

2. ポートの3つのロールとパケットの行く先

スイッチの物理ポート(あるいはVPCなどの論理ポート)には、PVLANを構成する上で以下の3つの役割のいずれかを割り当てる必要がある。

1. Promiscuous(P)ポート: 「無差別」の名を持つ、すべてのトラフィックを通す門番。通常はL3ルーターやデフォルトゲートウェイ、あるいはファイアウォールのインターフェースが接続される。Primary VLANに属し、すべてのSecondary VLAN(IsolatedおよびCommunity)と双方向の通信が可能。
2. Isolated(I)ポート: Isolated VLANに属するポート。ここから送り出されたフレームは、Promiscuousポートにしか向かうことが許されない。同じスイッチ上の別のIsolatedポートあてに送られたフレームは、スイッチのASICレベルで容赦なくドロップされる。
3. Community(C)ポート: Community VLANに属するポート。同じCommunity内のポート間とは通信できるが、他のグループの壁は越えられない。

通信シーケンスのリアル:Isolatedポート間の通信はどう阻まれるか?

例えば、IPアドレスが同じ /24 サブネットに属するサーバーA(Isolatedポート1)から、サーバーB(Isolatedポート2)へPingを打ったとする。パケットの動きはこうだ。

[サーバーA (Isolated)] 
       │ (1. ARPリクエスト送信: "192.168.1.2のMACは?")
       ▼
[L2スイッチ (ASIC)] 
       │ 
       ├─× [サーバーB (Isolated)] : PVLANルールによりドロップ!
       │
       └───► [ルーター / Gateway (Promiscuous)] : ゲートウェイだけがARPに応答、あるいはトラフィックを受け取る

1. サーバーAは宛先MACアドレスが分からないため、ブロードキャスト(ARP Request)を送信する。
2. スイッチは受信ポートがIsolatedであることを認識し、「このフレームはPromiscuousポート、および同じPrimaryに紐づく許可されたポートにしか転送してはならない」というPVLANの鉄則に従う。
3. 結果として、同じスイッチ上にいるサーバーBにはこのARPリクエストすら届かない。サーバーBの存在を、サーバーAはL2レイヤーで知る術を持たないのだ。

—

3. 実務で役立つ!Cisco CatalystスイッチにおけるPVLAN設定例

机上の空論はここまでにして、実際に現場で投入する設定コマンドを見ていこう。Catalystスイッチ(IOS環境)における標準的な設定手順だ。

前提条件として、VLAN 100 をPrimaryとし、VLAN 101 をIsolated、VLAN 102 をCommunityとする。

! 1. VTPモードをTransparentに変更(PVLANの設定には必須のステップ)
vtp mode transparent

! 2. VLANの作成とプライマリ/セカンダリの関連付け
vlan 100
 name WEB_PRIMARY_VLAN
 private-vlan primary
 private-vlan association 101,102  ! セカンダリVLANを紐づけ

vlan 101
 name WEB_ISOLATED_SERVER_VLAN
 private-vlan isolated

vlan 102
 name DB_COMMUNITY_SERVER_VLAN
 private-vlan community

! 3. サーバー収容ポート(Isolated)の設定
interface GigabitEthernet0/1
 description Web Server A (Isolated)
 switchport mode access
 switchport access vlan 101       ! アクセスVLANとしてセカンダリを指定
 switchport private-vlan host-association 100 101  ! Primary 100, Secondary 101
 spanning-tree portfast           ! 接続時のステニングツリー遅延を回避

! 4. サーバー収容ポート(Community)の設定
interface GigabitEthernet0/2
 description DB Server Group 1 (Community)
 switchport mode access
 switchport access vlan 102
 switchport private-vlan host-association 100 102
 spanning-tree portfast

! 5. ゲートウェイ(L3ルーターやSVI)に接続するPromiscuousポートの設定
interface GigabitEthernet0/24
 description Upstream Router / Gateway
 switchport mode private-vlan promiscuous
 switchport private-vlan mapping 100 add 101,102  ! Primary 100に対して、許可するSecondaryを指定

現場のTips:なぜ vtp mode transparent が必要なのか?

CatalystでPVLANを設定しようとして、VTP VLAN configuration not allowed when device is not in server mode というエラーを踏んだエンジニアは数しれない。PVLANのマッピング情報は標準的なVLANデータベース(vlan.dat)とは異なる構造(拡張VLANデータベース)で管理されるため、VTPサーバー/クライアントドメイン内で同期させようとするとコンフリクトを起こしやすい。そのため、実務ではVTPをTransparentモードに落としてローカル完結で設定するのが鉄則である。

—

4. 運用・トラブルシューティング時の注意点とデバッグ作法

PVLANは強力だが、レイヤー2の挙動が目に見えにくくなるため、設計や運用を誤ると「なぜか通信できない」という泥沼のトラブルを引き起こす。現場で必ず押さえておくべきポイントを挙げておこう。

① 混信・ミスマッチの検知(PVLANポートマッピングの確認)

「サーバー同士が通信できない」という問い合わせを受けた際、まず疑うべきはポートのロール設定ミスだ。以下のコマンドでスイッチ側の状態を必ず確認する。

Switch# show vlan private-vlan

Primary Secondary Type             Ports
------- --------- ---------------- --------------------------
100     101       isolated         Gi0/1
100     102       community        Gi0/2

このコマンドで、意図したポート(Gi0/1 や Gi0/2)が正しいセカンダリVLANにマッピングされているか、Promiscuousポート側がきちんとマッピングを受け入れているかを一目で確認できる。

② プロミスキーアス(Promiscuous)トランクの罠

仮想化基盤(VMware ESXiのvSwitchや、LinuxのKVM/Bridge)をPVLANのアップリンクに接続する場合、物理スイッチ側を通常のアクセスポートではなく、PVLAN Promiscuous Trunkとして構成しなければならないケースが多い。ハイパーバイザー側で複数の仮想マシンが異なるPVLANセグメントに所属してパケットを上げてくるためだ。
この際、ネイティブVLANの取り扱いや、トランク許可VLANの指定ミスによって、ルーターまでの道が断たれるトラブルが非常によく起きる。パケットキャプチャツール(tcpdump や Wireshark)をハイパーバイザー側に仕掛け、802.1Qタギングが正しく行われているかをL2レベルで追跡するスキルが求められる。

—

5. おわりに:L2の制約を愛するエンジニアへ

クラウドネイティブ全盛の今、VLANやスイッチのポート設定といった物理・L2レイヤーの話題は、ともすれば「インフラ専門業者に丸投げする領域」と思われがちなのかもしれない。

しかし、マルチテナントのセキュリティ境界を設計する際や、KubernetesのCNIやベアメタルサーバーのマルチテナント隔離において、このPVLANが持つ「同一サブネット・物理的同居でありながら論理的に完全隔離する」という思想は、今なお色あせることなく生き続けている。

パケットがスイッチのASICを通過するコンマ数秒の間、どのポートロールが適用され、どのフレームがドロップされ、どれが上流のルーターへ導かれるのか――その頭の中のルーティング・テーブルを正確に描ききれるかどうかが、優れたネットワークエンジニアと、そうでない者を分ける境界線だ。

日々のインフラ運用の片隅で、この「見えない壁」の仕組みを思い出していただければ幸いである。

コメント

タイトルとURLをコピーしました