एक ही होस्ट से 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 पथ वाले क्लाइंट के लिए उन्नयन के बजाय पहुँच का उपाय है।