Megváltozott MAC-cím egy Pi-n: melyik interfész változott?

Miután egy VPN-beállítás landol egy Pi-n, több interfész-identitás tűnhet elmozdultnak. A tegnapi Ethernet-cím már nem egyezik a mai listával, és a következtetés magától megíródik: a VPN megváltoztatta a MAC-címet. Általában nem. Egy fizikai uplink összehasonlítása egy híddal vagy virtuális adapterrel nem összehasonlítás, és az első feladat eldönteni, melyik objektumot is nézi valójában.

Nevezze meg az interfészt és a megfigyelőt

Jegyezze fel az eszköz nevét, az interfész típusát, a jelenlegi kapcsolati rétegbeli címet és az azt birtokló kezelőt. Adja hozzá az időbélyeget, mert a rendszerindításkor megváltozott megjelenítés más esemény, mint amelyik az alagút feljövetelekor változott.

Tegye ezt ugyanarra az interfészre a kapcsolódási esemény előtt és után. Egy objektum két megfigyelése bizonyíték; két objektum egyetlen megfigyelése véletlen, amelyre történetet ragasztottak. A különbség az egész vizsgálat. Ha eltéveszti az objektumot, minden későbbi mérés kárba vész.

Ha a DHCP-foglalás része a problémának, jegyezze fel, melyik kliens-identitást kapta meg valójában a kiosztó. Az asztali lista, a híd identitása és egy régi bérleti bejegyzés három különböző rekord, és közülük csak egy az, amit az útválasztó látott.

A TUN, a TAP és az uplink különböző objektumok

A kernel éles határt húz a két virtuális típus között. A TUN IP-csomagokat szállít, és egyáltalán nincs Ethernet-identitása. A TAP Ethernet-kereteket szállít, ezért van neki.

Ez azt jelenti, hogy a TAP oldali cím nem a fizikai uplink címe, és az útvonalválasztott TUN-cím nem helyettesíti a Wi-Fi MAC-címet. Ugyanazon gép különböző rétegei.

A híd egy harmadik objektum. Saját kapcsolati rétegbeli címe van, amelyet a hozzá kapcsolt portoktól függetlenül származtatnak vagy állítanak be, így egy feljövő híd megváltoztathatja, mit mutat egy lista, anélkül hogy bármilyen hardvert érintene. A portok a saját címüket tartják alatta. A címe kifejezetten is beállítható, és akkor semmi benne nem származik a hardverből.

Ki birtokol valódi változást

Ha ugyanaz a fizikai interfész valóban címet vált, nézze meg az aktív kapcsolati profilt, mielőtt okot rendelne hozzá. Az adatvédelmi beállítások, a klónozási beállítások és az újra létrehozott virtuális eszköz mind ezt a tünetet okozzák VPN nélkül.

Az időbeli közelség nem okság. Az alagút indulása és a profil újraalkalmazása gyakran ugyanabban a másodpercben történik, mert az egyik kiváltotta a másikat, és a címváltozás a profilhoz tartozik. Olvassa el a profilt, mielőtt az alagút naplóját olvassa.

Különböztesse meg az újra létrehozott interfészt a meglévő eszköztől is. A tartós konfiguráció és a futásidejű interfész rokon objektumok, és egyik sem állandó hardveridentitás.

Mit jelentenek egy kezelő klónozási értékei

A NetworkManager Ethernet-beállítások referenciája elválasztja a kifejezetten hozzárendelt címet az olyan különleges értékektől, mint a preserve, permanent, random és stable, eltérő írásmóddal a parancssorban és a D-Bus felületen.

Ezek az értékek egyetlen kezelő támogatott képességei. Nem bizonyítják, hogy ez a lemezkép azt a kezelőt futtatja, hogy ez a profil véletlenszerűsítést használt, vagy hogy egy VPN-folyamat átírta a NIC-et. Csak az ezen a gazdagépen aktív konfiguráció válaszol erre.

Ellenőrizze a beállítás tulajdonosát, ahelyett hogy egy második kezelőt telepítene, hogy a beállítás elérhető legyen. Két kezelő, amely egy interfészért harcol, pontosan azt az instabilitást hozza létre, amelyet az emberek később az alagútra fognak.

Az identitáskövetelményt javítsa, ne a megjelenítést

Ahol helyi foglalás szükséges, kövesse a kiosztó saját kliens-identitás mechanizmusát, és hangolja össze azzal, hogyan van az interfész konfigurálva. Egy nem kapcsolódó híd- vagy alagút-cím rögzítése, hogy egy lista stabilnak tűnjön, semmit nem old meg. Második identitást is létrehoz, amelyet senki nem dokumentált.

A távoli útvonalválasztott VPN hitelesíti a saját partnerét, és a saját modellje szerint oszt címeket. Egy LAN-cím befagyasztása nem regisztrálja azt a partnert, és nem hoz létre fix alagút-hozzárendelést.

Jóváhagyott identitásváltozás előtt tartsa az előző konfigurációt helyreállíthatónak, különösen egy képernyő nélküli gépen, amelyhez nem tud odasétálni. Utána ellenőrizze ugyanazt az interfészt és ugyanazt a helyi szolgáltatást az újracsatlakozás után.

A feljegyzésre érdemes megállapítás az, hogy melyik objektum változott, ki konfigurálta, és hogy ez sérti-e a szándékolt identitásszerződést. Minden szélesebb találgatás, amely következtetés ruháját viseli. A szűk megállapítások is kiállják a felülvizsgálatot.