כתובת MAC שהשתנתה ב-Pi: איזה ממשק השתנה?

אחרי שהגדרת VPN נוחתת על Pi, כמה זהויות ממשק עשויות להיראות כמי שזזו. כתובת ה-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 שכתב NIC מחדש. רק התצורה הפעילה במארח הזה עונה על כך.

בדקו את הבעלים של ההגדרה במקום להתקין מנהל שני כדי להפוך את ההגדרה לזמינה. שני מנהלים שנאבקים על ממשק אחד יוצרים בדיוק את חוסר היציבות שאנשים לאחר מכן מאשימים בו את המנהרה.

תקנו את דרישת הזהות, לא את התצוגה

כשנדרשת הזמנה מקומית, עקבו אחר מנגנון זהות הלקוח של המקצה עצמו והתאימו אותו לאופן שבו הממשק מוגדר. נעיצת כתובת גשר או מנהרה לא קשורה כדי שרשימה תיראה יציבה לא פותרת דבר. היא גם יוצרת זהות שנייה שאיש לא תיעד.

VPN מנותב מרוחק מאמת את העמית שלו ומקצה כתובות לפי המודל שלו. הקפאת כתובת LAN אינה רושמת את העמית הזה ואינה יוצרת הקצאת מנהרה קבועה.

לפני שינוי זהות מאושר, שמרו על התצורה הקודמת ניתנת לשחזור, במיוחד במכונה בלי מסך שאליה אינכם יכולים לגשת ברגל. אחר כך אמתו את אותו ממשק ואת אותו שירות מקומי לאחר התחברות מחדש.

הממצא ששווה לרשום הוא איזה אובייקט השתנה, מי הגדיר אותו, והאם זה מפר את חוזה הזהות שהתכוונתם לו. כל דבר רחב יותר הוא ניחוש לבוש כמסקנה. ממצאים צרים גם שורדים סקירה.