Pi वर बदललेला MAC पत्ता: कोणता इंटरफेस बदलला?

Pi वर VPN सेटअप आल्यानंतर अनेक इंटरफेस ओळखी बदलल्यासारख्या वाटू शकतात. कालचा इथरनेट पत्ता आजच्या यादीशी जुळत नाही, आणि निष्कर्ष स्वतःच लिहिला जातो: VPN ने MAC बदलला. सहसा तसे झाले नसते. भौतिक अपलिंकची ब्रिज किंवा आभासी अडॅप्टरशी तुलना ही तुलना नसते, आणि पहिले काम म्हणजे तुम्ही प्रत्यक्षात कोणती वस्तू पाहत आहात हे ठरवणे.

इंटरफेस आणि निरीक्षकाचे नाव ठरवा

उपकरणाचे नाव, इंटरफेसचा प्रकार, सध्याचा लिंक-लेयर पत्ता आणि तो ज्या मॅनेजरच्या मालकीचा आहे ते लिहून ठेवा. वेळेची नोंदही जोडा, कारण बूटच्या वेळी बदललेले प्रदर्शन आणि टनेल वर आल्यावर बदललेले प्रदर्शन या वेगवेगळ्या घटना आहेत.

जोडणीच्या घटनेपूर्वी आणि नंतर त्याच इंटरफेसासाठी हे करा. एकाच वस्तूची दोन निरीक्षणे पुरावा आहेत; दोन वस्तूंचे एक निरीक्षण म्हणजे कथेला जोडलेला योगायोग. हा फरकच संपूर्ण तपास आहे. वस्तू चुकीची ठरली तर पुढील प्रत्येक मोजमाप वाया जाते.

DHCP राखीवता या समस्येचा भाग असेल, तर अलोकेटरला प्रत्यक्षात कोणती क्लायंट ओळख मिळाली ते नोंदवा. डेस्कटॉपची यादी, ब्रिजची ओळख आणि जुनी लीज नोंद या तीन वेगवेगळ्या नोंदी आहेत, आणि राउटरने पाहिलेले त्यापैकी फक्त एकच आहे.

TUN, TAP आणि अपलिंक वेगवेगळ्या वस्तू आहेत

कर्नल दोन आभासी प्रकारांमध्ये स्पष्ट रेषा काढतो. TUN IP पॅकेट वाहून नेते आणि त्याला इथरनेट ओळख अजिबात नसते. TAP इथरनेट फ्रेम वाहून नेते आणि म्हणून त्याला ती असते.

म्हणजे TAP बाजूचा पत्ता भौतिक अपलिंकचा पत्ता नाही, आणि राउटेड TUN पत्ता Wi-Fi MAC ची जागा घेणारा पत्ता नाही. ते एकाच यंत्राचे वेगवेगळे स्तर आहेत.

ब्रिज ही तिसरी वस्तू आहे. तिचा स्वतःचा लिंक-लेयर पत्ता असतो, जो तिच्याशी जोडलेल्या पोर्ट्सपासून स्वतंत्रपणे घेतला किंवा ठेवला जातो, त्यामुळे ब्रिज वर आली की कोणतेही हार्डवेअर न बदलता यादीत काय दिसते ते बदलू शकते. तिच्या खाली पोर्ट्स आपले पत्ते ठेवतात. तिचा पत्ता स्पष्टपणेही ठेवता येतो; अशा वेळी त्यातले काहीही हार्डवेअरवरून घेतलेले नसते.

खरे बदलाचा मालक कोण आहे

त्याच भौतिक इंटरफेसचा पत्ता खरोखर बदलत असेल, तर कारण ठरवण्यापूर्वी सक्रिय कनेक्शन प्रोफाइल पाहा. गोपनीयता सेटिंग्ज, क्लोनिंग सेटिंग्ज आणि पुन्हा तयार केलेले आभासी उपकरण — हे सर्व VPN च्या सहभागाशिवाय तेच लक्षण निर्माण करतात.

वेळेतील जवळीक हे कारण नसते. टनेल सुरू होणे आणि प्रोफाइल पुन्हा लागू होणे बहुतेक वेळा एकाच सेकंदात घडते, कारण एकाने दुसरे सुरू केले असते, आणि पत्त्याचा बदल त्या प्रोफाइलचा असतो. टनेल लॉग वाचण्यापूर्वी प्रोफाइल वाचा.

पुन्हा तयार केलेला इंटरफेस विद्यमान उपकरणापासून वेगळा ओळखा. टिकाऊ संरचना आणि रनटाइम इंटरफेस या संबंधित वस्तू आहेत, आणि दोन्हीपैकी कोणतीही कायमची हार्डवेअर ओळख नाही.

मॅनेजरच्या क्लोनिंग मूल्यांचा अर्थ

NetworkManager च्या इथरनेट सेटिंग्ज संदर्भ मध्ये स्पष्टपणे दिलेला पत्ता preserve, permanent, random व stable अशा विशेष मूल्यांपासून वेगळा दाखवला आहे, आणि कमांड लाइन व D-Bus इंटरफेसवर यांचे स्पेलिंग वेगळे असते.

ही मूल्ये एका मॅनेजरची समर्थित क्षमता आहेत. ही प्रतिमा तो मॅनेजर चालवते, या प्रोफाइलने यादृच्छिकरण वापरले, किंवा VPN प्रक्रियेने NIC पुन्हा लिहिला — याचा ती पुरावा नाही. या होस्टवरील सक्रिय संरचनाच त्याचे उत्तर देते.

सेटिंग उपलब्ध करण्यासाठी दुसरा मॅनेजर बसवण्याऐवजी त्या सेटिंगचा मालक तपासा. एका इंटरफेसवर दोन मॅनेजरांची भांडणे नेमकी तीच अस्थिरता निर्माण करतात ज्याला लोक नंतर टनेलला दोष देतात.

प्रदर्शन नाही, ओळखीची आवश्यकता दुरुस्त करा

स्थानिक राखीवता आवश्यक असेल, तर अलोकेटरची स्वतःची क्लायंट-ओळख पद्धत वापरा आणि ती इंटरफेस कसा संरचित आहे त्याशी जुळवा. यादी स्थिर दिसावी म्हणून असंबंधित ब्रिज किंवा टनेल पत्ता पिन करण्याने काहीही सुटत नाही. त्याने कोणीही नोंदवलेली नसलेली दुसरी ओळख तयार होते.

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

मंजूर ओळख बदलापूर्वी आधीची संरचना पुनर्प्राप्त करण्यायोग्य ठेवा, विशेषतः जिथे तुम्ही चालत जाऊ शकत नाही अशा हेडलेस यंत्रावर. मग पुन्हा जोडणीनंतर तोच इंटरफेस आणि तीच स्थानिक सेवा तपासा.

नोंदवण्यासारखा निष्कर्ष म्हणजे कोणती वस्तू बदलली, ती कोणी संरचित केली, आणि त्याचे तुमच्या इच्छित ओळख कराराचे उल्लंघन होते का. यापेक्षा व्यापक काहीही म्हणजे निष्कर्षाचे कपडे घातलेला अंदाज. संकुचित निष्कर्ष पुनरावलोकनातही टिकतात.