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 ठेगाना जमाउँदा त्यो पीयर दर्ता हुँदैन र स्थिर टनेल असाइनमेन्ट बन्दैन।

स्वीकृत परिचय परिवर्तनअघि अघिल्लो कन्फिगरेसन पुनःप्राप्त गर्न सकिने राख्नुहोस्, विशेषतः तपाईं हिँडेर पुग्न नसक्ने हेडलेस मेसिनमा। त्यसपछि पुनः जडानपछि त्यही इन्टरफेस र त्यही स्थानीय सेवा प्रमाणित गर्नुहोस्।

लेख्न लायक निष्कर्ष भनेको कुन वस्तु बदलियो, त्यो कसले कन्फिगर गर्‍यो, र के त्यसले तपाईंले चाहेको परिचय सम्झौताको उल्लंघन गर्छ। यसभन्दा फराकिलो कुरा निष्कर्षको लुगा लगाएको अनुमान मात्र हो। साँघुरा निष्कर्ष पनि समीक्षामा टिक्छन्।