En ändrad MAC-adress på en Pi: vilket gränssnitt ändrades?

När en VPN-konfiguration landar på en Pi kan flera gränssnittsidentiteter se ut att ha flyttat sig. Gårdagens Ethernet-adress stämmer inte längre med dagens lista, och slutsatsen skriver sig själv: VPN:en ändrade MAC-adressen. Oftast gjorde den inte det. Att jämföra en fysisk upplänk med en brygga eller en virtuell adapter är ingen jämförelse, och det första jobbet är att avgöra vilket objekt du egentligen tittar på.

Namnge gränssnittet och observatören

Skriv ner enhetsnamnet, gränssnittstypen, aktuell länklagradress och hanteraren som äger den. Lägg till tidsstämpeln, eftersom en visning som ändrades vid start är en annan händelse än en som ändrades när tunneln kom upp.

Gör detta för samma gränssnitt före och efter anslutningshändelsen. Två observationer av ett objekt är bevis; en observation av två objekt är ett sammanträffande med en historia påklistrad. Skillnaden är hela utredningen. Tar du fel objekt är varje senare mätning bortkastad.

Om en DHCP-reservation är en del av problemet, notera vilken klientidentitet tilldelaren faktiskt tog emot. En skrivbordslista, en bryggidentitet och en gammal lease-post är tre olika poster, och bara en av dem är vad routern såg.

TUN, TAP och upplänken är olika objekt

Kärnan drar en hård gräns mellan de två virtuella typerna. TUN transporterar IP-paket och har ingen Ethernet-identitet alls. TAP transporterar Ethernet-ramar och har därför en.

Det betyder att en adress på TAP-sidan inte är den fysiska upplänkens adress, och en routad TUN-adress är ingen ersättning för Wi-Fi-MAC:en. De är olika lager av samma maskin.

En brygga är ett tredje objekt. Den har sin egen länklagradress, härledd eller konfigurerad oberoende av portarna som är kopplade till den, så en brygga som kommer upp kan ändra vad en lista visar utan att röra någon hårdvara. Portarna behåller sina egna adresser under den. Adressen kan också sättas explicit, och då härrör ingenting i den från hårdvaran.

Vem som faktiskt äger en verklig ändring

Om samma fysiska gränssnitt verkligen byter adress, titta på den aktiva anslutningsprofilen innan du tilldelar en orsak. Integritetsinställningar, kloningsinställningar och en återskapad virtuell enhet ger alla det symptomet utan någon inblandning av VPN.

Närhet i tid är inte orsakssamband. Att en tunnel startar och att en profil tillämpas igen sker ofta i samma sekund eftersom det ena utlöste det andra, och adressändringen tillhör profilen. Läs profilen innan du läser tunnel-loggen.

Skilj också ett återskapat gränssnitt från en befintlig enhet. Beständig konfiguration och körtidsgränssnittet är besläktade objekt, och ingen av dem är en permanent hårdvaruidentitet.

Vad en hanterares kloningsvärden betyder

NetworkManagers referens för Ethernet-inställningar skiljer en explicit tilldelad adress från specialvärden som preserve, permanent, random och stable, med olika stavning på kommandoraden och i D-Bus-gränssnittet.

Dessa värden är en funktion som stöds av en hanterare. De är inte bevis för att denna avbildning kör den hanteraren, att denna profil använde slumpmässighet eller att en VPN-process skrev om ett nätverkskort. Bara den aktiva konfigurationen på den här värden svarar på det.

Kontrollera vem som äger inställningen i stället för att installera en andra hanterare för att göra inställningen tillgänglig. Två hanterare som slåss om ett gränssnitt ger exakt den instabilitet som folk sedan skyller på tunneln.

Rätta identitetskravet, inte visningen

Där en lokal reservation behövs, följ tilldelarens egen klientidentitetsmekanism och få den att stämma med hur gränssnittet är konfigurerat. Att fästa en orelaterad brygg- eller tunneladress för att hålla en lista stabil löser ingenting. Det skapar också en andra identitet som ingen har dokumenterat.

En extern routad VPN autentiserar sin egen peer och tilldelar adresser genom sin egen modell. Att frysa en LAN-adress registrerar inte den peeren och skapar ingen fast tunneltilldelning.

Före en godkänd identitetsändring, håll den tidigare konfigurationen återställbar, särskilt på en huvudlös maskin som du inte kan gå fram till. Verifiera sedan samma gränssnitt och samma lokala tjänst efter en återanslutning.

Fyndet som är värt att skriva ner är vilket objekt som ändrades, vem som konfigurerade det och om det bryter mot det identitetsavtal du avsåg. Allt bredare är en gissning klädd i en slutsats. Smala fynd överlever också granskning.