Змінений MAC-адрес на Pi: який інтерфейс змінився?

Після того як на Pi з'являється налаштування VPN, кілька ідентичностей інтерфейсів можуть виглядати зміщеними. Учорашня Ethernet-адреса більше не збігається з сьогоднішнім списком, і висновок пишеться сам собою: VPN змінив MAC. Зазвичай це не так. Порівнювати фізичний аплінк із мостом або віртуальним адаптером — це не порівняння, і перше завдання — вирішити, на який об'єкт ви насправді дивитеся.

Назвіть інтерфейс і спостерігача

Запишіть ім'я пристрою, тип інтерфейсу, поточну адресу канального рівня й менеджер, якому він належить. Додайте позначку часу, бо відображення, що змінилося під час завантаження, — це інша подія, ніж те, що змінилося під час підняття тунелю.

Зробіть це для того самого інтерфейсу до й після події з'єднання. Два спостереження одного об'єкта — доказ; одне спостереження двох об'єктів — збіг з приєднаною історією. Ця різниця і є все розслідування. Помилитеся з об'єктом — і кожне подальше вимірювання змарноване.

Якщо резервування DHCP є частиною проблеми, занотуйте, яку саме ідентичність клієнта фактично отримав розподілювач. Список на робочому столі, ідентичність мосту й старий запис оренди — три різні записи, і лише один із них бачив маршрутизатор.

TUN, TAP і аплінк — різні об'єкти

Ядро проводить тверду межу між двома віртуальними типами. TUN переносить IP-пакети й зовсім не має ідентичності Ethernet. TAP переносить кадри Ethernet і тому має її.

Це означає, що адреса з боку TAP — не адреса фізичного аплінку, а маршрутизована адреса TUN — не заміна MAC Wi-Fi. Це різні рівні однієї машини.

Міст — третій об'єкт. У нього власна адреса канального рівня, похідна або налаштована незалежно від під'єднаних до нього портів, тож міст, що піднімається, може змінити те, що показує список, не торкаючись обладнання. Порти під ним зберігають свої адреси. Його адресу можна задати й явно, і тоді ніщо в ній не походить від обладнання.

Хто насправді володіє реальною зміною

Якщо той самий фізичний інтерфейс справді змінює адресу, подивіться на активний профіль з'єднання, перш ніж призначати причину. Налаштування приватності, налаштування клонування й повторно створений віртуальний пристрій дають цей симптом без будь-якої участі VPN.

Близькість у часі — не причинність. Запуск тунелю й повторне застосування профілю часто відбуваються в одну й ту саму секунду, бо одне спричинило інше, і зміна адреси належить профілю. Прочитайте профіль, перш ніж читати журнал тунелю.

Відрізняйте й повторно створений інтерфейс від наявного пристрою. Постійна конфігурація й інтерфейс часу виконання — пов'язані об'єкти, і жоден із них не є постійною апаратною ідентичністю.

Що означають значення клонування в менеджера

Довідник налаштувань Ethernet NetworkManager відокремлює явно призначену адресу від особливих значень, як-от preserve, permanent, random і stable, причому написання різниться в командному рядку та в інтерфейсі D-Bus.

Ці значення — підтримувана можливість одного менеджера. Вони не доводять, що цей образ запускає саме його, що цей профіль використав рандомізацію або що процес VPN переписав мережеву карту. Відповідь дає лише активна конфігурація на цьому хості.

Перевірте власника налаштування, а не встановлюйте другий менеджер, щоб налаштування стало доступним. Два менеджери, що борються за один інтерфейс, дають саме ту нестабільність, яку потім списують на тунель.

Виправляйте вимогу до ідентичності, а не відображення

Там, де потрібне локальне резервування, дотримуйтеся власного механізму ідентичності клієнта в розподілювача й узгодьте його з тим, як налаштований інтерфейс. Прикріплення сторонньої адреси мосту або тунелю, щоб список виглядав стабільним, нічого не вирішує. Воно ще й створює другу ідентичність, яку ніхто не задокументував.

Віддалений маршрутизований VPN сам автентифікує свого піра й призначає адреси за власною моделлю. Заморожування адреси LAN не реєструє цього піра й не створює фіксованого призначення тунелю.

Перед схваленою зміною ідентичності тримайте попередню конфігурацію відновлюваною, особливо на машині без екрана, до якої не можна підійти пішки. Потім перевірте той самий інтерфейс і ту саму локальну службу після повторного підключення.

Висновок, який варто записати: який об'єкт змінився, хто його налаштував і чи це порушує задуманий вами контракт ідентичності. Усе ширше — це здогад у вбранні висновку. Вузькі висновки теж переживають рев'ю.