为什么你的 VPN 传感器永远看不到分支的 VLAN 标签

VPN 一侧的传感器把两个分支 VLAN 看成普通 IP 流量，而在各自线路上标识分支的标签已经消失。这正是路由型隧道所做的事：它恢复数据包，而不是恢复送达它们的以太网帧。这个标签缺失是否要紧，完全取决于你向传感器提出的问题。按顺序做完下面四项检查，你就能知道哪个观察点可以回答它。

第一步：先确认隧道究竟恢复了什么

TUN 接口承载 IP 数据包，因此分支帧的 VLAN 头止步于把流量压入隧道的那台路由器。 TAP 接口承载以太网帧，这意味着当桥和 VLAN 准入规则放行时，标签可以存活下来。 在推断抓包应当包含什么之前，先读接口类型。

两种选择都不是缺陷。两套设计回答的是不同的问题，标签也留在不同的位置。

自己确认接口类型，而不是从产品名称里推断。链路详情会写明设备类型并显示当前生效的标志，而在 TUN 设备上抓包，不会因为你提出了要求就凭空长出以太网头。如果 TUN 抓包里仍出现标签，你几乎肯定是在读另一个接口，或者读一个把帧封在载荷内部的隧道。在继续之前，先记录自己属于哪一种情况。

第二步：把传感器放在对象仍然存在的位置

三个位置覆盖了大多数路由型设计：分支的以太网段、隧道两端之间的外层网络，以及隧道处理之后的路径。每个位置看到的对象都不同，而标签只存在于第一个位置。选择传感器位置，是在决定策略需要哪个对象，而不是图方便。

用表能回答的说法把策略问题提出来，它通常会自行解决。如果规则需要知道数据包来自哪个分支，下游的前缀映射也许够用，但前提是那份映射始终精确且无歧义。如果规则需要知道帧到达了哪个端口，你就需要第一个位置，因为下游任何环节都无法重建它。习惯性地放置传感器、而不是照着问题放置，正是团队最终去索要设计从未承载过的字段的原因。

承载以太网的隧道是另一套设计，需要单独检查两端保留了或改写了什么。只选 TAP 本身仍然没有定义桥、VLAN 准入规则或检查策略。

第三步：争取来源上下文，而不是信赖它

每个分支一个地址段，是 VLAN 身份的常见替代，它只在一对一映射下成立。重叠的前缀、转换和共享网关，各自都会打破这个假设，表现出来的样子更像数据质量问题，而不是设计问题。把映射连同边界写下来，并说明同时匹配两行的数据包会发生什么。同时出现在两个分支的前缀，应该是你能检出的错误，而不是你接受的抛硬币。

客户端提供的上下文不是成员身份的证明。它是一种声明，应该放在另一栏里。

在区别真正要紧的地方，用你自己掌控的关联数据：哪个隧道实例接受了连接、数据包从哪个接口进来、本地路由表对该对端怎么说。客户端提供的标签是有用的线索，也是无用的授权输入。如果传感器无法从自身一侧确立关联，策略需要的是更宽的规则，而不是自信的猜测。

第四步：确认回程路径，以及解密到底漏掉了什么

只看一个方向的传感器照样可能显得健康，因为请求仍在按时到达。要显式检查回程路径，而且要针对同一条流，而不是泛泛的可达性。半双工的可见性，会让你据此得出的任何有状态结论都出现无声缺口。

恢复内层 IP 流量，也不等于看到了里面的应用，因为跑在隧道上的 TLS 仍然是 TLS。

ip -d link show tun0
tcpdump -i tun0 -n -e -c 5

这两条命令能回答接口问题，也能显示抓包真正包含什么，比争论架构更快。换成你的设计所用的接口名，并在你关心的流活跃时运行抓包。当 TUN 设备上没有出现任何标签时，结论是这套设计选择了路由而不是桥接，而不是传感器丢了数据。然后要么把传感器移到能看到标签的位置，要么按当前位置能支撑的说法重写规则。