Een gewijzigd MAC-adres op een Pi: welke interface is veranderd?

Nadat een VPN-opstelling op een Pi is beland, lijken meerdere interface-identiteiten te zijn verschoven. Het Ethernet-adres van gisteren komt niet meer overeen met de lijst van vandaag, en de conclusie schrijft zichzelf: de VPN heeft het MAC-adres gewijzigd. Meestal was dat niet zo. Een fysieke uplink vergelijken met een bridge of een virtuele adapter is geen vergelijking, en de eerste taak is bepalen naar welk object je werkelijk kijkt.

Benoem de interface en de waarnemer

Schrijf de apparaatnaam op, het interfacetype, het huidige link-layeradres en de manager die er eigenaar van is. Voeg de tijdstempel toe, want een weergave die bij het opstarten veranderde is een andere gebeurtenis dan een die veranderde toen de tunnel opkwam.

Doe dit voor dezelfde interface voor en na de verbindingsgebeurtenis. Twee waarnemingen van één object zijn bewijs; één waarneming van twee objecten is een toeval met een verhaal eraan vast. Het verschil is het hele onderzoek. Heb je het verkeerde object, dan is elke latere meting verspild.

Als een DHCP-reservering deel van het probleem is, noteer dan welke clientidentiteit de toewijzer werkelijk heeft ontvangen. Een desktoplijst, een bridge-identiteit en een oude lease-regel zijn drie verschillende registraties, en slechts één daarvan is wat de router zag.

TUN, TAP en de uplink zijn verschillende objecten

De kernel trekt een harde grens tussen de twee virtuele typen. TUN vervoert IP-pakketten en heeft helemaal geen Ethernet-identiteit. TAP vervoert Ethernet-frames en heeft er daarom wel een.

Dat betekent dat een adres aan de TAP-kant niet het adres van de fysieke uplink is, en een gerouteerd TUN-adres is geen vervangend Wi-Fi-MAC. Het zijn verschillende lagen van dezelfde machine.

Een bridge is een derde object. Hij heeft zijn eigen link-layeradres, afgeleid of geconfigureerd onafhankelijk van de poorten die eraan zijn gekoppeld, dus een bridge die opkomt kan veranderen wat een lijst toont zonder hardware aan te raken. De poorten houden eronder hun eigen adressen. Het adres kan ook expliciet worden ingesteld, en in dat geval is niets eraan van de hardware afgeleid.

Wie een echte wijziging werkelijk bezit

Als dezelfde fysieke interface werkelijk van adres verandert, kijk dan naar het actieve verbindingsprofiel voordat je een oorzaak toekent. Privacy-instellingen, cloning-instellingen en een opnieuw aangemaakt virtueel apparaat geven allemaal dat symptoom zonder enige betrokkenheid van een VPN.

Nabijheid in tijd is geen causaliteit. Een tunnel die start en een profiel dat opnieuw wordt toegepast gebeuren vaak in dezelfde seconde omdat het ene het andere heeft getriggerd, en de adreswijziging hoort bij het profiel. Lees het profiel voordat je het tunnellog leest.

Onderscheid ook een opnieuw aangemaakte interface van een bestaand apparaat. Permanente configuratie en de runtime-interface zijn verwante objecten, en geen van beide is een blijvende hardware-identiteit.

Wat de cloning-waarden van een manager betekenen

De Ethernet-instellingenreferentie van NetworkManager onderscheidt een expliciet toegewezen adres van speciale waarden zoals preserve, permanent, random en stable, met een andere spelling op de commandoregel en in de D-Bus-interface.

Die waarden zijn een ondersteunde mogelijkheid van één manager. Ze bewijzen niet dat deze image die manager draait, dat dit profiel randomisatie gebruikte, of dat een VPN-proces een NIC heeft herschreven. Alleen de actieve configuratie op deze host beantwoordt dat.

Controleer de eigenaar van de instelling in plaats van een tweede manager te installeren om de instelling beschikbaar te maken. Twee managers die om één interface vechten veroorzaken precies de instabiliteit die mensen daarna de tunnel verwijten.

Repareer de identiteitseis, niet de weergave

Waar een lokale reservering nodig is, volg het eigen clientidentiteitsmechanisme van de toewijzer en laat het overeenkomen met hoe de interface is geconfigureerd. Een niet-verwant bridge- of tunneladres vastpinnen om een lijst stabiel te laten lijken lost niets op. Het creëert ook een tweede identiteit die niemand heeft gedocumenteerd.

Een externe gerouteerde VPN authenticeert zijn eigen peer en wijst adressen toe via zijn eigen model. Een LAN-adres bevriezen schrijft die peer niet in en maakt geen vaste tunneltoewijzing.

Houd vóór een goedgekeurde identiteitswijziging de vorige configuratie herstelbaar, vooral op een headless machine waar je niet even naartoe kunt lopen. Verifieer daarna dezelfde interface en dezelfde lokale dienst na een herverbinding.

De bevinding die het opschrijven waard is, is welk object veranderde, wie het configureerde, en of dat het identiteitscontract schendt dat je bedoelde. Alles breder is een gok in de kleren van een conclusie. Smalle bevindingen overleven ook een review.