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 र अन्य EtherType हरूलाई आफ्नै योजना वा फिल्टर चाहिन्छ। र सफल ping ले बोर्डका खोज प्रसारण, मल्टिकास्ट समूह वा जम्बो फ्रेमहरू मार्ग पार गर्छन् कि भन्नेबारे केही भन्दैन, किनकि ती फरक पूर्वनिर्धारित भएका फरक ट्राफिक वर्ग हुन्।

अन्तमा, ढुवानी र गोपनीयता दुई फरक खरिद हुन्। TAP ले Ethernet बोक्छ; OpenVPN सेवाले त्यसको वरिपरि सुरक्षा दिन्छ। VXLAN ओभरले पनि Ethernet बोक्छ र आफैंमा कुनै गोपनीयता दिँदैन, त्यसैले एउटालाई अर्कोले बदल्दा टोपोलोजी रेखाचित्र उस्तै देखिए पनि सुरक्षा गुणहरू बदलिन्छन्।

स्थायित्व र यसलाई प्रमाणित गर्ने परीक्षणहरू

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

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

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