Pi पर बदला हुआ MAC पता: कौन-सा इंटरफ़ेस बदला?

Pi पर VPN सेटअप आने के बाद कई इंटरफ़ेस पहचानें खिसकी हुई लग सकती हैं। कल का Ethernet पता आज की सूची से मेल नहीं खाता, और निष्कर्ष खुद लिख जाता है: VPN ने MAC बदल दिया। आमतौर पर ऐसा नहीं हुआ। भौतिक अपलिंक की तुलना ब्रिज या वर्चुअल अडैप्टर से करना तुलना नहीं है, और पहला काम यह तय करना है कि आप वास्तव में किस वस्तु को देख रहे हैं।

इंटरफ़ेस और प्रेक्षक का नाम लें

डिवाइस का नाम, इंटरफ़ेस का प्रकार, वर्तमान लिंक-लेयर पता और उसका मालिक प्रबंधक लिख लें। समय-चिह्न जोड़ें, क्योंकि बूट पर बदला प्रदर्शन टनल ऊपर आने पर बदले प्रदर्शन से अलग घटना है।

कनेक्शन घटना से पहले और बाद में उसी इंटरफ़ेस के लिए यह करें। एक वस्तु के दो अवलोकन साक्ष्य हैं; दो वस्तुओं का एक अवलोकन किसी कहानी से जुड़ा संयोग है। अंतर ही पूरी जाँच है। वस्तु गलत पकड़ी तो हर आगे का मापन व्यर्थ है।

अगर DHCP आरक्षण समस्या का हिस्सा है, तो नोट करें कि आवंटक को वास्तव में कौन-सी क्लाइंट पहचान मिली। डेस्कटॉप सूची, ब्रिज की पहचान और पुरानी लीज़ प्रविष्टि तीन अलग रिकॉर्ड हैं, और उनमें से केवल एक ही वह है जो राउटर ने देखा।

TUN, TAP और अपलिंक अलग-अलग वस्तुएँ हैं

कर्नेल दोनों वर्चुअल प्रकारों के बीच सख्त रेखा खींचता है। TUN IP पैकेट ले जाता है और उसकी कोई Ethernet पहचान नहीं है। TAP Ethernet फ़्रेम ले जाता है और इसलिए उसकी पहचान है।

इसका अर्थ है कि TAP पक्ष का पता भौतिक अपलिंक का पता नहीं है, और रूट किया गया TUN पता Wi-Fi MAC का विकल्प नहीं है। ये एक ही मशीन की अलग परतें हैं।

ब्रिज तीसरी वस्तु है। उसका अपना लिंक-लेयर पता होता है, जो उससे जुड़े पोर्ट से स्वतंत्र रूप से व्युत्पन्न या कॉन्फ़िगर होता है, इसलिए ऊपर आता ब्रिज किसी भी हार्डवेयर को छुए बिना बदल सकता है कि सूची क्या दिखाती है। पोर्ट उसके नीचे अपने पते रखते हैं। उसका पता स्पष्ट रूप से भी सेट किया जा सकता है, और तब उसमें कुछ भी हार्डवेयर से नहीं आता।

असली बदलाव का मालिक कौन है

अगर वही भौतिक इंटरफ़ेस सचमुच पता बदलता है, तो कारण तय करने से पहले सक्रिय कनेक्शन प्रोफ़ाइल देखें। गोपनीयता सेटिंग, क्लोन सेटिंग और फिर से बनाया गया वर्चुअल डिवाइस—सब VPN की कोई भूमिका बिना वही लक्षण पैदा करते हैं।

समय में निकटता कारणता नहीं है। टनल का शुरू होना और प्रोफ़ाइल का फिर से लागू होना अक्सर उसी सेकंड होता है क्योंकि एक ने दूसरे को शुरू किया, और पता बदलना प्रोफ़ाइल का है। टनल लॉग पढ़ने से पहले प्रोफ़ाइल पढ़ें।

फिर से बने इंटरफ़ेस को मौजूदा डिवाइस से भी अलग पहचानें। स्थायी कॉन्फ़िगरेशन और रनटाइम इंटरफ़ेस संबंधित वस्तुएँ हैं, और इनमें से कोई भी स्थायी हार्डवेयर पहचान नहीं है।

किसी प्रबंधक के क्लोन मानों का क्या अर्थ है

NetworkManager का Ethernet सेटिंग्स का संदर्भ स्पष्ट रूप से आवंटित पते को preserve, permanent, random और stable जैसे विशेष मानों से अलग करता है, कमांड लाइन और D-Bus इंटरफ़ेस पर वर्तनी अलग होती है।

वे मान एक प्रबंधक की समर्थित क्षमता हैं। वे इस बात का प्रमाण नहीं हैं कि यह इमेज वही प्रबंधक चलाती है, कि इस प्रोफ़ाइल ने रैंडमाइज़ेशन इस्तेमाल किया, या कि किसी VPN प्रक्रिया ने NIC फिर से लिखा। इस होस्ट पर सक्रिय कॉन्फ़िगरेशन ही उसका उत्तर देता है।

सेटिंग को उपलब्ध कराने के लिए दूसरा प्रबंधक स्थापित करने के बजाय सेटिंग के मालिक की जाँच करें। एक इंटरफ़ेस पर लड़ते दो प्रबंधक ठीक वही अस्थिरता पैदा करते हैं जिसका दोष लोग बाद में टनल पर डालते हैं।

पहचान की शर्त ठीक करें, प्रदर्शन नहीं

जहाँ स्थानीय आरक्षण ज़रूरी हो, आवंटक की अपनी क्लाइंट-पहचान व्यवस्था अपनाएँ और उसे इंटरफ़ेस के कॉन्फ़िगरेशन से मेल खिलाएँ। सूची को स्थिर दिखाने के लिए असंबंधित ब्रिज या टनल पता पिन करना कुछ हल नहीं करता। यह ऐसी दूसरी पहचान भी बनाता है जिसे किसी ने दर्ज नहीं किया।

दूरस्थ रूट किया गया VPN अपने साथी को प्रमाणित करता है और अपने मॉडल से पते आवंटित करता है। LAN पता जमाना उस साथी को नामांकित नहीं करता और निश्चित टनल आवंटन नहीं बनाता।

स्वीकृत पहचान बदलाव से पहले पिछला कॉन्फ़िगरेशन पुनर्प्राप्त करने योग्य रखें, खासकर ऐसी बिना स्क्रीन वाली मशीन पर जहाँ आप पैदल नहीं जा सकते। फिर दोबारा जुड़ने के बाद उसी इंटरफ़ेस और उसी स्थानीय सेवा को सत्यापित करें।

लिखने लायक निष्कर्ष यह है कि कौन-सी वस्तु बदली, किसने उसे कॉन्फ़िगर किया, और क्या यह आपके इच्छित पहचान-अनुबंध का उल्लंघन करता है। इससे व्यापक कोई भी बात निष्कर्ष के वस्त्र में अनुमान है। संकीर्ण निष्कर्ष भी समीक्षा में टिकते हैं।