एउटै होस्टबाट TCP र UDP मा OpenVPN सेवा दिने
2.7 अघि एउटा प्रक्रियाले एउटै ट्रान्सपोर्ट बाँध्छ। ब्रिज गरिएको TAP जोडी, दुई TUN सबनेट र साझा पूल तुलना गर्नुहोस्, त्यसपछि प्रत्येक प्रोफाइललाई यसको सुन्नेसँग मिलाउनुहोस्।
TCP 443 मात्र अनुमति दिने सञ्जालहरू UDP सहजै पार गर्न दिने सञ्जालहरूसँगै रहन्छन्, र एउटा सर्भरले दुवैलाई सेवा दिनुपर्छ। proto udp भएको प्रोफाइल दोस्रो समूहलाई जवाफ दिन्छ र पहिलोमा असफल हुन्छ, र proto tcp भन्नका लागि त्यही कन्फिगरेसन सम्पादन गर्दा दोस्रो सुन्ने बन्दैन। यो निर्देशनले एउटा प्रक्रियाका लागि एउटै ट्रान्सपोर्ट छान्छ। बाँकी सबै त्यही सीमाबाट आउँछ।
एकभन्दा बढी प्रक्रिया चलाउनुहोस्, वा एकैचोटि धेरै सकेट बाँध्न सक्ने संस्करण चलाउनुहोस्।
2.7 अघि एउटा प्रक्रियाले एउटै ट्रान्सपोर्ट बाँध्छ
समुदायको OpenVPN ले proto वर्णन गर्ने सकेट बाँध्छ, र त्यो निर्देशनले इन्स्टेन्सका लागि एउटै ट्रान्सपोर्ट छान्छ। TCP र UDP छुट्टै स्ट्याक हुन्, त्यसैले एउटै पोर्ट नम्बर दुवैले एकै समयमा ओगट्न सक्छन्, तर एउटा प्रक्रियाले सक्दैन। त्यसैले 2.6 शृंखलाले तपाईंलाई प्रत्येक डेमनका लागि एउटा ट्रान्सपोर्ट दिन्छ। OpenVPN 2.7 ले सर्भरहरूका लागि त्यो सीमा हटायो, जसले एउटै प्रक्रियामा धेरै --local कथनहरूमार्फत धेरै सकेट बाँध्न सक्छन्।
कुनै पनि जवाफको वरिपरि डिजाइन गर्नुअघि संस्करण जाँच्नुहोस्, किनकि 2.7 को व्यवस्था आफ्नै कन्फिगरेसन सिन्ट्याक्स भएको फरक सञ्चालन मोडेल हो। 2.6 का लागि लेखिएको गाइडले नभने पनि दुई प्रक्रियाको वर्णन गर्छ।
दुई इन्स्टेन्स चलाउने तीन तरिका
TAP इन्टरफेससँग, प्रत्येक ट्रान्सपोर्टका लागि एउटा इन्स्टेन्स चलाउनुहोस् र होस्टमा दुई tap यन्त्र ब्रिज गर्नुहोस्। दुवै क्लाइन्ट समूह एउटै ब्रोडकास्ट डोमेनमा पुग्छन्, जसले एउटै ठेगाना पूलले तिनीहरूलाई ढाक्न दिन्छ र ब्रोडकास्टमा निर्भर प्रोटोकलहरू चलिरहन्छन्। TUN सँग ब्रिजिङ उपलब्ध हुँदैन, त्यसैले सरलतम विभाजनले प्रत्येक इन्स्टेन्सलाई आफ्नै सबनेट दिन्छ र राउटिङले दुवै क्लाइन्ट समूह अलग राख्छ। तेस्रो विकल्पले एउटै पूल राख्छ: प्रत्येक इन्स्टेन्सले learn-address स्क्रिप्ट बोलाउँछ, जसले त्यो इन्स्टेन्सको यन्त्रबाट क्लाइन्टका लागि /32 रुट स्थापना गर्छ।
त्यो तेस्रो व्यवस्था मानिसहरूले माग्ने र सबैभन्दा धेरै होसियारी चाहिने हो, किनकि स्क्रिप्ट डाटा मार्गको भाग बन्छ र थप्ने, अद्यावधिक गर्ने र मेट्ने घटनाहरू ठीकसँग व्यवस्थापन गर्नुपर्छ।
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
दुई इन्स्टेन्स अलग राख्नुहोस्
प्रत्येक इन्स्टेन्सलाई अलग पोर्ट वा ठेगाना, अलग स्थिति फाइल र अलग लग गन्तव्य पनि चाहिन्छ। एउटै स्थिति फाइलमा थप्ने दुई डेमनले घटनाको समयमा पढ्न नसकिने आउटपुट बनाउँछन्, र ठीक त्यही बेला त्यो चाहिन्छ। दोस्रो इन्स्टेन्सले कुनै निश्चित ठेगाना बाँध्छ भने प्रक्रिया सुरु हुँदा त्यो ठेगाना होस्टमा हुनुपर्छ; नभए कुञ्जीबारे केही भन्नुअघि नै त्यो बाइन्ड असफलतासँग बाहिरिन्छ।
युनिट र प्रोफाइललाई फाइल नामबाटै ट्रान्सपोर्ट स्पष्ट हुने गरी नाम दिनुहोस्। अर्को अपरेटरले कुन TCP हो भन्ने थाहा पाउन कन्फिगरेसन खोल्नु नपर्ने हुनुपर्छ।
प्रोफाइललाई सुन्नेसँग मिलाउनुहोस्
proto tcp चलाउने सर्भरले proto tcp-client भएको क्लाइन्ट प्रोफाइल अपेक्षा गर्छ, र अझै proto udp बोकेको प्रोफाइल त्यो सुन्नेसामु प्रयोगकर्ताले कारबाही गर्न सक्ने त्रुटि बिनै समय सकिएर रोकिन्छ। तैनाथीले दुवै ट्रान्सपोर्ट दिन्छ भने दुई प्रोफाइल राख्नुहोस्, र कुन प्रयास गरियो भन्ने सहयोगले थाहा पाउने गरी लेबल गर्नुहोस्। पोर्ट नम्बर मात्रले ट्रान्सपोर्ट वर्णन गर्दैन।
फायरवाल नियमहरू त्यही विभाजन पछ्याउँछन्: UDP 1194 का लागि नियमले TCP 1194 बारे केही भन्दैन, र एउटा ठेगानाका लागि नियमले अर्को सुन्ने ढाक्दैन।
पहिले सर्भरको दृश्य पढ्नुहोस्
सर्भरमा ss -lntup बाट सुरु गर्नुहोस् र TCP र UDP दुवै सुन्ने देखिन्छन् भनी पुष्टि गर्नुहोस्। त्यसपछि प्रत्येक प्रकारको एक क्लाइन्ट जोड्नुहोस् र फरक ठेगाना भएका दुई प्रविष्टिका लागि स्थिति आउटपुट जाँच्नुहोस्। सकेट छन् तर क्लाइन्ट आउँदैन भने डेमनले तिनीहरूलाई देख्नुअघि नै मार्ग वा फायरवालले प्याकेट अस्वीकार गर्दैछ।
कहिल्यै नदेखिने सकेट कन्फिगरेसन वा बाइन्डको समस्या हो, र देखिए पनि कहिल्यै जडान अभिलेख नगर्ने सकेट फिल्टरिङको समस्या हो। क्लाइन्टबाट दुवै उस्तै देखिन्छन्, त्यसैले सर्भरको आफ्नै दृश्य पहिले आउँछ। TCP मा हेड-अफ-लाइन ब्लकिङ हुन्छ, त्यसैले यो दिनु सफा UDP मार्ग भएका क्लाइन्टका लागि सुधार नभई पहुँचको उपाय हो।