chundev
日期：2026-03-16 環境：RDS Defender POC
POC 期間 RDS Defender 完全沒有產生警示，原因是 mirror 過來的流量帶有 Q-in-Q（雙層 VLAN tag），導致封包解析引擎無法正確解析 L3/L4 header。原廠在後端設定解開外層 VLAN 後，警示開始正常產生。
Q-in-Q（IEEE 802.1ad），又稱 Double VLAN Tagging 或 VLAN Stacking，是在標準 802.1Q VLAN tag 外面再包一層 VLAN tag 的技術。
正常 802.1Q:
┌──────────┬───────────┬─────────┬─────────┐
│ Dst MAC │ VLAN Tag │ Payload │ FCS │
│ │ 0x8100 │ (IP...) │ │
└──────────┴───────────┴─────────┴─────────┘
Q-in-Q (802.1ad):
┌──────────┬───────────┬───────────┬─────────┬─────────┐
│ Dst MAC │ Outer Tag │ Inner Tag │ Payload │ FCS │
│ │ (S-VLAN) │ (C-VLAN) │ (IP...) │ │
│ │ 0x88a8 │ 0x8100 │ │ │
└──────────┴───────────┴───────────┴─────────┴─────────┘
| 名稱 | 說明 |
|---|---|
| S-VLAN (Service VLAN) | 外層 tag，服務商或骨幹網路使用，EtherType 0x88a8 |
| C-VLAN (Customer VLAN) | 內層 tag，客戶原本的 VLAN，EtherType 0x8100 |
RDS Defender 本質上是一台 被動收流量的 server，透過 switch mirror port 接收封包進行深度封包檢測（DPI）。
Switch Mirror Port
│
▼
┌─────────────┐
│ 帶 Q-in-Q │ ← 封包有兩層 VLAN tag
│ 的封包 │
└──────┬──────┘
▼
┌─────────────┐
│ RDS Defender │ ← 解析引擎預設只認單層 VLAN
│ 封包解析器 │
└──────┬──────┘
▼
❌ L3/L4 header 偏移錯誤
❌ 無法辨識 IP/TCP/UDP
❌ 規則比對全部失敗
❌ 零警示
核心原因： 封包解析器以為 EtherType 後面緊接的就是 IP header，但實際上多了 4 bytes 的外層 VLAN tag，導致所有 offset 都錯位。
原廠表示是「後端設定要解開」，最可能的調整方式：
| 調整方式 | 說明 | 可能性 |
|---|---|---|
| ✅ 啟用 Q-in-Q 解封裝 | 在 ingestion pipeline 加入 strip outer VLAN tag 的步驟 | 🟢 最可能 |
| 設定 VLAN offset | 告訴解析引擎 L3 header 要多偏移 4 bytes | 🟡 可能 |
| 修改 capture filter | 讓 BPF filter 辨識 EtherType 0x88a8 |
🟡 可能 |
Switch Mirror Port
│
▼
┌─────────────┐
│ 帶 Q-in-Q │
│ 的封包 │
└──────┬──────┘
▼
┌─────────────┐
│ Decap 模組 │ ← ✅ 剝掉外層 S-VLAN tag
└──────┬──────┘
▼
┌─────────────┐
│ 正常單層 │ ← 現在看起來跟正常封包一樣
│ VLAN 封包 │
└──────┬──────┘
▼
✅ L3/L4 header 正確解析
✅ 規則比對正常
✅ 警示產生
本案的 mirror 架構中間有一台 Ixia NPB (Network Packet Broker) E40，Q-in-Q 最可能就是 NPB 自己加的。
在 NPB 架構中，端口分兩種角色：
| 角色 | 說明 |
|---|---|
| Network Port（網路端口） | 輸入端，接收 SPAN/TAP 過來的流量 |
| Tool Port（工具端口） | 輸出端，連接監控工具（RDS Defender、IDS、Wireshark 等） |
Tool Sharing = 多個網路來源的流量彙整後，送給同一個（或多個）監控工具。 這是 NPB 最核心的功能 — 多對多的流量分配。
Network Port A (SPAN from Core Switch) ──┐
├──→ Tool Port 1 → RDS Defender
Network Port B (SPAN from DMZ Switch) ──┤
├──→ Tool Port 2 → Wireshark
Network Port C (TAP from WAN Link) ──┘
當多個 Network Port 的流量彙整到同一個 Tool Port 時，下游工具需要分辨「這個封包從哪個來源進來」。NPB 的做法就是 Port Tagging — 在封包外面加一層 VLAN tag 標記來源：
Network Port A (VLAN 100 的封包)
│
│ NPB 加上外層 tag: S-VLAN = 10 (代表 Port A)
▼
[S-VLAN:10] [C-VLAN:100] [IP] [Payload] ← Q-in-Q 就這樣產生了
Network Port B (VLAN 200 的封包)
│
│ NPB 加上外層 tag: S-VLAN = 20 (代表 Port B)
▼
[S-VLAN:20] [C-VLAN:200] [IP] [Payload]
兩者彙整 ──→ Tool Port 1 ──→ RDS Defender
Tool Sharing 啟用（NPB 彙整多來源流量）
↓
Port Tagging 自動啟用（為了標記封包來自哪個 Network Port）
↓
封包被加上外層 VLAN tag
↓
原本單層 VLAN → 變成 Q-in-Q
↓
RDS Defender 解析失敗 → 零警示
🔍 所以不是有人刻意加 Q-in-Q，而是 Tool Sharing 功能本身就需要 Port Tagging 來區分來源，副作用就是產生了雙層 VLAN。
原始網路設備 (Switch/Router)
│
│ SPAN / TAP（封包已帶 1 層 C-VLAN tag）
▼
┌──────────────┐
│ Ixia NPB E40 │ ← ⚠️ Tool Sharing + Port Tagging 加了外層 VLAN tag
└──────┬───────┘
│ Tool Port
▼
RDS Defender ← 收到雙層 VLAN = Q-in-Q
| 來源 | 可能性 | 說明 |
|---|---|---|
| Ixia NPB Port Tagging（因 Tool Sharing） | 🟢 最高 | NPB 的標準功能，Tool Sharing 時預設啟用 |
| 上游 Switch 本身就是 Q-in-Q | 🟡 可能 | 電信級環境或 VLAN trunk 串接 |
| SPAN 設定問題 | 🟡 可能 | 某些 switch SPAN 時會保留或額外加 VLAN encapsulation |
| 方式 | 優點 | 缺點 |
|---|---|---|
| ✅ NPB 端關掉 Port Tagging | 根源解決，下游設備不需額外處理 | 失去來源 port 識別能力 |
| ✅ RDS Defender 端解封裝 | 不需動 NPB 設定（已由原廠完成） | 每台下游設備都要各自處理 |
如果只有一個 SPAN 來源，在 NPB 關掉 tagging 比較乾淨（沒有需要區分的對象）。多個來源時，則建議下游工具支援 Q-in-Q 解封裝。
遇到「流量有收到但工具沒反應」的狀況時，以下是從封包 dump 中找出 Q-in-Q 蛛絲馬跡的方法。
tcpdump -i eth0 -e -c 20
正常單層 VLAN 的輸出：
14:23:01 aa:bb:cc:dd:ee:ff > 11:22:33:44:55:66, ethertype 802.1Q (0x8100), vlan 100, ... IP 10.0.1.5.443 > 10.0.1.10.52341: ...
Q-in-Q 的輸出 — 會看到兩個 vlan 關鍵字：
14:23:01 aa:bb:cc:dd:ee:ff > 11:22:33:44:55:66, ethertype 802.1Q (0x88a8), vlan 10, ... ethertype 802.1Q (0x8100), vlan 100, ... IP 10.0.1.5.443 > 10.0.1.10.52341: ...
🔍 關鍵判斷： 同一行出現兩次
vlan，或看到 EtherType0x88a8，就是 Q-in-Q。
# 專門過濾 Q-in-Q 封包
tcpdump -i eth0 -e ether proto 0x88a8 -c 5
如果有輸出，就確認存在 Q-in-Q 封包。沒輸出代表流量都是標準 802.1Q。
當 tcpdump 沒有加 -e 時，Q-in-Q 封包可能出現異常症狀：
tcpdump -i eth0 -c 20
| 異常現象 | 說明 |
|---|---|
大量 ethertype 或 unknown protocol |
解析器被多餘的 tag 搞混 |
IP 位址看起來不合理（如 0.0.0.0、亂碼） |
offset 錯位，把 VLAN tag 的 bytes 當成 IP 解析 |
| 封包長度異常偏大或偏小 | 長度欄位也被錯位解讀 |
看得到封包數量但幾乎全是 [|ip] 截斷 |
表示 IP header 解析失敗 |
🔍 經驗法則： 如果 tcpdump 能看到封包進來，但 IP 層資訊全是亂的，八成是有額外的封裝層。
用 Wireshark 開啟 pcap 檔案後：
# 過濾 Q-in-Q 封包
vlan.double_tag == 1
# 或直接過濾外層 EtherType
eth.type == 0x88a8
在 Wireshark 的 Packet Details 面板中，Q-in-Q 封包會顯示：
Ethernet II
└─ Type: 802.1ad (0x88a8) ← 外層
802.1Q Virtual LAN (S-VLAN)
└─ ID: 10 ← NPB Port Tag
└─ Type: 802.1Q (0x8100) ← 內層
802.1Q Virtual LAN (C-VLAN)
└─ ID: 100 ← 原始 VLAN
Internet Protocol Version 4
└─ Src: 10.0.1.5
🔍 關鍵判斷： 看到兩層
802.1Q Virtual LAN就是 Q-in-Q。
tcpdump -i eth0 -XX -c 3
正常 802.1Q 的 hex（從 byte 12 開始）：
0x000c: 81 00 00 64 08 00 45 00 ...
^^^^ ^^^^ ^^^^
8100 0800=IPv4
VLAN tag
Q-in-Q 的 hex：
0x000c: 88 a8 00 0a 81 00 00 64 08 00 45 00 ...
^^^^ ^^^^ ^^^^ ^^^^
88a8 8100 0800=IPv4
外層S-VLAN 內層C-VLAN
🔍 關鍵判斷： byte 12-13 如果是
88 a8而不是81 00或08 00，就是 Q-in-Q。
# Step 1: 先確認有沒有收到封包
tcpdump -i eth0 -c 5
# Step 2: 看 Ethernet header 和 VLAN 資訊
tcpdump -i eth0 -e -c 10
# Step 3: 專門找 Q-in-Q
tcpdump -i eth0 -e ether proto 0x88a8 -c 5
# Step 4: 如果要存 pcap 給 Wireshark 分析
tcpdump -i eth0 -w /tmp/mirror-check.pcap -c 1000
# Step 5: 統計 EtherType 分佈（需要 tshark）
tshark -r /tmp/mirror-check.pcap -T fields -e eth.type | sort | uniq -c | sort -rn
tcpdump -e 可以省掉幾天的排查時間