एका होस्टवरून 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 मार्ग असलेल्या क्लायंटसाठी सुधारणा नसून पोहोचक्षमतेचे उपाय आहे।