एक TAP सर्वर या कई? ब्रिज पर OpenVPN क्लाइंट

कई TAP क्लाइंट के लिए हर एक का अलग सर्वर प्रक्रिया, अलग UDP पोर्ट और होस्ट पर अलग TAP उपकरण ज़रूरी नहीं है। Ethernet मोड में एक OpenVPN सर्वर कई प्रमाणित क्लाइंट स्वीकार कर सकता है और उन्हें एक ही ब्रिज से जोड़ सकता है, और परत 2 के किसी खंड को बढ़ाने का यही प्रलेखित तरीका है। एक-प्रक्रिया वाला डिज़ाइन वही है जिसे मैनुअल प्रलेखित करता है, और आम तौर पर यही सही डिफ़ॉल्ट है।

असली सवाल यह है कि क्या उन क्लाइंट को वह खंड साझा करना चाहिए। प्रक्रियाओं की संख्या इसका उत्तर नहीं देती, क्योंकि अलगाव के गुण टोपोलॉजी से आते हैं, यह से नहीं कि कितने डेमॉन चल रहे हैं। इस तुलना का बाकी हिस्सा दो टोपोलॉजी और यह कि हर एक क्या आसान बनाती है, पर है।

दो आर्किटेक्चर, दो सेटिंग नहीं

रूटेड TUN परिनियोजन हर क्लाइंट को सर्वर के रूटिंग डोमेन में पॉइंट-टू-पॉइंट लिंक देता है। ब्रॉडकास्ट सर्वर पर रुक जाते हैं, क्लाइंट एक-दूसरे के फ़्रेम नहीं देख सकते, और क्लाइंट के बीच ट्रैफ़िक हो तो उसे स्पष्ट रूप से रूट और फ़िल्टर करना पड़ता है।

ब्रिज वाला TAP परिनियोजन क्लाइंट को एक ही Ethernet खंड का सदस्य बना देता है। वे ब्रॉडकास्ट देखते हैं, ARP से एक-दूसरे को हल कर सकते हैं, और अलग रहने के लिए रूटिंग के बजाय ब्रिज और फ़ायरवॉल नीति पर निर्भर करते हैं। यह तब उपयोगी है जब क्लाइंट ऐसे दिखने चाहिए जैसे वे उसी स्विच में लगे हों।

इसलिए तुलना इस बात की है कि क्लाइंट को कहाँ पहुँचना है, प्रदर्शन की नहीं। पहले परत चुनें, फिर तय करें कि कितनी प्रक्रियाएँ उसकी सेवा करेंगी।

server-bridge सहायक क्या करता है

server-bridge सहायक बहु-क्लाइंट Ethernet मोड कॉन्फ़िगर करता है। इसका पता-पूल रूप गेटवे, नेटमास्क और ब्रिज वाले सबनेट के भीतर एक समर्पित श्रेणी लेता है, जैसे 192.168.50.1 पर गेटवे और 192.168.50.160 से 192.168.50.199 तक पूल।

उस श्रेणी को किसी भी अन्य DHCP या स्थिर आवंटन से बाहर रखें। सहायक उससे पते आवंटित करता है, लेकिन उसी खंड पर किसी दूसरे आवंटक के साथ समन्वय नहीं करता, और दो अतिव्यापी पूल ऐसे दोहरे पते बनाते हैं जो यादृच्छिक कनेक्टिविटी विफलताओं जैसे लगते हैं। आरक्षित श्रेणी को साइट की पता योजना में लिखें ताकि अगला व्यक्ति उसे दोबारा उपयोग न करे। सर्वर कॉन्फ़िगरेशन में टिप्पणी उस रिकॉर्ड का खराब विकल्प है।

ऐसे परिनियोजन के लिए DHCP-प्रॉक्सी रूप मौजूद है जहाँ बाहरी सर्वर पते बाँटता है। इसकी अपनी पूर्वशर्तें हैं, और दोनों रूपों को मिलाने से ठीक वही टकराव पैदा होता है जिसकी दस्तावेज़ चेतावनी देते हैं। ब्रिज वाले सबनेट के लिए एक ही आवंटक चुनें।

अलगाव प्रक्रियाओं की संख्या से नहीं आता

उसी अप्रतिबंधित ब्रिज से जुड़ी आठ OpenVPN प्रक्रियाएँ अब भी एक ही ब्रॉडकास्ट डोमेन साझा करती हैं। क्लाइंट ब्रिज के आर-पार एक-दूसरे के लिए ARP भेज सकते हैं, और श्रोताओं की संख्या ने इसमें कुछ नहीं बदला।

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

अगर आवश्यकता केवल यह है कि क्लाइंट कुछ IP सेवाओं तक पहुँचें, तो रूटेड TUN डिज़ाइन आम तौर पर ब्रिजिंग और फ़िल्टरिंग से सरल है। हर क्लाइंट को अपना लिंक मिलता है, और नीति ब्रिज के भीतर के बजाय रूटिंग और फ़ायरवॉल नियमों में रहती है।

कब कई प्रक्रियाएँ फिर भी सही हैं

अलग प्रक्रियाओं को परिचालन आवश्यकताओं से उचित ठहराया जा सकता है: अलग प्रमाणीकरण बैकएंड, अलग प्रमाणपत्र प्राधिकरण, अलग अपग्रेड चक्र, या असंगत विकल्प-समुच्चय। ये वास्तविक कारण हैं और क्लाइंट संख्या से स्वतंत्र हैं।

अगर कई उपयोग करें, तो हर एक को अपना श्रोता और उपकरण-स्वामित्व दें और पता श्रेणियों का समन्वय करें। जो दो सर्वर दोनों मानते हैं कि उसी ब्रिज पर वही पूल उनका है, वे अंततः वही पता बाँटने लगेंगे।

फिर डिज़ाइन को एक साथ कई क्लाइंट के साथ सत्यापित करें। जाँचें कि पते अद्वितीय हैं, क्लाइंट के बीच इच्छित ट्रैफ़िक काम करता है, और जिस जोड़ी को संवाद नहीं करना चाहिए वह नहीं कर सकती। एक क्लाइंट का सफल पिंग बहु-क्लाइंट डिज़ाइन का कुछ भी परखता नहीं।

आरेख पर भरोसा करने से पहले चल रहे होस्ट से ब्रिज और सर्वर मोड पढ़ें। जो कॉन्फ़िगरेशन मायने रखता है वही है जो कर्नेल और डेमॉन ने वास्तव में लोड किया, और वही वह भी है जिसे समीक्षक जाँच सकता है।