काम स्पष्ट छ: ल्यापटप जोडिँदा ल्यापटपमै केही बदलिनुपर्छ। सम्पादन गरिँदै गरेको कन्फिगरेसन सर्भरको हो, र यहीँ अनुमान भाँचिन्छ। सर्भर फाइलमा भएको पाथले त्यही सर्भरको फाइल जनाउँछ, र जतिसुकै 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 सीमा अभिलेख गर्छ; तपाईंले तैनाथ गर्ने प्लेटफर्मले ती बिल्कुलै दिन्छ कि भन्ने अभिलेख गर्छ। अन्तरक्रियात्मक प्रशासक टर्मिनलमा सफल हुने स्क्रिप्ट अनुमान हो, प्रमाणीकरण होइन।

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