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

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