दुई मालिक, एउटा ठेगाना: TAP ब्रिजमा दोहोरिएको IP

एउटा Windows क्लाइन्टले 10.8.0.2 राख्छ र बुट क्रम नबदलेसम्म काम गर्छ; त्यसपछि क्लाइन्टमा केही नबदले पनि त्यही ठेगाना द्वन्द्वको रूपमा रिपोर्ट हुन्छ। उही ब्रिज गरिएको खण्डको दोस्रो होस्टले त्यही मान दाबी गर्छ, र कन्फिगरेसन सबैभन्दा पछि सक्ने मेसिन सामान्यतया हार्छ। दुवैले त्यो आफ्नो भएको ठान्छन्, र हार्ने पक्षले आफूलाई प्रयोग गर्न भनिएको ठेगाना चुपचाप प्रयोग गर्न छोड्छ। यसलाई समयको समस्या मान्नु नै प्रत्येक रिबुटमा यो दोहोरिने कारण हो।

ब्रिज छुनु अघि द्वन्द्वको प्रमाण पढ्नुहोस्

Windows ले अर्को दाबीकर्ताको हार्डवेयर ठेगानासहित ठेगाना द्वन्द्व रिपोर्ट गर्छ। त्यही हार्डवेयर ठेगाना उपयोगी तथ्य हो, किनकि यो एउटा होस्टको एउटा इन्टरफेससँग मेल खान्छ, जबकि घटनाको देखाइने नामले दोहोरिएको कहाँ छ भन्ने केही बताउँदैन। केही बदल्नु अघि हार्डवेयर ठेगाना लेखेर राख्नुहोस्।

ARP-आधारित दोहोरिएको पहिचानले ठेगाना प्रयोग हुनु अघि प्रतिस्पर्धी मालिकहरू जाँच्छ र त्यसपछि पनि निगरानी राख्छ। त्यसैले नेटवर्क कन्फिगर गर्दा अनुपस्थित रहेको होस्टले एक घण्टापछि पनि द्वन्द्व निम्त्याउन सक्छ। जाँच बुटमा एकपटक गरिने जाँच होइन। पछि देखा पर्ने मेसिनले दिनभर शान्त प्रयोगमा रहेको ठेगाना लिन सक्छ, त्यसैले यो खराबी कन्फिगरेसन त्रुटि नभई दौडजस्तो देखिन्छ।

द्वन्द्व घटनाले एक्लै कुन कन्फिगरेसनले अर्को दाबी बनायो भन्ने बताउँदैन, र प्रयोगका रूपमा ठेगाना मेटाउँदा त्यो बताउने म्यापिङ नष्ट हुन्छ। प्रमाणको उद्देश्य हार्डवेयर ठेगानालाई तपाईंले जाँच्न सक्ने इन्टरफेसमा बदल्नु हो। मेसिनको नामले इन्भेन्टरी खोज्दा सामान्यतया गलत होस्टमा पुगिन्छ।

खण्डमा भएका हरेक दाबीको सूची बनाउनुहोस्

ब्रिज गरिएको TAP सेटअपले पहिले अलग रहेका Ethernet खण्डहरू जोड्छ, त्यसैले आफ्नै नेटवर्कभित्र अद्वितीय रहेका ठेगाना फ्रेमले एउटै लिङ्क साझा गर्नेबित्तिकै ठोक्किन सक्छन्। त्यसैले यो खराबी वर्ग VPN मा छ र यसले प्रतिस्थापन गरेको रुट गरिएको नेटवर्कमा छैन। तपाईंले शंका गरेको पहिलो नभई हरेक सम्भावित मालिकको सूची बनाउनुहोस्।

सूची यो क्रममा हेर्नुहोस्: हरेक ब्रिज यन्त्र र त्यसका सदस्य पोर्टका ठेगाना, OpenVPN पूल र प्रत्येक क्लाइन्टका लागि कुनै पनि स्थिर बाँडफाँट, र ब्रिज गरिएको खण्ड ढाक्ने कुनै पनि DHCP सर्भर। त्यसपछि द्वन्द्व प्रतिवेदनको हार्डवेयर ठेगाना तपाईंले भेटेका इन्टरफेससँग मिलाउनुहोस्।

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

पूल र DHCP दायरा मानिसले बिर्सने दुई मालिक हुन्। दुवै दायरा सँगै प्रिन्ट गर्नुहोस् र अरू केही गर्नु अघि ओभरल्याप खोज्नुहोस्। हातले तोकिएको ब्रिज ठेगाना र त्यही मान दिने पूल ढिलो वा चाँडो ठोक्किनेछ, र दुवै दायरा सँगै प्रिन्ट नगरेसम्म ठोक्किने घटना अनियमित देखिन्छ।

ब्रिजलाई पहिचान चाहिने ठाउँमा मात्र नम्बर दिनुहोस्

सामान्य होस्ट ब्रिजमा ब्रिज यन्त्रले होस्टको तेस्रो तहको कन्फिगरेसन बोक्छ र Ethernet तथा TAP सदस्यले पोर्टको रूपमा काम गर्छन्। हरेक सदस्यलाई आफ्नै ठेगाना दिनु, वा ठेगाना नबदली एउटै सेटअप स्क्रिप्ट धेरै मेसिनमा प्रतिलिपि गर्नु—यसरी नै एउटा खण्डमा एउटै मानको तीन मालिक हुन्छन्। फ्रेम अगाडि पठाउन सदस्यलाई आफ्नै पहिचान चाहिँदैन। उनीहरूलाई त्यो खण्डमा पुग्न सकिने हरेक होस्टका लागि ठ्याक्कै एउटा पहिचान चाहिन्छ।

केवल फ्रेम स्विच गर्ने ब्रिजलाई त्यो खण्डमा ठेगाना नै चाहिँदैन। नम्बर नदिई राख्दा ठोक्किने घटनाको एउटा पूरा वर्ग हट्छ, तर होस्टसँग तपाईंले प्रमाणित गरेको व्यवस्थापन मार्ग अझै हुनुपर्छ। पहिले पहुँच पुष्टि गर्नुहोस्, दोस्रो ठेगाना हटाउनुहोस्, र तेस्रो पुग्न सकिने क्षमता जाँच्नुहोस्।

तपाईंले मेटाउन लागेको ठेगाना मेसिनमा पस्ने एउटै मार्ग हो भने, त्यो प्रयोगका रूपमा मेटाउनु निदान होइन, आफैले बनाएको अवरोध हो। केही परीक्षण गर्नु अघि बाह्य मार्ग प्रमाणित गर्नुहोस्।

सुधार रिबुटमा टिकिरहने बनाउनुहोस्

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

त्यो कन्फिगरेसनको मालिक खोज्नुहोस्: नेटवर्क म्यानेजर प्रोफाइल, प्रति-इन्टरफेस फाइल, कन्टेनर वा VM परिभाषा, वा cloud-init टुक्रा। त्यहीँ बदल्नुहोस्, त्यसपछि नयाँ मान नै फर्किएको पुष्टि गर्न जानाजान एउटा प्रभावित होस्ट रिबुट गर्नुहोस्। रिबुट मात्र स्थायित्व प्रमाणित गर्ने परीक्षण हो।

DHCP दायराभित्रका ब्रिज ठेगाना अपवादका रूपमा आरक्षित गर्नुहोस्, वा बाहिर सार्नुहोस्। स्प्रेडसिटमा मात्र भएको आरक्षण अपवाद होइन, र बाँडफाँट गर्नेले त्यो पढ्नेछैन।

हरेक क्लाइन्ट अनलाइन हुँदा यो प्रमाणित गर्नुहोस्

एउटा सफल जडानले केही प्रमाणित गर्दैन, किनकि मूल लक्षण क्रम बदल्दा मात्र देखा पर्थ्यो। हरेक अभिप्रेत क्लाइन्ट चलाउनुहोस्, बुट क्रम बदल्नुहोस्, र पुनः जोडिएपछि दोहोर्याउनुहोस्। त्यसपछि पहिले दौड हार्ने होस्ट रिस्टार्ट गर्नुहोस् र ठेगाना टिकिरहेको पुष्टि गर्नुहोस्।

प्रत्यक्ष पुष्टिका लागि, ठेगाना तोक्नु अघि दोहोरिएको मालिक छ कि जाँच्नुहोस् र त्यसपछि छिमेकी तालिका हेर्नुहोस्। यदि केहीले पनि जाँचको जवाफ दिएन र पूरा रिस्टार्ट चक्रमा ठेगाना अद्वितीय रह्यो भने, द्वन्द्व हटाइएको होइन, समाधान भएको हो। तलका आदेशले ब्रिज यन्त्रमा दुवै जाँच गर्छन्। RFC 5227 यी उपकरणले गर्ने जाँच र घोषणा व्यवहारको वर्णन गर्छ, र कसैले पहिचान बन्द गर्न सुझाव दिँदा उद्धृत गर्नुपर्ने स्रोत यही हो।

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

जवाफ नपाइएको जाँच सफा खण्डमा अपेक्षित नतिजा हो। प्रतिक्रिया तान्ने जाँचले तपाईंलाई बाँकी मालिकको हार्डवेयर ठेगाना दिन्छ, सुरुमा Windows घटनाले दिएको त्यही प्रमाण। त्यो आउटपुट परिवर्तन अभिलेखसँगै राख्नुहोस्, किनकि ठेगाना अद्वितीय रूपमा राखिएको एउटै प्रमाण त्यही हो।