OpenVPN क्लाइन्ट पुनः जोड्ने: तीन नियन्त्रण, तीन दायरा

कसैले VPN क्लाइन्ट पुनः जोड्न भन्छ, र यो अनुरोधले तीन फरक कुरा बुझाउन सक्छ। यसले एउटा प्रमाणित सत्र छोड्नु, हरेक क्लाइन्टलाई UDP सर्भर जाँदै छ भनी जानकारी दिनु, वा डेमन आफैलाई पुनः सुरु गर्नु बुझाउन सक्छ। प्रत्येकको प्रभाव दायरा फरक हुन्छ, र गलत छनोटले एक प्रयोगकर्ताका लागि गरिएको सुधारलाई पूरै सेवा अवरुद्धमा बदल्छ। दायरा नै निर्णय हो, र आदेश त्यसैबाट आउँछ।

कुन नियन्त्रण प्रयोग गर्ने भनी सोध्नुअघि कसलाई असर पर्नुपर्ने हो भनी सोध्नुहोस्।

एउटा इन्स्टेन्स: व्यवस्थापन इन्टरफेस

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

यसले नयाँ जडानको ग्यारेन्टी दिँदैन। क्लाइन्ट फर्किने हो कि होइन भन्ने उसको पुनः प्रयास सेटिङ, बाँकी रहेका टाढाका प्रविष्टि, प्रमाणीकरण आवश्यकता र निरीक्षण गर्ने अनुप्रयोग अझै चलिरहेको छ कि छैन भन्नेमा निर्भर हुन्छ। फर्केको क्लाइन्टले नयाँ पहिचानकर्ता पाउँछ, त्यसैले पहिचानकर्ता तुलना गर्नु नै पुरानो र नयाँ छुट्याउने एकमात्र भरपर्दो उपाय हो।

UDP निर्गमन सूचना प्रति-क्लाइन्ट आदेश होइन

explicit-exit-notify निर्गमन र पुनः सुरु हुने घटनाहरूबारेको कन्फिगरेसन निर्देश हो। UDP क्लाइन्टमा यसले अर्को पक्षलाई सत्र सकिँदै छ भनी बताउँछ, र सङ्ख्यात्मक आर्गुमेन्टले सूचना कतिपटक दोहोरिने नियन्त्रण गर्छ। सर्भर UDP मा चल्दा यसले जोडिएका क्लाइन्टहरूलाई पुनः सुरु गर्ने नियन्त्रण सन्देश पठाउँछ, र अभिलेखित मानहरूले एउटै सर्भरमा पुनः जोडिने र अर्को टाढाको प्रविष्टिमा सर्नेबीच फरक पार्छन्। यो फराकिलो श्रोतावर्ग भएको जीवनचक्र सङ्केत हो।

यसमा केहीले पनि कुनै क्षणमा कुनै मनपरी क्लाइन्ट छान्दैन। यसलाई पुनः जोड्ने बटन मान्दा एकैपटक सबै जोडिएका सत्रमा पुगिन्छ।

सङ्केतहरू सत्रमा होइन, प्रक्रियामा काम गर्छन्

SIGUSR1 चलिरहेको प्रक्रियालाई कन्फिगरेसन नपढी आफ्नो जडान पुनः सुरु गर्न भन्छ, र स्थायित्वका विकल्पहरूले त्यो पुनः सुरुबाट के बाँच्ने भनी निर्धारण गर्छन्। SIGHUP अझ अगाडि जान्छ: यसले कन्फिगरेसन फाइल पुनः पढ्छ र आफ्ना स्रोतहरू पुनः खोल्छ। SIGTERM र SIGINT व्यवस्थित बन्दको अनुरोध गर्छन्। यी प्रक्रिया-स्तरका कार्य हुन्: बहु-क्लाइन्ट सर्भरमा यी प्रक्रियाले बोकेका हरेक सत्रमा असर गर्छन्, टिकटमा उल्लेख गरिएको सत्रमा होइन।

प्रक्रिया सेवा व्यवस्थापकअन्तर्गत चल्दा प्रक्रिया सूचीमा भेटिएको PID मा सङ्केत पठाउनुको सट्टा व्यवस्थापककै नियन्त्रण प्रयोग गर्नुहोस्। व्यवस्थापकले कुन सङ्केत पठाउँछ हेर्न युनिट पढ्नुहोस्, किनकि पुनः सुरु गर्नु र पुनः लोड गर्नुले एउटै डेमनमा फरक काम गर्छन्।

नियन्त्रण छान्नुअघि दायरा तय गर्नुहोस्

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

पुनः जोड्ने बटन पाउन प्रमाणीकरणविना नियन्त्रण श्रोता थप्नुले पोर्टसम्म पुग्न सक्ने जो कोहीलाई त्यो बटनभन्दा धेरै बढी दिन्छ।

नयाँ सत्र जाँच्नुहोस्, विच्छेद होइन

विच्छेद घटनाले पुरानो सत्र सकिएको प्रमाणित गर्छ। नयाँ सत्र प्रमाणित हुँदै, ठेगाना पाउँदै, मार्ग स्थापना गर्दै वा प्रयोगकर्तालाई आवश्यक परेको स्रोतमा पुग्दै छ भन्नेबारे यसले केही भन्दैन। नयाँ पहिचानकर्ता जाँच्नुहोस्, त्यसपछि टनेलको अवस्था, त्यसपछि एउटा वास्तविक स्रोत। ती तीन चरण नै पुनः जोडिने र काम गर्ने जडानबीचको फरक हुन्।

परिवर्तन अभिलेखमा दायरा लेख्नुहोस्। 'मैले क्लाइन्ट पुनः जोडेँ' भन्ने विवरण होइन जब क्लाइन्ट साझा सर्भरमा चालीसमध्ये एक थियो।