为什么路由式 VPN 抓包永远看不到分支 VLAN 标签

在隧道接口上抓到的包永远不会显示分支的 VLAN ID，这是设计本身的特性，而不是工具的缺陷。路由式 TUN 隧道承载 IP 数据包，因此承载它们的带标签以太网帧在完成路由的那台路由器上就结束了。如果你的策略问题关乎网段，那么必须在抓包开始之前就为该问题选定传感器位置。你原本期待的 VLAN 字段，必须用你能自圆其说的上下文来替代。

看看隧道接口实际承载了什么

TUN 把 IP 数据包交给主机；TAP 交付以太网帧。路由式设计使用前者，这意味着解密后到达的数据包完全没有链路层首部，因此也没有可读取的 802.1Q 标签。途中没有任何东西被剥离，因为标签从未进入隧道。内层数据包从 IP 首部开始，所以支持 VLAN 的规则所期待的每个字段都根本不存在。

在争论抓包之前先确认接口类型，因为同一部署中的 TAP 设备行为不同，会把你引向错误结论。

ip -d link show tun0
tcpdump -i tun0 -nn -e -c 20

第一条命令打印设备类型及其标志。第二条打印前二十个数据包的链路层首部，而在 TUN 设备上输出从 IP 开始、没有以太网块，这一屏就是全部解释。

选择 TAP 也恢复不了标签。TAP 设备把帧交给网桥，标签会怎样取决于网桥的 VLAN 过滤和端口已配置的成员关系。那是另一个独立的设计决定，有它自己的失效模式。

站在三个位置中的任意一个，并接受它能看见什么

在分支以太网段上标签是存在的，但传感器只能看到该段上的本地流量。在外层 VPN 网络上 流量受到保护，观察者只能了解端点和流量大小，对内层数据包一无所知。在解密后的 TUN 路径上，内层 IP 数据包及其寻址和端口都可见，但没有分支的帧。因此，同一流量的干线抓包和路由式抓包看起来像两场不同的对话。

这三个位置回答三个不同的问题，而单次抓包不可能同时是全部三者。

tcpdump -i eth0 -nn -e 'vlan' -c 10
tcpdump -i tun0 -nn -c 10

运行这一对命令并比较。第一条在分支链路以干线接入主机的位置显示带标签的帧及其 VLAN ID；第二条显示路由之后同一场对话的普通 IP。如果第一条完全没有任何返回，就检查主机端口是否为接入端口，因为那样标签早已被交换机移除，主机上的任何抓包都不会再显示它。

用一个你能自圆其说的映射来替代缺失的标签

如果策略按 IP 前缀区分网段，就把这个映射连同它的局限一起写下来。地址范围重叠、源地址转换和共享网关，任何一项都可能让单个前缀不足以判断数据包真正来自哪里。

信任你所控制的接口和路由上下文，而不是客户端提供的标签。对端可以设置的头部字段并不能证明成员身份，把它当作证据的检查规则很容易被绕过。

ip route get 10.20.30.40
ip -br addr show

第一条命令报告内核为某个目的地址会使用的接口和源地址，这是网段归属的本地视角。第二条按接口列出地址，这样映射中的前缀就能对照实际情况而不是对照示意图来核对。

在信任结果之前，先检查返回路径和载荷

只看一个方向的检查点会漏掉一半对话，而一旦涉及 VPN，非对称路由就很常见。在把单向抓包当作完整证据之前，先确认应答经过同一个传感器。

恢复内层 IP 数据包也不会解密其中的 HTTPS 会话。如果策略问题关乎内容而不是流量，传感器位置就必须再次调整，而这个决定属于同一份设计文档。

仅仅为了让 VLAN 字段出现而把无限制的干线延伸到传感器，会扩大网络边界，却没有回答最初的问题。为策略所需的信息选择位置，记录它看不见什么，并在问题变化时重新审视这个选择。