एक 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 रचना सामान्यतः ब्रिजिंग व फिल्टरिंगपेक्षा सोपी असते। प्रत्येक क्लायंटला स्वतःची लिंक मिळते, आणि धोरण ब्रिजच्या आत नाही तर राउटिंग व फायरवॉल नियमांमध्ये असते।

अनेक प्रक्रिया कधी तरीही योग्य

वेगळ्या प्रक्रियांचे कारण ऑपरेशनल गरजा असू शकतात: वेगवेगळे प्रमाणीकरण बॅकएंड, वेगवेगळे प्रमाणपत्र प्राधिकरण, वेगळे अपग्रेड चक्र, किंवा विसंगत पर्याय-संच। ही खरी कारणे आहेत आणि ती क्लायंट संख्येपासून स्वतंत्र आहेत।

अनेक वापरल्यास प्रत्येकाला स्वतःचा श्रोता व उपकरण-मालकी द्या आणि पत्ता श्रेणींचे समन्वय करा। एकाच ब्रिजवर एकच पूल आपला असल्याचे दोन्ही सर्व्हर मानत असतील तर ते शेवटी तोच पत्ता देतील।

नंतर एकाच वेळी अनेक क्लायंटसह रचना पडताळा। पत्ते अद्वितीय आहेत का, क्लायंटमधील इच्छित रहदारी चालते का, आणि ज्या जोडीने संवाद करू नये ती करू शकत नाही का ते तपासा। एका क्लायंटचे यशस्वी पिंग बहु-क्लायंट रचनेतील काहीही तपासत नाही।

आकृतीवर विश्वास ठेवण्यापूर्वी चालू असलेल्या होस्टवरून ब्रिज व सर्व्हर मोड वाचा। महत्त्वाचे कॉन्फिगरेशन तेच आहे जे कर्नेल व डेमनने प्रत्यक्ष लोड केले, आणि समीक्षकही तेच तपासू शकतो।