Um endereço MAC alterado no Pi: qual interface mudou?
Uma bridge, um dispositivo TAP e um uplink físico carregam cada um a sua identidade. Compare o mesmo objeto antes e depois da ligação e depois descubra quem o definiu.
Depois que uma configuração de VPN chega a um Pi, várias identidades de interface podem parecer ter mudado de lugar. O endereço Ethernet de ontem já não corresponde à lista de hoje, e a conclusão escreve-se sozinha: a VPN mudou o MAC. Normalmente não mudou. Comparar um uplink físico com uma bridge ou um adaptador virtual não é uma comparação, e a primeira tarefa é decidir que objeto está realmente a observar.
Nomeie a interface e o observador
Anote o nome do dispositivo, o tipo de interface, o endereço atual da camada de ligação e o gestor que a possui. Acrescente o registo temporal, porque uma exibição que mudou no arranque é um evento diferente de uma que mudou quando o túnel subiu.
Faça isto para a mesma interface antes e depois do evento de ligação. Duas observações de um objeto são prova; uma observação de dois objetos é uma coincidência com uma história agarrada. A diferença é toda a investigação. Se errar o objeto, cada medição seguinte é desperdiçada.
Se uma reserva DHCP faz parte do problema, registe que identidade de cliente o alocador recebeu de facto. Uma lista de ambiente de trabalho, uma identidade de bridge e uma entrada de concessão antiga são três registos distintos, e só um deles foi o que o router viu.
TUN, TAP e o uplink são objetos diferentes
O kernel traça uma linha dura entre os dois tipos virtuais. O TUN transporta pacotes IP e não tem qualquer identidade Ethernet. O TAP transporta tramas Ethernet e, por isso, tem uma.
Isso significa que um endereço do lado TAP não é o endereço do uplink físico, e um endereço TUN encaminhado não é um substituto do MAC Wi-Fi. São camadas diferentes da mesma máquina.
Uma bridge é um terceiro objeto. Tem o seu próprio endereço de camada de ligação, derivado ou configurado independentemente das portas que lhe estão ligadas, pelo que uma bridge a subir pode mudar o que uma lista mostra sem tocar em qualquer hardware. As portas mantêm os seus próprios endereços por baixo. O endereço também pode ser definido explicitamente e, nesse caso, nada nele deriva do hardware.
Quem realmente é dono de uma mudança real
Se a mesma interface física muda genuinamente de endereço, olhe para o perfil de ligação ativo antes de atribuir uma causa. Definições de privacidade, definições de clonagem e um dispositivo virtual recriado produzem todos esse sintoma sem qualquer envolvimento da VPN.
Proximidade no tempo não é causalidade. Um túnel a arrancar e um perfil a ser reaplicado acontecem muitas vezes no mesmo segundo porque um desencadeou o outro, e a mudança de endereço pertence ao perfil. Leia o perfil antes de ler o registo do túnel.
Distinga também uma interface recriada de um dispositivo existente. A configuração persistente e a interface em execução são objetos relacionados, e nenhuma delas é uma identidade de hardware permanente.
O que significam os valores de clonagem de um gestor
A referência das definições Ethernet do NetworkManager separa um endereço atribuído explicitamente de valores especiais como preserve, permanent, random e stable, com grafias diferentes na linha de comandos e na interface D-Bus.
Esses valores são uma capacidade suportada por um gestor. Não são prova de que esta imagem execute esse gestor, de que este perfil tenha usado aleatorização ou de que um processo VPN tenha reescrito uma NIC. Só a configuração ativa neste anfitrião responde a isso.
Verifique o dono da definição em vez de instalar um segundo gestor para tornar a definição disponível. Dois gestores a disputar uma interface produzem exatamente a instabilidade de que as pessoas depois culpam o túnel.
Corrija o requisito de identidade, não a exibição
Onde é necessária uma reserva local, siga o próprio mecanismo de identidade de cliente do alocador e faça-o concordar com a forma como a interface está configurada. Fixar um endereço de bridge ou de túnel não relacionado para manter uma lista estável não resolve nada. Também cria uma segunda identidade que ninguém documentou.
Uma VPN encaminhada remota autentica o seu próprio par e atribui endereços através do seu próprio modelo. Congelar um endereço LAN não inscreve esse par e não cria uma atribuição de túnel fixa.
Antes de uma alteração de identidade aprovada, mantenha a configuração anterior recuperável, especialmente numa máquina sem monitor de que não se pode aproximar. Depois verifique a mesma interface e o mesmo serviço local após uma nova ligação.
A conclusão que vale a pena registar é que objeto mudou, quem o configurou e se isso viola o contrato de identidade que pretendia. Qualquer coisa mais ampla é um palpite vestido de conclusão. Conclusões estreitas também sobrevivem à revisão.