OpenVPN द्वारे दोन बोर्डांमधील वेगळा TAP ब्रिज

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

खालील मार्ग दोन Linux संगणकांमधील प्रमाणित TAP कनेक्शन, प्रत्येक बेंचसाठी एक समर्पित वायर्ड पोर्ट आणि प्रयोगाचा भाग नसलेला व्यवस्थापन इंटरफेस गृहीत धरतो। क्रम महत्त्वाचा आहे: आधी फ्रेम्स, नंतर पत्ते, शेवटी सीमा।

ब्रिज प्रत्यक्षात काय हलवतो

ब्रिज हा सॉफ्टवेअरमध्ये राबवलेला स्विच आहे। कोणता MAC पत्ता कोणत्या सदस्य पोर्टमागे दिसतो हे तो शिकतो आणि IP राउटिंग तक्त्याशिवाय सदस्यांमध्ये फ्रेम्स पाठवतो। त्या वर्णनात सबनेट, गेटवे किंवा डीफॉल्ट मार्ग नाही, म्हणूनच IP फॉरवर्डिंग सुरू केल्याने हे जोडणी तयार होत नाही आणि म्हणूनच ping यशस्वी होऊ शकतो तर इतर रहदारी अजूनही अयशस्वी होते। बोर्ड कोणताही डीफॉल्ट मार्ग न ठेवताही त्याच्या जोडीदारापर्यंत पोहोचू शकतो, जे स्तर दोन स्तर तीनसारखे वागेल अशी अपेक्षा ठेवणाऱ्यांना आश्चर्यचकित करते।

प्रत्येक संगणक ब्रिजला एक वायर्ड पोर्ट आणि TAP उपकरण त्याच ब्रिजला देतो, म्हणून बोर्डातील फ्रेम स्थानिक पोर्टमध्ये प्रवेश करते, TAP उपकरणाकडे पाठवले जाते, बोगदा ओलांडते, जोडीदाराच्या TAP उपकरणावर पोहोचते आणि जोडीदाराच्या बोर्डाकडे पाठवले जाते। बोगदा इतर कोणत्याही सदस्य पोर्टसारखाच आहे, आणि ब्रिजला मागे VPN आहे हे माहीत नाही किंवा त्याची पर्वा नाही। हीच सममिती उदाहरण समजून घेणे सोपे करते: प्रत्येक बाजूला लॅबकडे तोंड करणारा एक पोर्ट आणि एक बोगदा पोर्ट आहे, आणि कोणतीही बाजू विशेष नाही।

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

दोन्ही संगणकांवरील एकसारखी नावे स्थानिक नावे आहेत, सामायिक वस्तू नाहीत। बेंचांमध्ये एक Ethernet मार्ग आहे, दुसरी केबल आणि लूप बंद करणारा दुसरा बोगदा नाही; एकच MAC दोन पोर्टवर येताना पाहणारा ब्रिज आनंदाने वर्तुळात पाठवेल।

ब्रिजला पत्ता द्या, त्याच्या सदस्य पोर्टांना नाही

लॅब विभागातील संगणकाची ओळख ब्रिज उपकरणाची आहे। सदस्य पोर्ट क्रमांकाशिवाय राहतात, कारण पोर्ट हा पाठवणारा सदस्य आहे आणि त्यावरील पत्ता त्याच विभागाचा दुसरा, स्पर्धक मालक तयार करेल। हाच तो दुरुस्ती आहे जी बहुतेक हाताने लिहिलेल्या पाककृती चुकीच्या पद्धतीने करतात: त्या TAP उपकरण आणि ब्रिज दोन्हींना पत्ता देतात, मग जोडीदार प्रत्यक्षात कोणापर्यंत पोहोचतो याचा विचार करतात।

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

जोडीदार वेगळ्या होस्ट पत्त्यासह तोच आकार वापरतो, आणि बोर्ड त्याच श्रेणीत पत्ते घेतात, गरज असल्यास संगणकाचा ब्रिज पत्ता पुढील हॉप म्हणून वापरतात। योजना मान्य होईपर्यंत दस्तऐवजी श्रेणी वापरा, आणि कार्यालय आधीच राउट करत असलेल्या कोणत्याही गोष्टीशी टक्कर होऊ नये म्हणून श्रेणी राखून ठेवा। यापैकी काहीही चालवण्यापूर्वी सदस्य पोर्टवर उरलेला पत्ता, DHCP क्लायंट आणि दुसऱ्या ब्रिजमधील सदस्यत्व नाही याची खात्री करा, आणि TAP उपकरणाचे पत्ते बोगदा संरचना असलेल्या गोष्टीद्वारे जुळवा, नंतर पत्ता पुनर्संचयित होऊ नये म्हणून।

प्रत्येक बेंचसाठी एक समर्पित पोर्ट का

समर्पित वायर्ड पोर्टच प्रयोगाला कार्यालयभराचा बदल होण्यापासून रोखतो। व्यवस्थापन इंटरफेस SSH, डीफॉल्ट मार्ग आणि बाहेरचे VPN कनेक्शन वाहतो, आणि त्यातील काहीही लॅब फ्रेम्स हलवणे हे ज्याचे उद्दिष्ट आहे अशा ब्रिजवर नसावे।

व्यवस्थापन अडॅप्टर जोडल्याने कार्यालयाचे LAN विकास बोर्डापासून एका फॉरवर्डिंग निर्णयाच्या अंतरावर येते, आणि स्तर दोनवर गैरवर्तन करणारा बोर्ड हा त्याच विभागात तुम्हाला नको असलेला उपकरणाचा प्रकार आहे। Wi-Fi अडॅप्टर त्याहून वाईट: इन्फ्रास्ट्रक्चर मोडमध्ये वायरलेस इंटरफेस ब्रिज करणे Ethernet ब्रिज करण्यासारखे वागत नाही, आणि अपयश स्वच्छ नसून गोंधळात टाकणारे असते।

लॅब श्रेणी कोणत्याही उत्पादन DHCP व्याप्तीबाहेर ठेवा। बोर्डांना पुढे गतिशील पत्ते लागल्यास, एका पूलसह एक अधिकृत वाटपकर्ता हीच एकमेव व्यवस्था अंदाजे राहते; एकाच विभागात उत्तर देणारे दोन ठिकाणांचे सामान्य राउटर असे पत्ते तयार करतात जे कोणीही समजावून सांगू शकत नाही।

ब्रिज तयार करत नसलेली सीमा

ब्रिज करणे म्हणजे राउटिंग नाही, आणि ते वेगळे करणेही नाही। ब्रिज ओलांडणारी फ्रेम्स स्थापित bridge-netfilter मार्गानुसार होस्टच्या फिल्टरिंग हुकपर्यंत पोहोचू शकतात, म्हणून प्रभावी धोरण गृहीत न धरता तपासले पाहिजे। एक फ्रेम गेल्यामुळे फायरवॉल बंद करणे हे विशिष्ट बग सामान्य बगशी बदलते।

ब्रिज आणि प्रत्येक व्यवस्थापन किंवा अपलिंक इंटरफेस दरम्यान IP फॉरवर्डिंग बंद राहिले पाहिजे किंवा स्पष्टपणे नाकारले पाहिजे, आणि हे ब्रिज सदस्यत्वापासून वेगळे नियंत्रण आहे। संगणकाच्या लॅब पत्त्याला गेटवे म्हणून निवडणारा बोर्ड नेमके हेच तपासतो: व्यवस्थापन पारगमन यशस्वी झाल्यास, तुम्ही ठरवलेली सीमा कधीच नव्हती।

अजून दोन कुटुंबे स्पष्ट निर्णयास पात्र आहेत। पत्ता योजना ब्रिजला केवळ IPv4 करत नाही, म्हणून IPv6 आणि इतर EtherTypesांना स्वतःची योजना किंवा फिल्टर आवश्यक आहे। आणि यशस्वी ping बोर्डाचे शोध ब्रॉडकास्ट, मल्टिकास्ट गट किंवा जंबो फ्रेम्स मार्ग ओलांडतील याबद्दल काहीही सांगत नाही, कारण ते वेगवेगळ्या डीफॉल्टसह वेगवेगळे रहदारी वर्ग आहेत।

शेवटी, वाहतूक आणि गोपनीयता या दोन वेगळ्या खरेदी आहेत। TAP Ethernet वाहतो; OpenVPN सेवा त्याभोवती संरक्षण पुरवते। VXLAN आच्छादनही Ethernet वाहते आणि स्वतःच गोपनीयता देत नाही, म्हणून एकाची दुसऱ्याने जागा घेतल्यास टोपोलॉजी आकृती सारखी दिसली तरी सुरक्षा गुणधर्म बदलतात।

टिकाऊपणा आणि ते सिद्ध करणार्या चाचण्या

जोडल्यानंतर एकदा टाइप केलेला आदेश संरचना नाही। ब्रिज, पोर्ट सदस्यत्व आणि एकमेव होस्ट पत्ता संगणकाच्या विद्यमान नेटवर्क व्यवस्थापकाद्वारे टिकाऊ करा, आणि जोडणी TAP उपकरणाच्या प्रकट होण्याशी जोडा, पुन्हा जोडल्यावर सदस्य हरवलेला ब्रिज राहू नये म्हणून।

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

नंतर बोर्डांना दोन्ही दिशांनी प्रत्यक्षात काय आवश्यक आहे ते तपासा, बोगदा पुन्हा जोडा, आणि मंजूर पुनर्प्राप्ती योजनेनुसार एक संगणक पुन्हा सुरू करा। नंतर तीन गोष्टी निश्चित करा: व्यवस्थापन प्रवेश अजूनही स्वतंत्रपणे काम करतो, दुहेरी लॅब पत्ता दिसत नाही, आणि कोणताही अनपेक्षित उत्पादन इंटरफेस ब्रिजमध्ये सामील झालेला नाही। हेच संयोजन प्रयोग त्याच्या बेंचमध्येच राहिला याचा पुरावा आहे।