दोन मालक, एक पत्ता: 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 घटनेने दिलेला तोच पुरावा. तो आउटपुट बदल नोंदीसोबत ठेवा, कारण पत्ता अद्वितीयपणे धरून ठेवला आहे याचा तोच एकमेव पुरावा आहे.