OpenVPN क्लाइंट को फिर से जोड़ना: तीन नियंत्रण, तीन दायरे

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

यह पूछने से पहले कि कौन-सा नियंत्रण उपयोग करें, पूछें कि किसे प्रभावित होना चाहिए।

एक इंस्टेंस: प्रबंधन इंटरफ़ेस

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

यह नए कनेक्शन की गारंटी नहीं देता। क्लाइंट लौटेगा या नहीं, यह उसकी पुनः प्रयास सेटिंग्स, बची हुई रिमोट प्रविष्टियों, उसकी प्रमाणीकरण आवश्यकताओं और इस पर निर्भर है कि निगरानी करने वाला एप्लिकेशन अभी भी चल रहा है या नहीं। लौटने वाले क्लाइंट को नया पहचानकर्ता मिलता है, इसलिए पहचानकर्ताओं की तुलना ही पुराने और नए में अंतर करने का एकमात्र भरोसेमंद तरीका है।

UDP निकास सूचना प्रति-क्लाइंट आदेश नहीं है

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

इसमें कुछ भी किसी भी क्षण किसी मनमाने क्लाइंट को नहीं चुनता। इसे फिर से जोड़ने का बटन मानना एक साथ हर जुड़े सत्र तक पहुँच जाता है।

संकेत प्रक्रिया पर काम करते हैं, सत्र पर नहीं

SIGUSR1 चल रही प्रक्रिया से कॉन्फ़िगरेशन दोबारा पढ़े बिना अपना कनेक्शन फिर से शुरू करने को कहता है, और स्थायित्व विकल्प तय करते हैं कि उस पुनः आरंभ से क्या बचेगा। SIGHUP आगे जाता है: यह कॉन्फ़िगरेशन फ़ाइल दोबारा पढ़ता है और अपने संसाधन फिर से खोलता है। SIGTERM और SIGINT व्यवस्थित बंद का अनुरोध करते हैं। ये प्रक्रिया-स्तर के कार्य हैं: बहु-क्लाइंट सर्वर पर ये प्रक्रिया द्वारा वहन किए गए हर सत्र को प्रभावित करते हैं, टिकट में नामित सत्र को नहीं।

जब प्रक्रिया किसी सेवा प्रबंधक के अधीन चलती है, तो प्रक्रिया सूची में मिले PID को संकेत भेजने के बजाय प्रबंधक के अपने नियंत्रण का उपयोग करें। यूनिट पढ़ें ताकि देख सकें कि प्रबंधक कौन-सा संकेत भेजता है, क्योंकि पुनः आरंभ और पुनः लोड एक ही डेमन के साथ अलग-अलग काम करते हैं।

नियंत्रण चुनने से पहले दायरा तय करें

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

फिर से जोड़ने का बटन पाने के लिए बिना प्रमाणीकरण वाला नियंत्रण श्रोता जोड़ना पोर्ट तक पहुँच सकने वाले हर व्यक्ति को उस बटन से कहीं अधिक सौंप देता है।

नए सत्र को सत्यापित करें, डिस्कनेक्ट को नहीं

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

परिवर्तन रिकॉर्ड में दायरा लिखें। 'मैंने क्लाइंट फिर से जोड़ा' कोई विवरण नहीं है जब क्लाइंट साझा सर्वर पर चालीस में से एक था।