क्या हर OpenVPN पीयर को remote लाइन चाहिए? बिल्कुल नहीं

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

remote वास्तव में क्या निर्दिष्ट करता है

एक remote प्रविष्टि एक होस्ट का नाम देती है, वैकल्पिक रूप से एक पोर्ट और एक ट्रांसपोर्ट, और वैकल्पिक रूप से ऐसी कई प्रविष्टियाँ जिन्हें क्रम से आज़माया जाता है।

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

प्रविष्टि को पता-संबंध के रूप में पढ़ें। दूर का सिरा विश्वसनीय है या नहीं, इसका उत्तर प्रमाणपत्र और सत्यापन विकल्प देते हैं, कोई पता लिखा जाना नहीं।

तीन व्यवस्थाएँ उत्तर तय करती हैं

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

सामान्य गेटवे में स्थिर क्लाइंट पता चिपकाना वह गलती है जो उन श्रेणियों की अनदेखी से आती है। यह उस एकमात्र पीयर के लिए काम करती है जिसका पता दर्ज था और बाकी सभी को भ्रमित करती है।

निर्देश में ऐसा कुछ नहीं जो कॉन्फ़िगरेशन को बहु-क्लाइंट सर्वर बना दे, और इसकी उपस्थिति में ऐसा कुछ नहीं जो सर्वर भूमिका को रोके। OpenVPN 2.6 संदर्भ वैकल्पिक तर्कों और remote के बिना व्यवहार को अलग-अलग प्रलेखित करता है, जो इस बात का संकेत है कि वे कितने स्वतंत्र हैं।

ट्रांसपोर्ट भूमिकाएँ दूसरा अक्ष हैं

TCP में एक पक्ष प्रतीक्षा करता है और दूसरा कॉल करता है। ये गंतव्य से अलग निर्देश हैं, और इन्हें मिलाने से ऐसा युग्म बनता है जिसमें दोनों प्रतीक्षा करते हैं या दोनों कॉल करते हैं।

TCP स्रोत-फ़िल्टर भूमिका भी है, इसीलिए यह सपाट कथन गलत है कि सर्वर में कभी remote नहीं हो सकता।

UDP में स्थापित करने के लिए कोई कनेक्शन नहीं है, इसलिए दोनों सिरे संबंधित UDP ट्रांसपोर्ट का उपयोग करते हैं और निर्देश केवल बताता है कि कहाँ निशाना लगाना है। प्रमाणीकृत पीयर के पता-परिवर्तन अधिक प्रविष्टियाँ जोड़ने के बजाय समर्पित व्यवहार द्वारा संभाले जाते हैं। ट्रांसपोर्ट सही होना इस बात की पूर्वशर्त है कि गंतव्य का कोई अर्थ हो, और दोनों को मिलाने से ऐसे कॉन्फ़िगरेशन बनते हैं जो विश्वसनीय लगते हैं और कभी हैंडशेक पूरा नहीं करते।

remote की अनुपस्थिति खुला दरवाज़ा क्यों नहीं है

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

प्रमाणीकरण और गंतव्य स्वतंत्र हैं, और विश्वास के लिए पहला ही मायने रखता है।

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

लिखें कि कॉन्फ़िगरेशन क्या मान लेता है

हर पक्ष के लिए तीन बातें दर्ज करें: पहला पैकेट पीयर तक कैसे पहुँचता है, कौन-सा पक्ष ट्रांसपोर्ट स्वीकार कर सकता है, और हर पक्ष दूसरे के बारे में क्या सत्यापित करता है।

वे मान्यताएँ ही डिज़ाइन हैं। निर्देश केवल उनकी वर्तनी हैं।

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