OpenVPN उपकरणाचा मार्ग: कॉन्फिग मालक की स्टार्टअप स्क्रिप्ट?

तुम्ही शाखा मार्ग जोडता, तो काम करतो, आणि नंतर फर्मवेअर अपडेट किंवा वेब UI मधून सेव्ह तो काढून टाकतो। त्या क्षणी दोन दुरुस्त्या तितक्याच योग्य वाटतात: मार्ग उपकरणाच्या समर्थित कॉन्फिगरेशन स्रोतात ठेवणे, किंवा स्टार्टअप स्क्रिप्टमधून तयार झालेल्या फाइलमध्ये तो जोडणे। ते आठवडाभर सारखेच वागतात आणि दुसऱ्या अपग्रेडला वेगळे होतात। हा लेख प्रत्येकजण प्रत्यक्षात काय मालकी ठेवतो याची तुलना करतो।

दोन उमेदवार वेगवेगळ्या गोष्टींचे मालक आहेत

समर्थित कॉन्फिगरेशन स्रोत म्हणजे उपकरण इनपुट म्हणून वापरत असलेली प्रत्येक गोष्ट: GUI फील्ड, आयात केलेली प्रोफाइल, प्रत्येक क्लायंटसाठी दस्तऐवजीकृत डिरेक्टरी, व्यवस्थापन पॅकेज वाचत असलेला सेटिंग्ज डेटाबेस। तयार केलेली server.conf ही आउटपुट आहे। आउटपुट संपादित करणे जनरेटर पुन्हा चालण्यापर्यंत काम करते, आणि ते सेव्हवर, रीबूटवर आणि अपग्रेडवर होते।

स्क्रिप्ट पद्धत जनरेटर संपल्यानंतर त्या आउटपुटवर पॅच करते। ही प्रयोगशाळेसाठी वैध तंत्र आहे, आणि शाखा कार्यालयासाठी हे चुकीचे डीफॉल्ट आहे, कारण ते मार्गाला दस्तऐवजीकृत फील्डऐवजी मजकूर जुळणीवर अवलंबून करते।

उपकरण काय पुन्हा तयार करते, आणि कधी

व्यवस्थापन पॅकेजेस सहसा सेटिंग्ज डेटाबेसमध्ये किंवा टेम्पलेट संचात ठेवतात आणि सुरुवातीला डेमॉन कॉन्फिगरेशन तयार करतात। वेब UI मधून सेव्ह अनेकदा एक ओळ पॅच करण्याऐवजी संपली फाइल पुन्हा लिहितो। तुमचा बदल त्या फाइलमध्ये होता, तर तो आता गेला आहे, आणि काहीही इशारा नोंदवत नाही, कारण उपकरणाच्या दृष्टिकोनातून काहीही गमावले नाही।

स्टार्टअप रॅपरना दुसरा अपयश मोड आहे। विशिष्ट अंतराच्या सूचनेसाठी grep टेम्पलेट बदलल्यानंतर जुळणे थांबवते, आणि स्क्रिप्ट गुपचूप काहीही करत नाही। त्याहून वाईट, फर्मवेअर अपडेट रॅपरला नव्या आवृत्तीने बदलू शकतो आणि पॅच सोबत घेऊन जाऊ शकतो। मग तुमच्याकडे एक वर्ष असलेला आणि कोणीही राउटिंगशी जोडले नाही अशा देखभालीदरम्यान नाहीसा झालेला मार्ग असतो।

समर्थित मालकाने काय व्यक्त करावे

शाखा प्रीफिक्सला एक नाही, तीन विधाने लागतात। क्लायंटने मार्ग शिकला पाहिजे, सर्व्हरला कोणता प्रमाणित क्लायंट प्रीफिक्सचा मालक आहे हे माहीत असले पाहिजे, आणि शाखेच्या बाजूने रहदारी तिला दिलेल्या टनेल पत्त्यावर परत पाठवली पाहिजे। OpenVPN अटींमध्ये याचा अर्थ पुश केलेला route, क्लायंटशी बांधलेला जुळणारा iroute, आणि पलीकडे परतीचा मार्ग।

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

जेव्हा कोणतेही समर्थित नियंत्रण नसते

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

नेटवर्कचा वारसा घेणाऱ्याला एका वाक्यात वर्णन करता येईल असा पर्याय निवडा। उत्तरासाठी स्क्रिप्ट पथ आणि मजकूर नमुना नमूद करावा लागत असेल, तर रचना आधीच ठिसूळ आहे।

हेतू ऑडिटयोग्य करा

करार उपकरणाबाहेर नोंदवा: प्रभावी क्लायंट ओळख, प्रीफिक्स, परतीचे गेटवे, आणि प्रत्येक पुरवणारे समर्थित फील्ड। समर्थित यंत्रणेद्वारे कॉन्फिगरेशन निर्यात करा जेणेकरून पुनर्बांधणीला संदर्भ असेल, आणि पुन्हा जोडणी, रीस्टार्ट आणि अपग्रेडनंतर सेवा पडताळा, केवळ बदलानंतर नाही।

काही तुटल्यावर स्पष्टीकरण नसलेली ओळ पुनर्संचयित करून आशा धरण्याऐवजी, तयार झालेल्या निकालाची त्या नोंदीशी तुलना करा।OpenVPN 2.6 संदर्भ ही UI शी वाद घालण्यापूर्वी route आणि iroute कसे परस्पर क्रिया करतात हे पुष्टी करण्याची जागा आहे।

पुढील बदलासाठी चेकलिस्ट: मालकाचे नाव द्या, तीन-भाग करार सांगा, हेतू निर्यात करा, आणि तुमच्या संपादनानंतर नाही, उपकरणाच्या स्वतःच्या जीवनचक्र घटनांनंतर पुन्हा चाचणी करा।