क्या आपके OpenVPN क्लाइंट को nobind या निश्चित पोर्ट उपयोग करना चाहिए?

एक ही पंक्ति से भिन्न दो प्रोफ़ाइल उसी होस्ट पर दूसरा क्लाइंट शुरू होते ही अलग व्यवहार करती हैं। एक nobind रखती है और कर्नेल जो भी स्थानीय पोर्ट देता है उसे ले लेती है; दूसरी 1194 आरक्षित करती है, और दूसरा इंस्टेंस पहले से उपयोग में लिए पते के साथ मर जाता है। यही पंक्ति तय करती है कि स्रोत पोर्ट कौन चुनता है, जो आगे तय करता है कि प्रोफ़ाइल मशीन पर किसी और चीज़ के साथ रह सकती है या नहीं। तीन प्रश्न इसे तय करते हैं, और पहला प्रश्न बाकी दो तक पहुँचने से पहले अधिकांश प्रोफ़ाइलों का उत्तर देता है।

nobind असल में क्या छोड़ देता है

डिफ़ॉल्ट रूप से क्लाइंट कॉल करने से पहले स्थानीय सॉकेट बाँधता है, और प्रोफ़ाइल कुछ और न कहे तो स्थानीय पोर्ट 1194 होता है। nobind उस आरक्षण को हटा देता है, इसलिए स्टैक कनेक्शन के समय कोई अप्रयुक्त पोर्ट आवंटित करता है। यह अपवाद है, डिफ़ॉल्ट नहीं, और बिना पंक्ति वाला क्लाइंट 1194 रखता है, इसीलिए पिन न किया गया दूसरा इंस्टेंस टकराता है। अधिकांश वितरित क्लाइंट प्रोफ़ाइल इसी कारण यह निर्देश रखती हैं, और किसी नमूना फ़ाइल का कुछ करना इसके बराबर नहीं है कि तंत्र डिफ़ॉल्ट रूप से वही करे।

जो नहीं बदलता वह दूर का छोर है। सर्वर अब भी वहीं सुनता है जहाँ प्रोफ़ाइल कहती है कि वह सुनता है, और कॉन्फ़िगरेशन में गंतव्य पोर्ट अब भी गंतव्य पोर्ट है। गतिशील स्रोत पोर्ट आपके अपने सॉकेट का वापसी पता बदलता है, सर्वर के सॉकेट का कुछ नहीं।

यह कुछ छिपाता भी नहीं। आपका सार्वजनिक पता वही है जिसमें मार्ग उसे अनुवादित करता है, पैकेट अब भी स्थानीय नेटवर्क से गुजरता है, और जो उस नेटवर्क को चलाता है वह अब भी एक प्रवाह देखता है। nobind न गोपनीयता की विशेषता है न फ़ायरवॉल से बचने का रास्ता।

तीन शर्तें जो इसे तय करती हैं

एक प्रश्न बाकी दोनों को तय करता है, इसलिए कुछ भी संपादित करने से पहले उसका उत्तर दें। यदि साथी बाहर कॉल करता है, तो बाकी प्रश्न केवल पहले से लिए गए निर्णय को और स्पष्ट करते हैं। यदि यह आवक कनेक्शन स्वीकार करता है, तो स्थानीय पोर्ट का कोई भी समायोजन इसे पहुँच-योग्य नहीं बनाता।

क्या यह साथी कनेक्शन शुरू करता है? यदि यह बाहर कॉल करता है, तो गतिशील स्रोत पोर्ट हानिरहित है और आमतौर पर बेहतर, क्योंकि उत्तर उसी प्रवाह से वापस आता है। यदि यह आवक कनेक्शन की प्रतीक्षा करता है, तो गतिशील पोर्ट इसे अगम्य बना देता है, जब तक कि आगे कुछ पोर्ट प्रकाशित न करे। वही एक उत्तर हर क्लाइंट प्रोफ़ाइल को हर सर्वर प्रोफ़ाइल से अलग करता है।

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

क्या कई इंस्टेंस होस्ट साझा करते हैं? एक निश्चित पोर्ट उनमें से दो की सेवा नहीं कर सकता, और पुनः आरंभ किया गया इंस्टेंस 1194 को अब भी बंद होने की स्थिति में पा सकता है। गतिशील पोर्ट बाकी कुछ बदले बिना वह टकराव हटा देते हैं। यदि आप इसका उत्तर आत्मविश्वास से नहीं दे सकते, तो हाँ मान लें और कर्नेल को चुनने दें।

जहाँ पिन किया गया पोर्ट सही उत्तर है

कुछ नेटवर्क गंतव्य के साथ-साथ स्रोत पोर्ट पर भी फ़िल्टर करते हैं, इसलिए ऑपरेटर ने ऐसा नियम लिखा हो सकता है जो केवल एक ज्ञात पोर्ट से ट्रैफ़िक गुज़ारता है। तब स्थानीय पोर्ट पिन करना सही है, और प्रोफ़ाइल को एक टिप्पणी रखनी चाहिए जो उस नियम का नाम ले जिसे वह पूरा करती है। सर्वर पोर्ट के साथ समरूपता के लिए पिन करना कारण नहीं है, क्योंकि दोनों संख्याओं का एक-दूसरे से कोई संबंध नहीं है। यदि पिन केवल इसलिए है कि टेम्पलेट में था, तो उसे हटा दें।

अन्यथा पिन किया गया पोर्ट मुसीबत खरीदता है: एक मशीन पर दो क्लाइंट दोनों 1194 नहीं रख सकते, और दूसरा ऐसी त्रुटि से विफल होता है जो प्रोफ़ाइल के बजाय पोर्ट की ओर इशारा करती है। तेज़ी से पुनः आरंभ होने वाला कंटेनर उसी दीवार से टकराता है। मरम्मत वह निर्देश है जो वितरित प्रोफ़ाइलों में पहले से था।

सर्वर और क्लाइंट सममित नहीं हैं

OpenVPN 2.6 मैनुअल को nobind के बगल में lport रखता है, जो एक पंक्ति में तर्क है: एक विकल्प कहता है कि कर्नेल चुनता है, दूसरा कहता है कि आप चुनते हैं। गतिशील स्थानीय पोर्ट केवल उसी साथी के लिए काम करता है जो बाहर कॉल करता है, क्योंकि उत्तर देने वाला पक्ष पोर्ट पहले से नहीं जान सकता। इसीलिए क्लाइंट प्रोफ़ाइल को सर्वर पर नकल करने से ऐसा श्रोता बनता है जहाँ कोई पहुँच नहीं सकता।

कई नेटवर्क इंटरफ़ेस वाले होस्ट पर पता पोर्ट से अलग निर्णय है। किसी विशिष्ट स्थानीय पते को बाँधना और किसी विशिष्ट पोर्ट को बाँधना दो अलग सेटिंग हैं, और दो अपलिंक वाला सर्वर आमतौर पर दोनों पिन करता है। जो क्लाइंट दोनों पिन करता है उसने बिना किसी लाभ के वही कठोरता अपना ली है।

सारांश भूमिकाओं के बारे में है, सुरक्षा के बारे में नहीं: जो बाहर कॉल करता है वह अपने स्रोत के बारे में लचीला हो सकता है, और जो उत्तर देता है वह नहीं। कोई भी विकल्प यह नहीं बदलता कि दूसरा पक्ष आपकी पहचान के बारे में क्या सीखता है। इसीलिए यह निर्देश क्लाइंट नमूनों में दिखता है और सर्वर नमूनों में लगभग कभी नहीं।

कर्नेल द्वारा चुना गया पोर्ट सत्यापित करें

कनेक्ट करने के बाद कॉन्फ़िगरेशन नहीं, सॉकेट पढ़ें, क्योंकि कॉन्फ़िगरेशन इरादा बताता है और सॉकेट बताता है कि क्या हुआ। दर्ज करने योग्य तथ्य स्थानीय पोर्ट, दूर का अंतिम बिंदु और यह कि कुछ अब भी सुन रहा है या नहीं। Linux होस्ट पर तीनों एक आदेश की दूरी पर हैं।

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

क्लाइंट nobind के साथ उच्च स्थानीय पोर्ट और कॉन्फ़िगर किया गया दूर का पोर्ट दिखाता है, जो अपेक्षित आकार है। सर्वर अपने कॉन्फ़िगर किए गए पोर्ट पर सुनता सॉकेट दिखाता है, और यदि वह सॉकेट न हो तो प्रोफ़ाइल या तो श्रोता नहीं है या बाँध नहीं सकी। जब प्रवाह हो पर पैकेट वापस न आएँ, तो प्रोफ़ाइल संपादित करने से पहले चुने गए स्रोत पोर्ट की मार्ग पर किसी भी पोर्ट फ़िल्टर से तुलना करें। एक चीज़ बदलें, फिर कनेक्ट करें और सॉकेट फिर पढ़ें।