स्थिर OpenVPN ठेगानाहरू स्रोत IP नभई पहिचानको पालना गर्नुपर्छ

‘यो ल्यापटपले 10.90.0.10 पाउँछ’ भन्ने ठेगाना योजनाहरू वास्तवमा पहिचानको बारेमा कथन हुन्: कुन प्रमाणित यन्त्रले त्यो ठेगाना राख्न सक्छ। त्यो यन्त्रको हालको सार्वजनिक IP सँग यसको लगभग कुनै सम्बन्ध छैन, किनभने NAT र रोमिङले प्रयोगकर्ता को हो भन्ने नबदली त्यसलाई बदल्छन्। स्रोत ठेगानामा योजना बनाउँदा पहिलो होटल सञ्जालमै भाँचिने नियमहरू बन्छन्। प्रमाणित पहिचानमा योजना बनाउँदा यात्रामा टिक्ने योजना बन्छ।

सर्भरले प्रमाणित गर्न सक्ने कुराबाट सुरु गर्नुहोस्, त्यसपछि ठेगाना केका लागि हो भनेर निर्णय गर्नुहोस्।

ठेगानाअघि पहिचानको कुञ्जी छान्नुहोस्

प्रत्येक यन्त्रका लागि छुट्टै क्लाइन्ट प्रमाणपत्रले सर्भरलाई प्रत्येक सदस्यका लागि स्थिर, प्रमाणित गर्न सकिने कुञ्जी दिन्छ, जुन स्थिर बाँडफाँटका लागि सबैभन्दा सफा आधार हो। प्रयोगकर्ता-आधारित प्रमाणीकरण प्रयोग गर्ने तैनाथीले यसको सट्टा प्रयोगकर्ता नाममा भर पर्न सक्छ, यदि कन्फिगरेसन छनोटले त्यही क्षेत्रलाई पछ्याउँछ। दुवै मोडेल मिसाउँदा एउटा क्लाइन्टका लागि प्रमाणपत्र र अर्कोका लागि प्रयोगकर्ता नामसँग मिल्ने बाँडफाँट बन्छ, र कसले जित्छ भन्ने कसैले अनुमान गर्न सक्दैन। एउटा पनि आरक्षण लेख्नुअघि योजनाले कुन कुञ्जी प्रयोग गर्छ भनेर निर्णय गर्नुहोस्।

duplicate-cn सँग, धेरै एकैसाथ चलिरहेका सत्रहरूले एउटै सामान्य नाम प्रस्तुत गर्न सक्छन्, त्यसैले एउटा पिन गरिएको ठेगानाले तिनीहरूलाई अलग-अलग पहिचान गर्न सक्दैन। यो पहिचान मोडेलको विशेषता हो, राम्रो ठेगाना योजनाले सुधार्न सक्ने कुरा होइन।

गतिशील दायराबाहिर ठेगानाहरू आरक्षित गर्नुहोस्

10.90.0.0/24 जस्ता सबनेट-टोपोलोजी सञ्जालमा, नामित सदस्यहरूका लागि तल्ला ठेगानाहरू राख्नुहोस् र गतिशील पूल अलग दायरामा राख्नुहोस्। पिन गरिएको सदस्यको बाँडफाँट यस्तो देखिन्छ ifconfig-push 10.90.0.10 255.255.255.0 सर्भरले त्यो पहिचानका लागि छान्ने फाइलमा। दोस्रो आर्गुमेन्ट net30 अन्तर्गत अर्कै अर्थ दिन्छ, त्यसैले उदाहरण टोपोलोजी-तटस्थ छैन। प्रतिलिपि गर्नुअघि टोपोलोजी पढ्नुहोस्।

पूलको दिगोपनले हालैका लिजहरू रेकर्ड गर्छ र उही ठेगाना फर्काउने प्रवृत्ति राख्छ, जुन सुविधा हो, आरक्षण होइन। दिगोपन फाइललाई स्वामित्वको अभिलेख बन्न नदिनुहोस्, किनभने यो नीतिअनुसार नभई जडान इतिहासअनुसार बदलिन्छ।

बाँडफाँटको प्राथमिकताले कसले जित्छ भनेर निर्धारण गर्छ

म्यानुअलले एउटा क्रम अभिलेख गर्छ: client-connect का क्रममा उत्पन्न स्पष्ट बाँडफाँट client-config-dir प्रविष्टिभन्दा पहिले लागू हुन सक्छ, जुन आफैंमा सामान्य पूल बाँडफाँटभन्दा अघि आउँछ। त्यो क्रमले ‘पिन गरिएको ठेगाना लागू भएन’ भन्ने अधिकांश प्रतिवेदनको व्याख्या गर्छ। यसको अर्थ पनि हुन्छ कि प्रत्येक सत्रका लागि कन्फिगरेसन लेख्ने गतिशील बाँडफाँटकर्ताले तपाईंले आधिकारिक ठान्नुभएको स्थिर फाइल चुपचाप ओभरराइड गर्न सक्छ।

बाँडफाँटको स्वामित्व एउटा तहलाई दिनुहोस् र अरूलाई पढ्न-मात्र बनाउनुहोस्। दुवैले निर्णय गर्ने दाबी गर्ने दुई तहले समय-निर्भर बाँडफाँट बनाउँछन्।

गतिशील बाँडफाँटकर्तालाई पनि त्यही मोडेल चाहिन्छ

प्रत्येक सत्रमा ठेगाना बाँड्ने client-connect एकीकरण सामान्य बाँडफाँटकर्ता समस्याहरू भएको सानो बाँडफाँटकर्ता हो। यसले अनुरोध गर्ने पहिचान प्रमाणित गर्नुपर्छ, ठेगाना आणविक रूपमा आरक्षित गर्नुपर्छ, समर्थित प्रति-जडान आउटपुट मात्र दिनुपर्छ, र विच्छेदन वा असफलतामा आरक्षण छोड्नुपर्छ। एकैसाथ आउने अनुरोधहरूलाई लक वा डेटाबेस अवरोध चाहिन्छ, पढेर-त्यसपछि-लेख्ने क्रम होइन। सफाइ नगरे पूल रिस्टार्टसम्म ठेगाना चुहाउँछ।

बाँडफाँटकर्ताको अवस्था अर्को अपरेटरले पढ्न सक्ने ठाउँमा राख्नुहोस्, र ठेगाना मात्र नभई पहिचान-देखि-ठेगानासम्मको निर्णय लग गर्नुहोस्।

ठेगाना नीति हो कि सुविधा भनेर निर्णय गर्नुहोस्

यदि फायरवाल नियम वा मार्गले एउटा टनेल ठेगानाबाट ट्राफिकलाई अनुमति दिन्छ भने, ठेगाना पहुँच नीतिमा सहभागी हुन्छ र पुनःबाँडफाँटले त्यो अनुमति उत्तराधिकारमा पाउँछ। पहिचान, ठेगाना र फायरवालको जीवनचक्र समन्वय गर्नुहोस्, वा नियमलाई पुनःबाँडफाँट गर्न नसकिने कुरासँग जोड्नुहोस्। स्थिर ठेगाना निर्धारणले कन्फिगरेसन पढ्नयोग्य बनाउँछ; यसले प्रमाणीकरणको ठाउँ लिँदैन।

योजनालाई प्रत्येक प्रविष्टिका लागि मालिकसहितको सूचीका रूपमा लेख्नुहोस्, त्यसपछि यन्त्र सेवानिवृत्त हुँदा यसको समीक्षा गर्नुहोस्। नप्रयोग गरिएको आरक्षण नै गल्तीले पुनः प्रयोग हुने हो।