आप एक शाखा मार्ग जोड़ते हैं, वह काम करता है, और फिर फ़र्मवेयर अपडेट या वेब 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 के परस्पर व्यवहार की पुष्टि करें।

अगले बदलाव के लिए चेकलिस्ट: मालिक का नाम दें, तीन-भाग वाला अनुबंध बताएँ, इरादा निर्यात करें, और अपने संपादन के बाद नहीं, उपकरण के अपने जीवनचक्र की घटनाओं के बाद फिर से परीक्षण करें।

संबंधित लेख