काम स्पष्ट आहे: लॅपटॉप जोडला गेल्यावर लॅपटॉपवर काहीतरी बदलले पाहिजे. जे कॉन्फिगरेशन संपादित केले जात आहे ते सर्व्हरचे आहे, आणि तिथेच ही गृहीतक फुटते. सर्व्हर फाइलमधील पाथ त्या सर्व्हरवरील फाइल दर्शवतो, आणि कितीही push केले तरी कोणती प्रक्रिया तो चालवते हे बदलत नाही. दोन हुकांपैकी एक निवडणे म्हणजे मुख्यतः काम कोणत्या मशीनचे आहे हे ठरवणे आणि त्यातून येणाऱ्या मर्यादा स्वीकारणे.

दोन मशीन, आधी उत्तर देण्याचे दोन प्रश्न

स्थिती बदल कुठे व्हायला हवा असे विचारा, मग त्या बदलाशी कोणती घटना जुळते असे विचारा. बदल प्रति-वापरकर्ता अधिकृतता किंवा प्रति-क्लायंट कॉन्फिगरेशन निर्णय असेल, तर तो तिथे जातो जिथे वापरकर्ता डिरेक्टरी ज्ञात आहे: सर्व्हरवर. बदल मार्ग असेल, resolver सेटिंग किंवा एंडपॉइंटवरील स्थानिक सहाय्यक असेल, तर तो एंडपॉइंटवर जातो, आणि फक्त एंडपॉइंटच तो करू शकतो.

या दोन प्रश्नांची उलट क्रमाने उत्तरे देताच लोक Windows लॅपटॉपवर बॅच फाइल push करण्याचा प्रयत्न करतात. सर्व्हरला माहीत असते कोण जोडले गेले; लॅपटॉपला माहीत असते त्याचा स्वतःचा नेटवर्क स्टॅक कसा दिसतो. दोघांपैकी कोणाकडेही दुसऱ्याची माहिती नसते, आणि प्रयत्न सहसा स्पष्ट त्रुटीऐवजी शांतपणे अयशस्वी होतो.

दोन्हींपूर्वी तिसरा प्रश्न विचारण्यासारखा आहे: प्लॅटफॉर्म तुम्हाला हवा असलेला हुक अजिबात देतो का? स्वतःचे कॉन्फिगरेशन तयार करणारे उपकरण तीच घटना नावे देत नसेल, आणि .ovpn फाइल आयात करणारा डेस्कटॉप क्लायंट ती फाइल ज्या क्लायंटसाठी लिहिली गेली तोच असेल असे नाही. प्लॅटफॉर्म आधी निश्चित केल्यास तिथे नसलेल्या हुकभोवती रचना करणे टळते. तुमच्यासमोरच्या मशीनला कोणते दस्तऐवज खरंच लागू होते हेही ते सांगते.

सर्व्हरच्या बाजूचा पर्याय: प्रत्येक कनेक्शनसाठी एक घटना

client-connect स्क्रिप्ट प्रमाणित क्लायंट जोडला जातो तेव्हा सर्व्हरच्या प्रक्रिया संदर्भात चालते, आणि common name व नियुक्त केलेला पत्ता यांसारखे दस्तऐवजीकृत कनेक्शन तपशील घेते. प्रति-क्लायंट कॉन्फिगरेशन तुकडा लिहिणे, धोरण निर्णय लागू करणे किंवा सर्व्हरच्या मालकीची स्थिती नोंदवणे यासाठी ही योग्य जागा आहे.

लोक जो फरक चुकवतात तो म्हणजे या हुक आणि सर्व्हरच्या up हुकमधील फरक. सर्व्हरने त्याचे टनेल उपकरण उघडल्यावर up हुक सक्रिय होतो, जे अनेक क्लायंट असलेल्या सर्व्हरवर डेमन सुरू होताना एकदाच घडते. ही प्रति-लॉगिन घटना नाही, आणि तिथे ठेवलेला कोड वापरकर्ते जोडले जातात तेव्हा नाही तर सेवा सुरू होते तेव्हा चालतो.

वेब इंटरफेस असलेल्या उपकरणावर, तयार झालेल्या डेमन फाइल्स संपादित करण्याऐवजी समर्थित विस्तार यंत्रणा वापरा. तयार झालेल्या फाइल्स पुढील जतन करताना पुन्हा लिहिल्या जातात, आणि ते पुनर्लेखन तुमचा बदल सर्वात वाईट क्षणी शांतपणे काढून टाकते. विस्तार मजकुराची प्रत उपकरणाबाहेर ठेवा, जेणेकरून फर्मवेअर अद्ययावत करताना हेतूही हरवणार नाही.

क्लायंटच्या बाजूचा पर्याय: स्थानिक पातळीवर चालणारे काम

समुदाय क्लायंट टनेल उपकरण वर आल्यावर आणि पुन्हा मार्ग स्थापित झाल्यावर स्थानिक स्क्रिप्ट चालवू शकतो. हे दोन वेगळे क्षण आहेत, आणि चुकीचा निवडल्यास सहाय्यक ज्या मार्गावर अवलंबून आहे तो अस्तित्वात येण्यापूर्वीच सुरू होतो अशी पारंपरिक शर्यत तयार होते.

सहाय्यक त्या क्लायंटवर असणे आवश्यक आहे, क्लायंट चालवणाऱ्या खात्यासाठी वाचनीय आणि चालवण्यायोग्य असणे आवश्यक आहे, आणि स्पष्ट script-security सेटिंगने परवानगी दिलेली असणे आवश्यक आहे. प्रशासक म्हणून क्लायंट सुरू करता तेव्हा चालणारी स्क्रिप्ट लॉगिनपूर्व सेवा किंवा दुसऱ्या वापरकर्त्याच्या सत्राबद्दल काहीही सांगत नाही.

नावेही महत्त्वाची आहेत. up हुक उपकरण तयार होण्याशी जुळतो आणि route-up मार्ग स्थापित होण्याशी, पण खाजगी नेटवर्कपर्यंत पोहोचता आले पाहिजे अशा कामाने उपकरण तयार होणे म्हणजे प्रत्येक मार्ग, resolver नोंद आणि अनुप्रयोग तयार आहे असे गृहीत धरण्याऐवजी पोहोचक्षमता तपासली पाहिजे.

कार्यान्वित कोड push करणे पर्यायांमध्ये का नाही

push केलेले पर्याय हेतुपुरस्सर मर्यादित आहेत, आणि स्क्रिप्ट चालवणारे पर्याय सर्व्हरला देऊ नयेत अशा श्रेणींमध्ये येतात. ही मर्यादा आहे कारण पर्यायाने तडजोड झालेला किंवा चुकीच्या पद्धतीने कॉन्फिगर केलेला सर्व्हर कधीही जोडला जाणाऱ्या प्रत्येक क्लायंटवर अनियंत्रित आदेश चालवू शकला असता.

स्थानिक पातळीवर स्क्रिप्ट चालवणे सक्षम केल्याने ते बदलत नाही. तुमची script-security सेटिंग तुम्ही निवडलेल्या स्थानिक स्क्रिप्टना परवानगी देते; ती सर्व्हरला नवीन पुरवण्याचा अधिकार देत नाही.

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

दोन्हींपैकी कोणत्याही हुकवर विश्वास ठेवण्यापूर्वी काय तपासावे

प्रत्येक हुकासाठी चार गोष्टी लिहा: मशीन, घटनेचे नाव, तो कोणत्या खात्याखाली चालतो, आणि त्याने निर्माण करायचा स्थिती बदल. मग कनेक्शन, पुनःकनेक्शन आणि स्वच्छतेचा मार्ग तपासा, कारण पुनःकनेक्शनवर स्थिती गळणारा हुक कधीही न चाललेल्या हुकापेक्षा वाईट आहे.

खरोखर तो चालवणाऱ्या खात्याखाली, खरोखर चालणाऱ्या क्षणी तपासा. openvpn(8) मॅन्युअल दोन्ही हुक कुटुंबे आणि push मर्यादा दस्तऐवजीकृत करते; तुम्ही तैनात करत असलेला प्लॅटफॉर्म त्या अजिबात उपलब्ध करतो का हे दस्तऐवजीकृत करतो. परस्परसंवादी प्रशासक टर्मिनलमध्ये यशस्वी होणारी स्क्रिप्ट हे गृहीतक आहे, पडताळणी नाही.

संबंधित लेख