के प्रत्येक 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 नहुनु खुला ढोका किन होइन
गन्तव्य नभएको प्रक्रियाले पनि प्रमाणीकरण नगर्ने पियरहरूको ट्राफिक अस्वीकार गर्छ, र मानिसहरूले अनुपस्थित लाइनलाई सबैका लागि खुला श्रोताका रूपमा पढ्दा यही भाग छुटाउँछन्।
प्रमाणीकरण र गन्तव्य स्वतन्त्र छन्, र विश्वासका लागि पहिलो नै महत्त्वपूर्ण छ।
उल्टो गल्ती बढी खतरनाक छ। स्थिर स्रोत ठेगाना पहुँच नियन्त्रणजस्तो लाग्न सक्छ किनभने यो विशिष्ट र जाँच्न सजिलो छ, तर अर्को छेउमा को छ भन्नेबारे यसले केही प्रमाणित गर्दैन। प्रमाणपत्र प्रमाणीकरण राख्नुहोस्, र प्रमाणपत्रलाई यसको भूमिकासँग बाँध्ने पहिचान जाँचहरू पनि राख्नुहोस्। तिनलाई ठेगाना मिलानले बदल्नु भनेको वास्तविक नियन्त्रणलाई यसको देखावटसँग साट्नु हो।
कन्फिगरेसनले के मान्छ लेख्नुहोस्
प्रत्येक पक्षका लागि तीन कुरा अभिलेख गर्नुहोस्: पहिलो प्याकेट पियरसम्म कसरी पुग्छ, कुन पक्षले ट्रान्सपोर्ट स्वीकार गर्न सक्छ, र प्रत्येक पक्षले अर्कोबारे के प्रमाणित गर्छ।
ती मान्यताहरू नै डिजाइन हुन्। निर्देशनहरू तिनको हिज्जे मात्र हुन्।
यदि दुई फाइल फरक छन् भने, एउटा गलत छ भनी मान्नुको सट्टा तिनले फरक मान्यता व्यक्त गर्छन् कि जाँच्नुहोस्। सममित फाइल जोडी काम गर्ने सुरुङका लागि न आवश्यक छ न पर्याप्त, र असममितता नै प्रायः टोपोलोजीलाई काम गराउने भाग हो।