En endret MAC-adresse på en Pi: hvilket grensesnitt ble endret?

Etter at et VPN-oppsett lander på en Pi, kan flere grensesnittidentiteter se ut som om de har flyttet seg. Gårsdagens Ethernet-adresse samsvarer ikke lenger med dagens liste, og konklusjonen skriver seg selv: VPN-en endret MAC-en. Vanligvis gjorde den ikke det. Å sammenligne en fysisk opplenke med en bro eller en virtuell adapter er ikke en sammenligning, og den første jobben er å avgjøre hvilket objekt du faktisk ser på.

Navngi grensesnittet og observatøren

Skriv ned enhetsnavnet, grensesnitttypen, gjeldende lenkelagsadresse og håndtereren som eier den. Legg til tidsstempelet, fordi en visning som endret seg ved oppstart er en annen hendelse enn en som endret seg da tunnelen kom opp.

Gjør dette for samme grensesnitt før og etter tilkoblingshendelsen. To observasjoner av ett objekt er bevis; én observasjon av to objekter er en tilfeldighet med en historie festet til seg. Forskjellen er hele undersøkelsen. Tar du feil objekt, er hver senere måling bortkastet.

Hvis en DHCP-reservasjon er en del av problemet, noter hvilken klientidentitet tildeleren faktisk mottok. En skrivebordsliste, en broidentitet og en gammel lease-oppføring er tre forskjellige poster, og bare én av dem er det ruteren så.

TUN, TAP og opplenken er forskjellige objekter

Kjernen trekker en hard grense mellom de to virtuelle typene. TUN frakter IP-pakker og har ingen Ethernet-identitet i det hele tatt. TAP frakter Ethernet-rammer og har derfor en.

Det betyr at en adresse på TAP-siden ikke er den fysiske opplenkens adresse, og en rutet TUN-adresse er ikke en erstatning for Wi-Fi-MAC-en. De er forskjellige lag av samme maskin.

En bro er et tredje objekt. Den har sin egen lenkelagsadresse, utledet eller konfigurert uavhengig av portene som er knyttet til den, så en bro som kommer opp kan endre det en liste viser uten å røre noe maskinvare. Portene beholder sine egne adresser under den. Adressen kan også settes eksplisitt, og i så fall er ingenting ved den utledet fra maskinvaren.

Hvem som faktisk eier en reell endring

Hvis det samme fysiske grensesnittet virkelig endrer adresse, se på den aktive tilkoblingsprofilen før du tilskriver en årsak. Personverninnstillinger, kloningsinnstillinger og en gjenopprettet virtuell enhet gir alle det symptomet uten VPN-innblanding.

Nærhet i tid er ikke årsakssammenheng. En tunnel som starter og en profil som brukes på nytt skjer ofte i samme sekund fordi den ene utløste den andre, og adresseendringen tilhører profilen. Les profilen før du leser tunnel-loggen.

Skill også et gjenopprettet grensesnitt fra en eksisterende enhet. Vedvarende konfigurasjon og kjøretidsgrensesnittet er beslektede objekter, og ingen av dem er en permanent maskinvareidentitet.

Hva en håndterers kloningsverdier betyr

NetworkManagers referansen for Ethernet-innstillinger skiller en eksplisitt tildelt adresse fra spesialverdier som preserve, permanent, random og stable, med forskjellig stavemåte på kommandolinjen og i D-Bus-grensesnittet.

Disse verdiene er en støttet egenskap i én håndterer. De er ikke bevis for at dette imaget kjører den håndtereren, at denne profilen brukte randomisering, eller at en VPN-prosess skrev om et NIC. Bare den aktive konfigurasjonen på denne verten svarer på det.

Sjekk hvem som eier innstillingen i stedet for å installere en ekstra håndterer for å gjøre innstillingen tilgjengelig. To håndterere som slåss om ett grensesnitt gir nøyaktig den ustabiliteten folk deretter gir tunnelen skylden for.

Rett på identitetskravet, ikke på visningen

Der en lokal reservasjon trengs, følg tildelerens egen klientidentitetsmekanisme og få den til å stemme med hvordan grensesnittet er konfigurert. Å feste en urelatert bro- eller tunneladresse for å holde en liste stabil løser ingenting. Det lager også en annen identitet som ingen har dokumentert.

En ekstern rutet VPN autentiserer sin egen peer og tildeler adresser gjennom sin egen modell. Å fryse en LAN-adresse registrerer ikke den peeren og lager ikke en fast tunneltildeling.

Før en godkjent identitetsendring, hold den forrige konfigurasjonen gjenopprettbar, spesielt på en hodeløs maskin du ikke kan gå bort til. Verifiser deretter samme grensesnitt og samme lokale tjeneste etter en ny tilkobling.

Funnet som er verdt å skrive ned, er hvilket objekt som endret seg, hvem som konfigurerte det, og om det bryter identitetskontrakten du hadde tenkt. Noe bredere er en gjetning som har kledd seg ut som en konklusjon. Smale funn tåler også gjennomgang.