ネットワークの「暗黙の了解」を暴く：VLANトランクのネイティブVLANという名の地雷原
ネットワークエンジニアとして現場に立っていると、「なぜか特定のVLANだけ通信が通らない」「セキュリティ監査で設定不備を指摘された」という相談を死ぬほど受けます。その多くが、実はこの「ネイティブVLAN（Native VLAN）」の理解不足に起因しているのです。
教科書には「タグなしフレームを処理するためのもの」と一行で書かれていますが、現場のパケットフローはもっと泥臭い。今日は、この「一見地味だが破壊力のある」仕様について、実務の視点から紐解いていきましょう。
—
1. なぜ「タグなし」が存在するのか？
そもそも、IEEE 802.1Qのトランクリンクは、フレームに「どのVLANのものか」を示す4バイトのタグを挿入することで、物理線を仮想的に分割します。しかし、これだと「古い機器（タグを理解できないレガシーなL2スイッチなど）」と接続した時に通信が切断されてしまいます。
そこで登場したのが、ネイティブVLANです。トランクポートにおいて、設定されたネイティブVLANに属するフレームは、トランク上を「タグなし（Untagged）」で流すというルールです。
通信フローのリアル：パケットの「脱ぎ着」
1. Ingress（スイッチに入る時）： ポートに入ってきたタグなしフレームを、そのポートの「ネイティブVLAN ID」としてスイッチが認識する。
2. Trunk送出時： トランクポートを通る際、そのフレームのVLAN IDが「ネイティブVLAN」と一致していれば、タグを剥がして（あるいは付けずに）ケーブルに送り出す。
3. Egress（スイッチから出る時）： 受け取った対向機器側も、タグなしフレームを「ネイティブVLAN」として受け取る。
この「タグを剥がす」という挙動こそが、トラブルの温床です。
—
2. 実務で遭遇する「不一致」トラブル
最も恐ろしいのは、スイッチAとスイッチBでネイティブVLANの定義が食い違っているケースです。
- スイッチA： ネイティブVLAN 1
- スイッチB： ネイティブVLAN 99
この状態でVLAN 1のパケットを流すと、スイッチAは「タグなし」で送り出しますが、スイッチBはそれを「VLAN 99」として受け取ってしまいます。結果、VLAN 1のパケットがVLAN 99に漏洩するという、極めて深刻なセキュリティインシデント（VLANホッピング攻撃の踏み台）が発生します。
Cisco IOSでの設定例
現場での検証や構築時には、必ず両端の整合性を確認してください。
# インターフェースをトランクモードへ設定
interface GigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport mode trunk
# デフォルトはVLAN 1だが、セキュリティ対策で適宜変更する
switchport trunk native vlan 99
# 許可するVLANを明示的に絞る（重要！）
switchport trunk allowed vlan 10,20,99—
3. Web API開発者から見たVLANの可視性
インフラエンジニアだけでなく、WebアプリケーションやAPIを開発するエンジニアも、「自分がどのセグメントにいるか」を意識する必要があります。特に、コンテナ環境（Docker/Kubernetes）や仮想ネットワーク（VXLANなど）を扱う場合、下位層のVLAN設定がアプリケーションの疎通性に直結するからです。
例えば、Pythonで特定のネットワークインターフェースにバインドしてAPIのリクエストを送る際、VLAN設定が不適切だとARP解決ができず、ConnectionRefusedやNo route to hostが返ってきます。
import requests
# 特定のVLAN配下のゲートウェイやAPIエンドポイントへの疎通確認
# 注意: アプリ層からはVLANは見えないが、疎通不可はしばしばL2/L3のミス
url = "http://192.168.99.10/api/v1/status"
try:
# タイムアウトを設けて、ネットワークの遅延や不整合を切り分ける
response = requests.get(url, timeout=2)
response.raise_for_status()
print(f"ステータス: {response.json()}")
except requests.exceptions.RequestException as e:
# ここでエラーが出る場合、VLAN設定ミスによる疎通断を疑う
print(f"疎通エラー: {e}")—
4. 現場のシニアからのアドバイス：どう防ぐか
トラブルを未然に防ぎ、堅牢なシステムを構築するための鉄則を3つ伝授します。
1. ネイティブVLANをデフォルト（VLAN 1）のままにするな
- 攻撃者が最も狙うのがVLAN 1です。未使用のVLAN IDをネイティブVLANに割り当て、かつそのVLANには何もデバイスを繋がない運用が定石です。
2. switchport trunk native vlan tag コマンドを活用せよ
- 最近のスイッチOSでは、ネイティブVLANのフレームにもタグを付ける設定が可能です。これを有効にすれば、タグなしフレームを排除でき、セキュリティ強度が劇的に向上します。
3. 構成ドキュメントとの照合を自動化せよ
- 手動設定は必ずズレます。Ansible等で
ios_l2_interfacesモジュールなどを使用して、トランク設定をコード化（IaC）し、CI/CDパイプラインで定期的にドリフトチェックを行うのが現代の正解です。
まとめ
「ネイティブVLANは、何もしないのが一番の正解」という時代は終わりました。Web APIが複雑化し、マイクロサービスがネットワークを跨ぐ現在、ネットワークの「基礎の基礎」であるVLANの挙動を理解しておくことは、泥臭いトラブルシュートから脱却し、信頼性の高いシステムを構築するための最短距離です。
次にパケットが通らなくなった時、show interface trunk を叩く前に、まずはネイティブVLANの不一致を疑ってみてください。きっと、そこに答えが落ちているはずです。
コメント