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

दुई उम्मेदवार फरक चीजको मालिक छन्

समर्थित कन्फिगरेसन स्रोत भनेको उपकरणले इनपुटका रूपमा लिने सबै कुरा हो: GUI फिल्ड, आयात गरिएको प्रोफाइल, प्रत्येक क्लाइन्टका लागि कागजात गरिएको डिरेक्टरी, व्यवस्थापन प्याकेजले पढ्ने सेटिङ डेटाबेस। बनाइएको server.conf आउटपुट हो। आउटपुट सम्पादन गर्नु जेनेरेटर फेरि नचलेसम्म काम गर्छ, र त्यो सेभमा, रिबुटमा र अपग्रेडमा हुन्छ।

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

QuestionSupported config sourcePost-generation script
Survives a GUI saveYesOnly if the save does not regenerate the file
Survives a package upgradeUsually, when the field is documentedNo guarantee; the wrapper can be replaced
Supportable by the vendorYesNo
Obvious to the next adminYes, it is in the UINo, it lives in a wrapper

उपकरणले के पुनः सिर्जना गर्छ, र कहिले

व्यवस्थापन प्याकेजहरू सामान्यतया सेटिङ डेटाबेस वा टेम्प्लेट सेटमा राख्छन् र सुरुमा डेमन कन्फिगरेसन बनाउँछन्। वेब UI बाट सेभले प्रायः एउटा लाइन प्याच गर्नुको सट्टा पूरै फाइल पुनः लेख्छ। यदि तपाईंको परिवर्तन त्यो फाइलमा थियो भने, अब गइसक्यो, र कुनै पनि चेतावनी लग गर्दैन, किनकि उपकरणको दृष्टिकोणबाट केही गुमेन।

स्टार्टअप र्यापरहरूमा दोस्रो असफलता मोड छ। निश्चित स्पेसिङ भएको निर्देशनका लागि grep टेम्प्लेट परिवर्तनपछि मिल्न छोड्छ, र स्क्रिप्ट चुपचाप केही गर्दैन। अझ नराम्रो, फर्मवेयर अपडेटले र्यापरलाई नयाँ संस्करणले प्रतिस्थापन गरी प्याच पनि सँगै लैजान सक्छ। त्यसपछि तपाईंसँग एक वर्ष रहेको र कसैले राउटिङसँग जोड्न नसकेको मर्मतका क्रममा हराएको मार्ग हुन्छ।

समर्थित मालिकले के व्यक्त गर्नुपर्छ

शाखा प्रिफिक्सलाई एक होइन, तीन कथन चाहिन्छ। क्लाइन्टले मार्ग सिक्नुपर्छ, सर्भरले कुन प्रमाणित क्लाइन्ट प्रिफिक्सको मालिक छ भन्ने जान्नुपर्छ, र शाखा पक्षले ट्राफिक आफूलाई दिइएको टनेल ठेगानामा फर्काउनुपर्छ। OpenVPN शब्दमा यसको अर्थ पुश गरिएको route, क्लाइन्टसँग बाँधिएको मिल्ने iroute, र अर्को छेउमा फिर्ता मार्ग हो।

यहीँ उपकरण UI ले भ्रममा पार्छन्। “क्लाइन्टहरूलाई सर्भरको LAN मा पहुँच दिनुहोस्” लेबल भएको चेकबक्सले सर्भरको आफ्नै नेटवर्कतर्फको ट्राफिक वर्णन गर्छ। तपाईंको शाखा विपरीत दिशा हो: एउटा क्लाइन्टको पछाडिको नेटवर्क, सर्भर पक्षबाट पुग्न सकिने। उही लेबलले त्यसको समर्थन जनाउँदैन, र फाइलमा रहेको मान्य निर्देशन प्याकेजले त्यसलाई जोगाउने वाचा होइन।

जब कुनै समर्थित नियन्त्रण हुँदैन

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

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

मनसायलाई अडिटयोग्य बनाउनुहोस्

सम्झौता उपकरणबाहिर रेकर्ड गर्नुहोस्: प्रभावकारी क्लाइन्ट पहिचान, प्रिफिक्स, फिर्ता गेटवे, र प्रत्येकलाई आपूर्ति गर्ने समर्थित फिल्ड। समर्थित संयन्त्रमार्फत कन्फिगरेसन निर्यात गर्नुहोस् ताकि पुनर्निर्माणसँग सन्दर्भ होस्, र पुनः जडान, रिस्टार्ट र अपग्रेडपछि सेवा प्रमाणित गर्नुहोस्, परिवर्तनपछि मात्र होइन।

केही बिग्रँदा व्याख्या नगरिएको लाइन पुनर्स्थापित गरेर आशा राख्नुको सट्टा, बनेको नतिजाको त्यो रेकर्डसँग तुलना गर्नुहोस्।OpenVPN 2.6 सन्दर्भ UI सँग बहस गर्नुअघि route र iroute कसरी अन्तरक्रिया गर्छन् भनी पुष्टि गर्ने ठाउँ हो।

अर्को परिवर्तनका लागि चेकलिस्ट: मालिकको नाम भन्नुहोस्, तीन-भाग सम्झौता बताउनुहोस्, मनसाय निर्यात गर्नुहोस्, र तपाईंको सम्पादनपछि होइन, उपकरणको आफ्नै जीवनचक्र घटनापछि फेरि परीक्षण गर्नुहोस्।

सम्बन्धित लेखहरू