こんにちは、シニアネットワークエンジニアの私です。
Web APIの設計やモダンなクラウドインフラの構築に日々奔走している皆さん、ふと「下回り」のレイヤー、つまりL2スイッチの世界に目を向けることはあるでしょうか？ 「コンテナが通信できない」「VPC間のルーティングがおかしい」といったトラブルシューティングの沼にハマったとき、最終的に私たちを救うのは、パケットがワイヤー上をどう流れているかという泥臭い基礎知識です。
今回は、そんな基礎の中でも「ネイティブVLAN（Native VLAN）」を取り上げます。IEEE 802.1Qトランクの裏道とも言えるこの仕様が、なぜ現在でもセキュリティの急所になり得るのか。実務で使えるコンフィグやパケットの挙動を交えて、徹底的に紐解いていきましょう。
—
1. ネイティブVLANとは何か？（IEEE 802.1Qの歴史的背景）
私たちが普段使っているイーサネットは、本来「タグ」の概念を持たないフラットな世界でした。しかし、ネットワークの規模が拡大するにつれ、1つの物理回線を複数の論理ネットワークに分割する「VLAN（Virtual LAN）」が必須となり、IEEE 802.1Qという標準規格が策定されました。
802.1Qトランクポートは、複数のVLANに属するフレームを多重化して対向スイッチへ送受信します。その際、イーサネットヘッダーの送信元MACアドレスの直後に、4バイトの「VLANタグ（TPID 0x8100 ＋ TCI）」を挿入するのが基本動作です。
しかし、ここで一つのレガシーな問題が生じました。
「VLANを認識しない古いハブや、タグ処理をサポートしていない機器（IP電話やルーターの一部など）がトランクリンクの対抗にいたら、どう通信するのか？」
この後方互換性を担保するために生まれたのがネイティブVLANです。
ネイティブVLANの仕様と挙動
ネイティブVLANに指定されたVLAN（Ciscoデフォルトでは VLAN 1）に属するフレームがトランクポートを通過する際、スイッチはあえてVLANタグを「付与せず（Untagged）」に送信します。そして、対向のトランクポート側でタグなしフレームを受信した際、「これはどのVLAN宛てのフレームか？」と迷うことなく、あらかじめ設定されたネイティブVLANのものとして処理します。
つまり、トランクリンク上には「タグ付きフレーム」と「タグなしフレーム」が混在することになるのです。
—
2. 通信フロー：トランク上を流れるパケットの現実
言葉だけではイメージしにくいので、スイッチAとスイッチBの間を結ぶトランクリンク上で、パケットがどのように処理されるかシーケンスを見てみましょう。
[PC A (VLAN 10)] ---> (Access Port) [Switch A] (Trunk Port)
|
|--- VLAN 10 のフレームには [Tag: 10] を付与して送信
|--- ネイティブVLAN (VLAN 1) のフレームは [Tagなし] で送信
|
(Trunk Port) [Switch B] (Access Port) ---> [PC B (VLAN 1)]1. VLAN 10（タグ付きVLAN）の通信:
- PC Aから送られたイーサネットフレームがSwitch Aに入ると、ポートの設定に基づき
VLAN 10のタグが付与されます。 - トランクリンク上を流れる際も
[Tag: 10]が維持されます。 - Switch Bのトランクポートに到達すると、タグを剥がして適切な
VLAN 10のアクセスポートへ転送します。
2. VLAN 1（ネイティブVLAN）の通信:
- PC B（VLAN 1に属する）から送られたフレームがSwitch Aに入ります。
- ここで、このポートに割り当てられたネイティブVLANが
VLAN 1である場合、Switch Aは「お、これはネイティブVLANだからタグを付けなくていいんだな」と判断し、タグを一切付与せずにそのままトランク回線へ送り出します。 - 対向のSwitch Bがタグなしのフレームを受信すると、「タグがない＝ネイティブVLAN宛てだ」と解釈し、自身の設定にあるネイティブVLAN（例:
VLAN 1）へフォワードします。
—
3. なぜ危険なのか？ ネイティブVLANが孕む脆弱性
この「タグを付けない」というレガシーな親切設計こそが、セキュリティエンジニアの頭を悩ませる最大の原因です。代表的な脆弱性として「VLANホッピング攻撃（VLAN Hopping Attack）」があります。
二重タギング攻撃（Double Tagging Attack）のメカニズム
攻撃者は、ネイティブVLANの仕様の隙を巧みに突き、本来アクセス権のない別のVLANへパケットを送り込もうとします。
1. 攻撃者の前提条件:
- 攻撃者が接続しているアクセスポートの所属VLANが、スイッチ間のトランクのネイティブVLANと一致していること。（Ciscoのデフォルトである
VLAN 1をそのまま放置している環境がこれに該当します）
2. パケットの偽装:
- 攻撃端末は、自分が属するVLAN（例: ネイティブVLANの
1）のタグと、侵入したい標的のVLAN（例: 機密データがあるVLAN 100）のタグという、二重のタグがついた不正なイーサネットフレームを作成し、スイッチへ送信します。
3. 1段目の剥離（スイッチA）:
- スイッチAは、最初のトランク（またはアクセス）ポートで外側のタグ（ネイティブVLANである
1）を「お、これはネイティブVLAN宛てのタグなし（または外側タグ）だな」と剥がしてしまいます。このとき、内側に隠れていた[Tag: 100]はそのまま残されます。
4. 2段目の通過と侵入（スイッチB）:
- スイッチAは、タグが1枚剥がれた状態（内側の
[Tag: 100]のみが残った状態）のフレームをトランクリンクへ送り出します。 - 対向のスイッチBは、流れてきたフレームに
[Tag: 100]がついているのを見て、「おっ、これはVLAN 100向けの正規のトラフィックだ」と誤認し、VLAN 100のセグメントへ転送してしまいます。
結果として、攻撃者はVLANの壁をやすやすと飛び越え、本来隔離されているはずの基幹系ネットワーク等へアクセスできてしまうのです。
—
4. 実務での対策：セキュアなインフラ構築・設定例
この脆弱性を塞ぐための王道かつ絶対的なプラクティスは、以下の2点です。
1. ネイティブVLANをデータ通信に使わない（ダミーのVLAN IDに追放する）
2. トランクポートにおけるネイティブVLANの「タグ強制（Native VLAN Tagging）」を有効にする
実際のCisco IOS/IOS-XEスイッチにおける、モダンでセキュアな設定例を見てみましょう。
実機設定サンプル (Cisco CLI)
! ----------------------------------------------------
! 1. トランクポートの基本設定と、ネイティブVLANの変更
! (デフォルトのVLAN 1を使用せず、未使用のVLAN 999等に割り当てる)
! ----------------------------------------------------
interface GigabitEthernet0/1
description === Uplink to Core Switch ===
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,30
! ----------------------------------------------------
! 2. グローバルでネイティブVLANのタグ付けを強制する
! (Cisco IOS 15.0以降などでサポート)
! ※対向機器も対応している必要がある点に注意
! ----------------------------------------------------
vlan dot1q tag nativeインフラ運用の現場におけるTips
- ネイティブVLANの不一致（Native VLAN Mismatch）に注意:
リンクの両端でネイティブVLANのIDが異なっていると、Ciscoスイッチであれば CDP (Cisco Discovery Protocol) が検知してコンソールに警告ログ（%CDP-4-NATIVE_VLAN_MISMATCH）を出力しますが、他社製機器との接続やCDPを無効化している環境では、サイレントに通信障害（ループやパケットロス）を引き起こします。運用ドキュメントには必ず両端のネイティブVLAN IDを明記しましょう。
- クラウド環境（AWS VPC / Azure VNet等）における扱い:
AWSのDirect ConnectやAzure ExpressRouteなどの仮想専用線サービスにおいて、L2トランクを直接提供するケースは稀ですが、NFV（ネットワーク仮想化アプライアンス）をEC2上にデプロイして独自に802.1Qを処理させる場合があります。その際も、クラウド側のルーターや仮想スイッチがネイティブVLANのタグなしフレームをどうハンドリングするか、あらかじめクラウドのドキュメントで仕様を確認することが極めて重要です。
—
まとめ
ネイティブVLANは、レガシーな互換性を維持するために作られた「歴史的遺産」のような仕様です。しかし、その利便性の裏側には、設定の不備を突かれた瞬間にネットワーク全体を危険に晒すアキレス腱としての側面が隠されています。
「デフォルトだから VLAN 1 のままでいいや」という油断が、大規模なセキュリティインシデントの引き金になることも少なくありません。インフラエンジニアとして、スイッチのポート設定一枚にまで意味を持たせ、セキュアな設計を貫くこと。それこそが、堅牢なネットワークシステムを守り抜くプロフェッショナルの仕事です。
日々の運用管理やIaC（Infrastructure as Code）のコードレビューの際、ぜひネイティブVLANの指定が適切に行われているか、改めて確認してみてください。
コメント