Pi 上的 MAC 地址变了：究竟是哪个接口？

在 Pi 上落地一套 VPN 之后，多个接口身份看起来像是挪了位。昨天的以太网地址对不上今天的列表，于是结论自动写就：VPN 改了 MAC。通常并没有。拿物理上行链路去和网桥或虚拟适配器对比，根本算不上对比；第一件事是弄清你究竟在看哪个对象。

先写清接口和观察者

写下设备名、接口类型、当前链路层地址，以及拥有它的管理器。再补上时间戳，因为开机时变化的显示，和隧道起来时变化的显示是两个不同事件。

对同一个接口，在连接事件前后各做一次。对同一个对象的两次观测才是证据；对两个对象各观测一次，只是附会了故事的巧合。这个差别就是整个排查。对象搞错，后面每次测量都是白费。

如果 DHCP 保留地址是问题的一部分，就记下分配器实际收到的是哪个客户端身份。桌面列表、网桥身份和旧的租约记录是三份不同的记录，只有一份是路由器看到的。

TUN、TAP 与上行链路是不同对象

内核在两类虚拟设备之间划了硬线。TUN 承载 IP 包，根本没有以太网身份。TAP 承载以太网帧，因此有身份。

也就是说，TAP 一侧的地址不是物理上行链路的地址，经过路由的 TUN 地址也不是 Wi-Fi MAC 的替代品。它们是同一台机器的不同层次。

网桥是第三个对象。它有自己的链路层地址，该地址独立于挂在它上面的端口而推导或配置，所以网桥起来时可以在不碰任何硬件的情况下改变列表的显示。端口在它下面各自保留地址。它的地址也可以显式设置，那种情况下它身上没有任何东西来自硬件。

真实变更到底归谁

如果同一块物理接口真的换了地址，先看当前活动的连接配置，再下结论。隐私设置、克隆设置和重新创建的虚拟设备都会产生这个症状，与 VPN 无关。

时间上接近不等于因果。隧道启动和配置被重新应用常常发生在同一秒，因为一个触发了另一个，而地址变更属于那份配置。先读配置，再读隧道日志。

也要把重新创建的接口和已存在的设备区分开。持久配置和运行时接口是相互关联的对象，两者都不是永久的硬件身份。

管理器的克隆值意味着什么

NetworkManager 的以太网设置参考把显式指定的地址与 preserve、permanent、random、stable 这类特殊值区分开来，这些值在命令行和 D-Bus 接口上的写法并不相同。

那些值只是某一个管理器支持的能力。它们不能证明这个镜像运行的就是那个管理器、这份配置用了随机化，或者某个 VPN 进程改写了网卡。只有本机上的活动配置能回答这一点。

去查这个设置归谁管，而不是为了让设置可用再装一个管理器。两个管理器抢同一块接口，恰好制造出人们随后甩给隧道的那个不稳定。

修的是身份要求，不是显示

需要本地保留地址时，就按分配器自己的客户端身份机制来，并让它与接口的配置方式一致。为了列表看起来稳定去钉一个无关的网桥或隧道地址，什么也解决不了，还会造出第二个没人记录过的身份。

远程路由式 VPN 认证自己的对端，并按自己的模型分配地址。冻结一个 LAN 地址既不会登记那个对端，也不会建立固定的隧道分配。

在获准变更身份之前，要让旧配置可回滚，尤其是在你没法走过去操作的无头机器上。重连之后再验证同一个接口和同一个本地服务。

值得记下的结论是：哪个对象变了、谁配置的、这是否违反了你想要的身份约定。比这更宽的说法，都是披着结论外衣的猜测。范围窄的结论也更容易通过评审。