Una dirección MAC cambiada en una Pi: ¿qué interfaz ha cambiado?

Después de que una configuración de VPN aterrice en una Pi, varias identidades de interfaz pueden parecer desplazadas. La dirección Ethernet de ayer ya no coincide con la lista de hoy, y la conclusión se escribe sola: la VPN cambió la MAC. Normalmente no lo hizo. Comparar un enlace físico con un puente o un adaptador virtual no es una comparación, y la primera tarea es decidir a qué objeto está mirando en realidad.

Nombre la interfaz y el observador

Anote el nombre del dispositivo, el tipo de interfaz, la dirección actual de la capa de enlace y el gestor que la posee. Añada la marca de tiempo, porque una visualización que cambió al arrancar es un evento distinto de una que cambió cuando subió el túnel.

Hágalo para la misma interfaz antes y después del evento de conexión. Dos observaciones de un objeto son prueba; una observación de dos objetos es una coincidencia con una historia pegada. La diferencia es toda la investigación. Si se equivoca de objeto, cada medición posterior es tiempo perdido.

Si una reserva DHCP forma parte del problema, anote qué identidad de cliente recibió realmente el asignador. Una lista de escritorio, una identidad de puente y una entrada antigua de concesión son tres registros distintos, y solo uno de ellos es lo que vio el enrutador.

TUN, TAP y el enlace son objetos distintos

El kernel traza una línea dura entre los dos tipos virtuales. TUN transporta paquetes IP y no tiene ninguna identidad Ethernet. TAP transporta tramas Ethernet y, por tanto, sí la tiene.

Eso significa que una dirección del lado TAP no es la dirección del enlace físico, y que una dirección TUN enrutada no es un sustituto de la MAC del Wi-Fi. Son capas distintas de la misma máquina.

Un puente es un tercer objeto. Tiene su propia dirección de capa de enlace, derivada o configurada con independencia de los puertos conectados a él, así que un puente que sube puede cambiar lo que muestra un listado sin tocar ningún hardware. Los puertos conservan sus propias direcciones por debajo. Su dirección también puede fijarse explícitamente, y entonces nada de ella deriva del hardware.

Quién posee realmente un cambio real

Si la misma interfaz física cambia de dirección de verdad, mire el perfil de conexión activo antes de asignar una causa. Los ajustes de privacidad, los de clonación y un dispositivo virtual recreado producen ese síntoma sin intervención alguna de la VPN.

La cercanía en el tiempo no es causalidad. Un túnel que arranca y un perfil que se vuelve a aplicar suelen ocurrir en el mismo segundo porque uno desencadenó al otro, y el cambio de dirección pertenece al perfil. Lea el perfil antes de leer el registro del túnel.

Distinga también una interfaz recreada de un dispositivo existente. La configuración persistente y la interfaz en ejecución son objetos relacionados, y ninguno de los dos es una identidad permanente de hardware.

Qué significan los valores de clonación de un gestor

La referencia de ajustes Ethernet de NetworkManager separa una dirección asignada explícitamente de valores especiales como preserve, permanent, random y stable, con grafías distintas en la línea de comandos y en la interfaz D-Bus.

Esos valores son una capacidad admitida de un solo gestor. No demuestran que esta imagen ejecute ese gestor, que este perfil haya usado aleatorización o que un proceso VPN haya reescrito una NIC. Solo la configuración activa en este host responde a eso.

Compruebe el propietario del ajuste en lugar de instalar un segundo gestor para que el ajuste esté disponible. Dos gestores peleando por una interfaz producen exactamente la inestabilidad que luego la gente culpa al túnel.

Corrija el requisito de identidad, no la visualización

Donde haga falta una reserva local, siga el mecanismo de identidad de cliente propio del asignador y hágalo concordar con cómo está configurada la interfaz. Fijar una dirección de puente o de túnel no relacionada para que una lista parezca estable no resuelve nada. También crea una segunda identidad que nadie documentó.

Una VPN enrutada remota autentica su propio par y asigna direcciones mediante su propio modelo. Congelar una dirección de LAN no inscribe a ese par ni crea una asignación fija de túnel.

Antes de un cambio de identidad aprobado, mantenga la configuración anterior recuperable, sobre todo en una máquina sin pantalla a la que no puede acercarse. Luego verifique la misma interfaz y el mismo servicio local tras reconectar.

El hallazgo que merece escribirse es qué objeto cambió, quién lo configuró y si eso viola el contrato de identidad que pretendía. Cualquier cosa más amplia es una conjetura vestida de conclusión. Los hallazgos estrechos también sobreviven a la revisión.