نشانی MAC تغییرکرده روی یک Pi: کدام رابط تغییر کرد؟

پس از آنکه یک پیکربندی VPN روی یک Pi فرود می‌آید، ممکن است به نظر برسد چند هویت رابط جابه‌جا شده‌اند. نشانی Ethernet دیروز دیگر با فهرست امروز جور درنمی‌آید و نتیجه خودش نوشته می‌شود: VPN نشانی MAC را عوض کرد. معمولاً عوض نکرده است. مقایسهٔ یک پیوند فیزیکی بالادست با یک پل یا یک آداپتور مجازی مقایسه نیست و نخستین کار این است که تصمیم بگیرید واقعاً به کدام شیء نگاه می‌کنید.

رابط و ناظر را نام بگذارید

نام دستگاه، نوع رابط، نشانی کنونی لایهٔ پیوند و مدیری که مالک آن است را بنویسید. مُهر زمان را هم اضافه کنید، چون نمایشی که هنگام بوت عوض شده رویدادی متفاوت از نمایشی است که هنگام بالا آمدن تونل عوض شده.

این کار را برای همان رابط پیش و پس از رویداد اتصال انجام دهید. دو مشاهده از یک شیء شاهد است؛ یک مشاهده از دو شیء تصادفی است که داستانی به آن چسبانده‌اند. تفاوت همان تمام پژوهش است. اگر شیء را اشتباه بگیرید، هر اندازه‌گیری بعدی هدر می‌رود.

اگر رزرو DHCP بخشی از مسئله است، یادداشت کنید که تخصیص‌دهنده در واقع کدام هویت مشتری را دریافت کرده است. فهرست رومیزی، هویت پل و یک ورودی اجارهٔ قدیمی سه رکورد متفاوت‌اند و تنها یکی از آن‌ها همان چیزی است که روتر دیده است.

TUN، TAP و پیوند بالادست اشیای متفاوتی هستند

هسته میان دو نوع مجازی خط سختی می‌کشد. TUN بسته‌های IP را حمل می‌کند و هیچ هویت Ethernet ندارد. TAP قاب‌های Ethernet را حمل می‌کند و از این رو یکی دارد.

یعنی نشانی سمت TAP نشانی پیوند فیزیکی بالادست نیست و نشانی مسیریابی‌شدهٔ TUN جانشین MAC وای‌فای نیست. این‌ها لایه‌های متفاوت همان ماشین‌اند.

پل سومین شیء است. نشانی لایهٔ پیوند خودش را دارد که مستقل از پورت‌های متصل به آن مشتق یا پیکربندی می‌شود، پس بالا آمدن یک پل می‌تواند نمایش یک فهرست را عوض کند بی‌آنکه سخت‌افزاری لمس شود. پورت‌ها نشانی‌های خودشان را زیر آن حفظ می‌کنند. نشانی آن را می‌توان به‌صراحت هم تنظیم کرد و در آن صورت هیچ چیز آن از سخت‌افزار مشتق نمی‌شود.

چه کسی واقعاً مالک یک تغییر واقعی است

اگر همان رابط فیزیکی واقعاً نشانی را عوض می‌کند، پیش از نسبت دادن علت به پروفایل اتصال فعال نگاه کنید. تنظیمات حریم خصوصی، تنظیمات کلون‌سازی و یک دستگاه مجازی بازساخته‌شده همه این نشانه را بدون هیچ دخالت VPN تولید می‌کنند.

نزدیکی زمانی علیت نیست. شروع یک تونل و اعمال دوبارهٔ یک پروفایل اغلب در همان ثانیه رخ می‌دهند چون یکی دیگری را آغاز کرده و تغییر نشانی متعلق به پروفایل است. پیش از خواندن گزارش تونل، پروفایل را بخوانید.

رابط بازساخته‌شده را نیز از دستگاه موجود جدا کنید. پیکربندی پایدار و رابط زمان اجرا اشیای مرتبط‌اند و هیچ‌کدام هویت دائمی سخت‌افزار نیست.

مقادیر شبیه‌سازی یک مدیر به چه معناست

مرجع تنظیمات Ethernet در NetworkManager نشانی صریحاً تخصیص‌یافته را از مقادیر ویژه‌ای مانند preserve و permanent و random و stable جدا می‌کند، با املای متفاوت در خط فرمان و در رابط D-Bus.

آن مقادیر قابلیتی پشتیبانی‌شده از یک مدیرند. آن‌ها مدرکی نیستند بر اینکه این تصویر همان مدیر را اجرا می‌کند، یا این پروفایل از تصادفی‌سازی استفاده کرده، یا فرایندی از VPN یک NIC را بازنویسی کرده است. تنها پیکربندی فعال روی همین میزبان به این پاسخ می‌دهد.

به‌جای نصب مدیر دومی برای در دسترس کردن تنظیم، مالک تنظیم را بررسی کنید. دو مدیر که بر سر یک رابط می‌جنگند دقیقاً همان ناپایداری‌ای را می‌سازند که مردم بعداً گردن تونل می‌اندازند.

نیاز هویتی را درست کنید، نه نمایش را

جایی که رزرو محلی لازم است، سازوکار هویت مشتری خود تخصیص‌دهنده را دنبال کنید و آن را با نحوهٔ پیکربندی رابط همساز کنید. میخ‌کوبیدن یک نشانی پل یا تونل بی‌ربط برای پایدار نشان دادن فهرست چیزی را حل نمی‌کند. هویت دومی هم می‌سازد که کسی مستندش نکرده است.

یک VPN مسیریابی‌شدهٔ دوردست همتای خودش را احراز هویت می‌کند و نشانی‌ها را با مدل خودش تخصیص می‌دهد. منجمد کردن یک نشانی LAN آن همتا را ثبت نمی‌کند و تخصیص ثابتی برای تونل نمی‌سازد.

پیش از یک تغییر هویت تأییدشده، پیکربندی پیشین را بازیابی‌پذیر نگه دارید، به‌ویژه روی ماشینی بی‌نمایشگر که نمی‌توانید پیاده به سراغش بروید. سپس پس از اتصال دوباره همان رابط و همان سرویس محلی را بررسی کنید.

یافته‌ای که ارزش نوشتن دارد این است که کدام شیء تغییر کرد، چه کسی آن را پیکربندی کرد و آیا این کار قرارداد هویتی را که در نظر داشتید نقض می‌کند. هر چیز گسترده‌تر حدسی است با جامهٔ نتیجه. یافته‌های باریک هم از بازبینی جان سالم به در می‌برند.