एउटा 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 डिजाइन सामान्यतया ब्रिजिङ र फिल्टरिङभन्दा सरल हुन्छ। प्रत्येक क्लाइन्टले आफ्नै लिङ्क पाउँछ, र नीति ब्रिजभित्र होइन, राउटिङ र फायरवाल नियमहरूमा बस्छ।

कहिले धेरै प्रक्रिया अझै उपयुक्त

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

धेरै प्रयोग गर्नुहुन्छ भने प्रत्येकलाई आफ्नै श्रोता र यन्त्र-स्वामित्व दिनुहोस् र ठेगाना दायराहरू समन्वय गर्नुहोस्। एउटै ब्रिजमा एउटै पूल आफ्नो हो भनी दुवै सर्भरले माने अन्ततः तिनीहरूले उही ठेगाना दिन्छन्।

त्यसपछि एकैचोटि धेरै क्लाइन्टसँग डिजाइन प्रमाणित गर्नुहोस्। ठेगानाहरू अद्वितीय छन् कि, क्लाइन्टबीचको अभीष्ट ट्राफिक चल्छ कि, र जोडीले सञ्चार गर्नु नहुने हो भने गर्न सक्दैन कि जाँच्नुहोस्। एउटा क्लाइन्टको सफल पिंगले बहु-क्लाइन्ट डिजाइनको केही पनि परीक्षण गर्दैन।

रेखाचित्रमा विश्वास गर्नुअघि चलिरहेको होस्टबाट ब्रिज र सर्भर मोड पढ्नुहोस्। महत्त्वपूर्ण कन्फिगरेसन त्यही हो जो कर्नेल र डेमनले वास्तवमै लोड गरे, र समीक्षकले जाँच्न सक्ने पनि त्यही हो।