Ei endra MAC-adresse på ein Pi: kva grensesnitt vart endra?
Ei bru, ein TAP-eining og ein fysisk opplenk ber kvar sin identitet. Samanlikn same objektet før og etter tilkoplinga, og finn deretter ut kven som sette det.
Etter at eit VPN-oppsett landar på ein Pi, kan fleire grensesnittidentitetar sjå ut som dei har flytta seg. Ethernet-adressa frå i går stemmer ikkje lenger med lista i dag, og konklusjonen skriv seg sjølv: VPN-en endra MAC-en. Vanlegvis gjorde han ikkje det. Å samanlikne ei fysisk opplenk med ei bru eller ein virtuell adapter er ikkje ei samanlikning, og den første jobben er å avgjere kva objekt du faktisk ser på.
Namngje grensesnittet og observatøren
Skriv ned einingas namn, grensesnitttypen, gjeldande lenkelagsadresse og handteraren som eig henne. Legg til tidsstempelet, fordi ei vising som endra seg ved oppstart er ei anna hending enn ei som endra seg då tunnelen kom opp.
Gjer dette for same grensesnitt før og etter tilkoplingshendinga. To observasjonar av eitt objekt er prov; éin observasjon av to objekt er eit samantreff med ei historie fest til seg. Skilnaden er heile granskinga. Tek du feil objekt, er kvar seinare måling bortkasta.
Viss ein DHCP-reservasjon er ein del av problemet, noter kva klientidentitet tildelaren faktisk fekk. Ei skrivebordsliste, ein bruidentitet og eit gammalt lease-oppføring er tre ulike postar, og berre éin av dei er det rutaren såg.
TUN, TAP og opplenka er ulike objekt
Kjernen dreg ei hard grense mellom dei to virtuelle typane. TUN fraktar IP-pakkar og har ingen Ethernet-identitet i det heile. TAP fraktar Ethernet-rammer og har derfor ein.
Det tyder at ei adresse på TAP-sida ikkje er adressa til den fysiske opplenka, og ei ruta TUN-adresse er ikkje ei erstatning for Wi-Fi-MAC-en. Dei er ulike lag av same maskin.
Ei bru er eit tredje objekt. Ho har si eiga lenkelagsadresse, utleidd eller konfigurert uavhengig av portane som er knytte til henne, så ei bru som kjem opp kan endre det ei liste viser utan å røre noko maskinvare. Portane held på sine eigne adresser under henne. Adressa kan også setjast eksplisitt, og då er ingenting ved henne utleidd frå maskinvaren.
Kven som faktisk eig ei reell endring
Viss det same fysiske grensesnittet verkeleg endrar adresse, sjå på den aktive tilkoplingsprofilen før du gir ei årsak. Personverninnstillingar, kloningsinnstillingar og ei gjenoppretta virtuell eining gir alle det symptomet utan noka VPN-innblanding.
Nærleik i tid er ikkje årsakssamanheng. Ein tunnel som startar og ein profil som blir brukt på nytt skjer ofte i same sekund fordi den eine utløyste den andre, og adresseendringa høyrer til profilen. Les profilen før du les tunnel-loggen.
Skil også eit gjenoppretta grensesnitt frå ei eksisterande eining. Varig konfigurasjon og køyretidsgrensesnittet er skylde objekt, og ingen av dei er ein permanent maskinvareidentitet.
Kva kloningsverdiane til ein handterar tyder
NetworkManagers referansen for Ethernet-innstillingar skil ei eksplisitt tildelt adresse frå spesialverdiar som preserve, permanent, random og stable, med ulik stavemåte på kommandolinja og i D-Bus-grensesnittet.
Dei verdiane er ein støtta eigenskap i éin handterar. Dei er ikkje prov for at dette imaget køyrer den handteraren, at denne profilen brukte randomisering, eller at ein VPN-prosess skreiv om eit NIC. Berre den aktive konfigurasjonen på denne verten svarar på det.
Sjekk kven som eig innstillinga i staden for å installere ein ekstra handterar for å gjere innstillinga tilgjengeleg. To handterarar som slåst om eitt grensesnitt gir nøyaktig den ustabiliteten folk deretter gir tunnelen skulda for.
Rett på identitetskravet, ikkje på visinga
Der ein lokal reservasjon trengst, fylg klientidentitetsmekanismen til tildelaren sjølv og få han til å stemme med korleis grensesnittet er konfigurert. Å feste ei urelatert bru- eller tunneladresse for å halde ei liste stabil løyser ingenting. Det lagar også ein annan identitet som ingen har dokumentert.
Ein ekstern ruta VPN autentiserer sin eigen peer og tildeler adresser gjennom sin eigen modell. Å fryse ei LAN-adresse registrerer ikkje den peeren og lagar ikkje ei fast tunneltildeling.
Før ei godkjend identitetsendring, hald den førre konfigurasjonen gjenopprettbar, særleg på ein hovudlaus maskin du ikkje kan gå bort til. Stadfest deretter same grensesnitt og same lokale teneste etter ei ny tilkopling.
Funnet som er verdt å skrive ned, er kva objekt som endra seg, kven som konfigurerte det, og om det bryt identitetskontrakten du hadde tenkt. Noko breiare er ei gjetting som har kledd seg ut som ein konklusjon. Smale funn toler også gjennomgang.