प्रत्येक OpenVPN पीअरला remote ओळ आवश्यक आहे का? तंतोतंत नाही
remote पहिले पॅकेट कुठे जाते हे सांगते; ते क्लायंट, सर्व्हर किंवा TLS भूमिका निवडत नाही. दोन्ही बाजूंना कॉपी करण्यापूर्वी रचना वाचा.
दोन पीअर कॉन्फिगरेशनची शेजारी शेजारी तुलना केली जाते, एकात remote ओळ आहे आणि दुसऱ्यात नाही, आणि निष्कर्ष असा आहे की त्यापैकी एक खराब आहे. हा निष्कर्ष पुरेसा वेळा चुकीचा असतो की त्याचे विश्लेषण करणे योग्य ठरते. सूचना पहिले पॅकेट कुठे पाठवायचे हे वर्णन करते. ती प्रक्रिया सुरू करणारा क्लायंट किंवा प्रतीक्षा करणारा गेटवे म्हणून कार्य करते का हे निवडत नाही, आणि कोणती बाजू दुसऱ्यासमोर आपली ओळख सिद्ध करते हेही ठरवत नाही.
remote प्रत्यक्षात काय निर्दिष्ट करते
remote नोंद एक होस्ट, पर्यायाने पोर्ट आणि ट्रान्सपोर्ट, आणि पर्यायाने क्रमाने प्रयत्न करायच्या अशा अनेक नोंदी नाव देते.
त्याची अनुपस्थिती अस्पष्ट नसून निश्चित अर्थ दर्शवते: प्रक्रिया प्रतीक्षा करते आणि तो पीअर प्रमाणीकरण करत नाही तोपर्यंत कोणत्याही पत्त्यावरून येणाऱ्या पॅकेटवर कार्य करत नाही. म्हणून फिरत्या वापरकर्त्यांना सेवा देणाऱ्या गेटवेला त्यांच्यापैकी कोणाचेही नाव आधीच देण्याचे कारण नाही.
नोंद पत्ता-संबंध म्हणून वाचा. दूरचे टोक विश्वासार्ह आहे का हे प्रमाणपत्रे आणि पडताळणी पर्याय सांगतात, पत्ता लिहिला गेला ही गोष्ट नाही.
तीन रचना उत्तर ठरवतात
फिरत्या क्लायंटला गंतव्य आवश्यक आहे, कारण त्याला सुरुवात करावी लागते आणि त्याशिवाय गेटवे कुठे आहे हे त्याला माहीत नाही. अनेक-क्लायंट गेटवेला प्रति-वापरकर्ता गंतव्याची गरज नाही, कारण क्लायंट येतात आणि प्रमाणीकरण करतात. ज्ञात टोकांच्या जाणीवपूर्वक दोन-पीअर दुव्याला एका बाजूला, दोन्ही बाजूंना किंवा कोणत्याही बाजूला गंतव्य असू शकते, कोणती बाजू सुरुवात करते यावर अवलंबून.
सामान्य गेटवेमध्ये स्थिर क्लायंट पत्ता चिकटवणे ही त्या श्रेणींकडे दुर्लक्ष केल्यामुळे येणारी चूक आहे. ती ज्या एकाच पीअरचा पत्ता नोंदवला गेला त्याला काम करते आणि बाकी सर्वांना दिशाभूल करते.
सूचनेत कॉन्फिगरेशनला अनेक-क्लायंट सर्व्हर बनवणारे काहीही नाही, आणि तिच्या उपस्थितीत सर्व्हर भूमिकेला प्रतिबंध करणारे काहीही नाही. OpenVPN 2.6 संदर्भ पर्यायी वितर्क आणि remote नसतानाचे वर्तन स्वतंत्रपणे नोंदवतो, जे ते किती स्वतंत्र आहेत याचा इशारा आहे.
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
ट्रान्सपोर्ट भूमिका वेगळा अक्ष आहेत
TCP मध्ये एक बाजू प्रतीक्षा करते आणि दुसरी कॉल करते. हे गंतव्यापेक्षा वेगळे निर्देश आहेत, आणि ते मिसळल्यास दोन्ही प्रतीक्षा करणारी किंवा दोन्ही कॉल करणारी जोडी तयार होते.
TCP स्रोत-फिल्टर भूमिकाही आहे, म्हणून सर्व्हरमध्ये कधीही remote नसावे हे सपाट विधान चुकीचे आहे.
UDP मध्ये स्थापित करायचे कनेक्शन नाही, म्हणून दोन्ही टोके संबंधित UDP ट्रान्सपोर्ट वापरतात आणि सूचना फक्त कुठे लक्ष्य ठेवायचे ते सांगते. प्रमाणीकृत पीअरचे पत्ता बदल अधिक नोंदी जोडण्याऐवजी समर्पित वर्तनाने हाताळले जातात. ट्रान्सपोर्ट बरोबर असणे हे गंतव्याला अर्थ असण्याची पूर्वअट आहे, आणि दोन्ही गोंधळल्यास विश्वासार्ह दिसणारी आणि कधीही हँडशेक पूर्ण न करणारी कॉन्फिगरेशन तयार होतात.
remote नसणे खुले दार का नाही
गंतव्य नसलेली प्रक्रियाही प्रमाणीकरण न करणाऱ्या पीअरचा रहदारी नाकारते, आणि अनुपस्थित ओळ सर्वांसाठी खुला श्रोता म्हणून वाचताना लोक हा भाग चुकवतात.
प्रमाणीकरण आणि गंतव्य स्वतंत्र आहेत, आणि विश्वासासाठी पहिलेच महत्त्वाचे आहे.
उलटी चूक अधिक धोकादायक आहे. स्थिर स्रोत पत्ता प्रवेश नियंत्रणासारखा वाटू शकतो कारण तो विशिष्ट आणि तपासायला सोपा आहे, पण दुसऱ्या टोकाला कोण आहे याबद्दल तो काहीही सिद्ध करत नाही. प्रमाणपत्र पडताळणी ठेवा, आणि प्रमाणपत्राला त्याच्या भूमिकेशी जोडणाऱ्या ओळख तपासण्याही ठेवा. त्या पत्ता जुळणीने बदलणे म्हणजे खरे नियंत्रण त्याच्या दिसण्याशी बदलणे.
कॉन्फिगरेशन काय गृहीत धरते ते लिहा
प्रत्येक बाजूसाठी तीन गोष्टी नोंदवा: पहिले पॅकेट पीअरपर्यंत कसे पोहोचते, कोणती बाजू ट्रान्सपोर्ट स्वीकारू शकते, आणि प्रत्येक बाजू दुसऱ्याबद्दल काय पडताळते.
ती गृहीतके म्हणजे रचना. सूचना फक्त त्यांचे स्पेलिंग आहेत.
दोन्ही फाइली वेगळ्या असतील, तर एक चुकीची आहे असे गृहीत धरण्याऐवजी त्या वेगळी गृहीतके व्यक्त करतात का ते तपासा. सममित फाइल जोडी कार्यरत बोगद्यासाठी आवश्यकही नाही आणि पुरेशीही नाही, आणि असममितताच बहुतेक वेळा टोपोलॉजी कार्यान्वित करणारा भाग असते.