Un indirizzo MAC cambiato su un Pi: quale interfaccia è cambiata?
Un bridge, un dispositivo TAP e un uplink fisico portano ciascuno la propria identità. Confrontate lo stesso oggetto prima e dopo la connessione, poi scoprite chi lo ha impostato.
Dopo che una configurazione VPN arriva su un Pi, diverse identità di interfaccia possono sembrare spostate. L’indirizzo Ethernet di ieri non corrisponde più all’elenco di oggi, e la conclusione si scrive da sola: la VPN ha cambiato il MAC. Di solito non è così. Confrontare un uplink fisico con un bridge o un adattatore virtuale non è un confronto, e il primo compito è decidere quale oggetto state guardando davvero.
Nominate l’interfaccia e l’osservatore
Annotate il nome del dispositivo, il tipo di interfaccia, l’indirizzo attuale del livello di collegamento e il gestore che lo possiede. Aggiungete la marca temporale, perché una visualizzazione cambiata all’avvio è un evento diverso da una cambiata quando è salito il tunnel.
Fatelo per la stessa interfaccia prima e dopo l’evento di connessione. Due osservazioni di un solo oggetto sono prove; una sola osservazione di due oggetti è una coincidenza con una storia attaccata. La differenza è tutta l’indagine. Se sbagliate l’oggetto, ogni misura successiva è sprecata.
Se una prenotazione DHCP fa parte del problema, annotate quale identità client ha ricevuto davvero l’allocatore. Un elenco del desktop, un’identità di bridge e una vecchia voce di lease sono tre record diversi, e solo uno di essi è ciò che il router ha visto.
TUN, TAP e l’uplink sono oggetti diversi
Il kernel traccia una linea netta tra i due tipi virtuali. TUN trasporta pacchetti IP e non ha alcuna identità Ethernet. TAP trasporta frame Ethernet e quindi ne ha una.
Ciò significa che un indirizzo lato TAP non è l’indirizzo dell’uplink fisico, e che un indirizzo TUN instradato non sostituisce un MAC Wi-Fi. Sono livelli diversi della stessa macchina.
Un bridge è un terzo oggetto. Ha il proprio indirizzo di livello di collegamento, derivato o configurato indipendentemente dalle porte collegate, quindi un bridge che sale può cambiare ciò che mostra un elenco senza toccare alcun hardware. Le porte conservano i propri indirizzi sotto di esso. Il suo indirizzo può anche essere impostato esplicitamente, e allora nulla di esso deriva dall’hardware.
Chi possiede davvero un cambiamento reale
Se la stessa interfaccia fisica cambia davvero indirizzo, guardate il profilo di connessione attivo prima di assegnare una causa. Impostazioni di privacy, impostazioni di clonazione e un dispositivo virtuale ricreato producono tutti quel sintomo senza alcun coinvolgimento della VPN.
La vicinanza nel tempo non è causalità. Un tunnel che parte e un profilo riapplicato accadono spesso nello stesso secondo perché uno ha innescato l’altro, e il cambio di indirizzo appartiene al profilo. Leggete il profilo prima di leggere il registro del tunnel.
Distinguete anche un’interfaccia ricreata da un dispositivo esistente. La configurazione persistente e l’interfaccia di runtime sono oggetti correlati, e nessuno dei due è un’identità hardware permanente.
Cosa significano i valori di clonazione di un gestore
Il riferimento alle impostazioni Ethernet di NetworkManager separa un indirizzo assegnato esplicitamente da valori speciali come preserve, permanent, random e stable, con grafie diverse sulla riga di comando e nell’interfaccia D-Bus.
Quei valori sono una capacità supportata da un solo gestore. Non dimostrano che questa immagine esegua quel gestore, che questo profilo abbia usato la randomizzazione o che un processo VPN abbia riscritto una NIC. Solo la configurazione attiva su questo host risponde a ciò.
Controllate il proprietario dell’impostazione invece di installare un secondo gestore per renderla disponibile. Due gestori che litigano per un’interfaccia producono esattamente l’instabilità che poi le persone attribuiscono al tunnel.
Correggete il requisito di identità, non la visualizzazione
Dove serve una prenotazione locale, seguite il meccanismo di identità client proprio dell’allocatore e fatelo concordare con il modo in cui l’interfaccia è configurata. Fissare un indirizzo di bridge o di tunnel non correlato per far sembrare stabile un elenco non risolve nulla. Crea anche una seconda identità che nessuno ha documentato.
Una VPN instradata remota autentica il proprio peer e assegna indirizzi secondo il proprio modello. Congelare un indirizzo LAN non iscrive quel peer e non crea un’assegnazione fissa del tunnel.
Prima di un cambiamento di identità approvato, mantenete la configurazione precedente recuperabile, soprattutto su una macchina senza schermo a cui non potete avvicinarvi. Poi verificate la stessa interfaccia e lo stesso servizio locale dopo una riconnessione.
Il risultato che vale la pena scrivere è quale oggetto è cambiato, chi lo ha configurato e se ciò viola il contratto di identità che intendevate. Qualsiasi cosa più ampia è una congettura vestita da conclusione. I risultati ristretti sopravvivono anche alla revisione.