VLANトランクの闇：ネイティブVLANが生むパケットの変容と、その脆弱性にどう立ち向かうか
ネットワークの現場に身を置く我々インフラエンジニアやセキュリティスペシャリストにとって、レイヤ2の挙動は「見えない空気」のようなものだ。スイッチのポートをトランクモードに設定し、IEEE 802.1Qのタグがパケットの海をスイスイと流れていく――普段は意識すらないその背後で、パケットは刻一刻と形を変えている。
特に、今日のテーマである「ネイティブVLAN（Native VLAN）」は、長年にわたってネットワーク設計者を悩ませ、数々のセキュリティインシデントを引き起こしてきた「静かなる時限爆弾」だ。
教科書的な定義はこうだ。「トランクリンク上で、タグが付いていない（Untagged）フレームをどのVLANに所属させるかを定義するもの」。しかし、パケットレベルの内部挙動、そしてゼロトラストの文脈における境界防御の観点から見ると、この「タグなしを許容する」という仕様そのものが、現代の高度なネットワークセキュリティにおいて致命的な矛盾をはらんでいることが見えてくる。
今回は、パケットの物理的な挙動から、L2/L3の境界線、そしてネイティブVLANを悪用したエクスプロイトの回避策まで、現場の泥臭い知見を交えて徹底的に解剖していこう。
—
1. パケットレベルで見るIEEE 802.1QとネイティブVLANの挙動
まずは、トランクポートを通過するパケットのミクロな世界を覗いてみよう。
通常のアクセスポートでは、デバイスから送出されたイーサネットフレームはそのままの姿でスイッチに入り、内部でVLANスタンプを押される。しかし、スイッチ間を結ぶトランクポートにおいては、複数のVLANトラフィックを多重化（Multiplexing）するため、IEEE 802.1Q規格に基づく「4バイトのタグ」がMACヘッダーの後続に挿入される。
+-------------------+-------------------+-------------------+-------------------+
| Destination MAC | Source MAC | 802.1Q Tag (4Bytes)| EtherType / Length|
| (6 Bytes) | (6 Bytes) | [TPID:PRI:CFI:VLAN]| (2 Bytes) |
+-------------------+-------------------+-------------------+-------------------+この4バイトの内訳は、TPID（Tag Protocol Identifier: 0x8100）が2バイト、PCP（Priority Code Point: 3bit）、DEI（Drop Eligible Indicator: 1bit）、そしてVLAN ID（12bit = 最大4094VLAN）で構成される。
タグの付与と剥離（Tagging & Untagging）のアルゴリズム
トランクポートにパケットが到達した際、ASIC（Application-Specific Integrated Circuit）レベルで以下のような厳密な処理が行われる。
1. トランクポートへの方向（Ingress）:
- 受信したフレームに
0x8100のTPIDが含まれている場合：ASICはその12bitのVLAN IDを読み取り、対応するVLANの内部スイッチングファブリックへ転送する。 - 受信したフレームにタグが含まれていない場合（Untagged）：スイッチは、そのポートに設定されている「ネイティブVLAN ID」を強制的に付与して内部処理に回す。
2. トランクポートからの方向（Egress）:
- 送信先のVLAN IDが、そのトランクポートのネイティブVLANと一致する場合：スイッチはパフォーマンスとレガシー機器への配慮から、あえて802.1Qタグを剥ぎ取って（Strip）から送信する。
- 一致しない場合：タグを維持したままワイヤ上に送出する。
この「ネイティブVLANのフレームはタグなしで流れる」という仕様こそが、ネットワークの利便性を保つ一方で、セキュリティ上の巨大な死角を生む原因となるのだ。
—
2. ネイティブVLANがもたらすセキュリティの脅威：ダブルタギング攻撃
なぜ、ネイティブVLANがこれほどまでにセキュリティスペシャリストから嫌われるのか。その答えが「VLANホッピング（VLAN Hopping）/ ダブルタギング攻撃（Double Tagging Attack）」である。
攻撃者がトランクポートに直結している、あるいは不正にアクセスできる環境を想定してほしい。通常のアクセスポートであれば、自分が所属するVLAN以外のトラフィックを見ることはできない。しかし、ネイティブVLANの仕様の隙をつくことで、攻撃者は異なるVLANへ自由にパケットを送り込むことが可能になる。
攻撃のメカニズム
1. 攻撃者は、自身が接続するポートのネイティブVLAN（例: VLAN 1）に属するパケットに、あらかじめ2重の802.1Qタグを仕込んだ不正なフレームを作成する。
- 外側のタグ：現在のネイティブVLAN（例:
VLAN 1） - 内側のタグ：標的のVLAN（例:
VLAN 100）
2. 攻撃者の端末から送信されたフレームが最初のスイッチのトランクポートに到達する。
3. スイッチは外側のタグ（VLAN 1）がネイティブVLANであるため、これを剥ぎ取る（Strip）。
4. 剥ぎ取られた結果、内部に残っていた2つ目のタグ（VLAN 100）が露出した状態で、次のトランクリンクへ転送（Forward）される。
5. 対向のスイッチは、残された VLAN 100 のタグを見て、ターゲットのセグメントへパケットを送り届けてしまう。
この攻撃の恐ろしいところは、上位層（トランスポート層やアプリケーション層）のセキュリティ、例えばTLSハンドシェイクや強固な認証が実装されていたとしても、レイヤ2のトポロジーそのものが欺瞞されるため、ファイアウォールやIDS/IPSのインスペクションをバイパスして内部セグメントに侵入できてしまう点にある。
—
3. ゼロトラスト時代におけるネイティブVLANの硬化（Hardening）プラクティス
現代のエンタープライズネットワークにおいて、境界防御の神話は崩壊し、ゼロトラストアーキテクチャへの移行が進んでいる。しかし、L2レイヤの脆弱性が放置されていれば、ゼロトラストの土台そのものが揺らぐ。
ネイティブVLANに起因するリスクを完全に排除するためには、インフラストラクチャ全体で徹底したハードening（硬化）を行わなければならない。具体的なCisco IOSスイッチの設定例を交えて、そのベストプラクティスを見ていこう。
実務で必須となるスイッチング設定
最大の防御策は、「すべてのトランクポートにおいてネイティブVLANを使用不可（あるいはダミーの未使用VLANに固定）にし、かつすべてのフレームにタグを強制する」ことだ。
Cisco Catalyst等の機器では、近年のOSバージョンにおいて、ネイティブVLANにタグを強制するコマンドが用意されている。
! 1. 接続するすべてのトランクポートに対してネイティブVLANのタグ付けを強制する
SW(config)# vlan dot1q tag native
! 2. トランクポートのネイティブVLANを、デフォルトの「VLAN 1」から未使用の「VLAN 999（Blackhole VLAN）」に変更する
SW(config)# interface GigabitEthernet 0/1
SW(config-if)# switchport trunk encapsulation dot1q
SW(config-if)# switchport mode trunk
SW(config-if)# switchport trunk native vlan 999
! 3. 使用するVLANのリストを明示的に許可し、不必要なVLANの伝搬を防ぐ
SW(config-if)# switchport trunk allowed vlan 10,20,30設定におけるエンジニアリングのポイント
vlan dot1q tag nativeの徹底: このコマンドにより、ネイティブVLAN宛てのコントロールプレーンおよびデータプレーンのフレームであっても、ワイヤ上では必ず802.1Qタグが付与されて流れるようになる。これにより、前述のダブルタギング攻撃の足場を完全に奪うことができる。- デフォルトVLAN（VLAN 1）の排除: Cisco機器のデフォルトである
VLAN 1は、LLDP、CDP、STPなどのさまざまなコントロールトラフィックが流れるため、攻撃者の標的になりやすい。データ通信用のトランクにおけるネイティブVLANとしては絶対に使用せず、あらかじめトラフィックが流れないようにブラックホール化したVLANを割り当てるのが鉄則だ。
—
4. トランスポート層・ネットワークパフォーマンスへの影響と最適化
「すべてのパケットにタグを強制する」「ネイティブVLANを分離する」といったセキュリティ対策は、パケットの挙動やパフォーマンスにどのような影響を与えるのだろうか。ネットワークスペシャリストとして、ここもしっかりと押さえておかなければならない。
MTU（Maximum Transmission Unit）のジレンマ
IEEE 802.1Qタグが挿入されると、通常のイーサネットフレーム（最大1500バイト）に4バイトが追加され、1504バイトに拡張される。これが、いわゆる「ベビー・ジャイアントフレーム（Baby Giant Frames）」と呼ばれる現象だ。
もし、ネットワーク機器や途中のL2スイッチ、あるいは仮想スイッチ（vSwitch）のMTU設定が標準の1500バイトに厳格に固定されている場合、4バイト超過したフレームは「巨像フレーム（Jumbo/Oversized Frame）」とみなされ、ハードウェアレベルで破棄（Drop）される。
[PC] --(1500 Bytes)-- [Switch (Trunk: +4Bytes = 1504Bytes)] --(Drop if MTU=1500)-- [Destination]パフォーマンス維持のためのTCP/IP・L2チューニング
この問題を回避し、RTT（Round Trip Time）の増加やパケットロスによるTCP再送を防ぐためには、インフラ全体でMTUの設計を見直す必要がある。
1. 物理スイッチのMTU拡張:
現代のエンタープライズスイッチは、通常1500バイト以上のフレームサイズ（例: 9198バイトや9216バイトなど）をハードウェアレベルでサポートしている。トランクポートが収容されるパス全体で、ジャンボフレームを許容する設定を施すことが望ましい。
2. Linuxカーネルおよびホスト側のMTU調整:
仮想化基盤（KVM, VMware ESXi）やコンテナネットワーク（Docker, KubernetesのCNI）において、ホスト側の仮想インターフェース（vethやbridge）のMTUを適切に設定する。
# Linuxホストのインターフェース（例: eth0）のMTUを802.1Qタグのオーバーヘッドを考慮して1500から1504（または一般的なジャイアント対応の9000）に拡張するコマンド
sudo ip link set dev eth0 mtu 1500
# もしVXLANやGeneveなどのカプセル化を併用する場合は、さらなるオーバーヘッド（50バイト以上）が発生するため、
# ホスト側でTCP MSS（Maximum Segment Size）クランピングを有効にする必要がある
sudo iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuTCP MSSクランピングを適切に設定することで、パケットがトランクリンクやトンネルを通過する際にフラグメンテーションが発生するのを防ぎ、レイテンシのスパイクを最小限に抑えることができる。セキュリティとパフォーマンスはトレードオフではない。正しい知識と適切なチューニングを行えば、堅牢性と高速性の両立は十分に可能なのだ。
—
5. 結びにかえて
ネイティブVLANは、レガシーな機器との互換性を保つために生み出された「過去の遺産」でありながら、設定を誤れば社内ネットワーク全体を崩壊させかねない強力なバックドアになり得る。
パケットの1バイト、4バイトのタグ構造に目を凝らし、スイッチのASICがどのようにフレームを処理しているのかを想像する――これこそが、真にセキュアなネットワークを構築するための第一歩である。
「動いているから触らない」というエンジニアリングの悪癖を捨て去り、今すぐインフラストラクチャのトランクポートとネイティブVLANの設定を監査してほしい。ゼロトラストの要塞は、こうした足元の大地を固めることからしか始まらないのだから。
コメント