केवल एक प्रबंधन क्लाइंट: आपका मॉनिटर GUI को क्यों बाहर कर देता है
प्रबंधन सॉकेट एक समय में एक ही कनेक्शन लेता है। दूसरा सब्सक्राइबर या तो जुड़ नहीं पाता या प्रॉम्प्ट रखने वाले घटक से नियंत्रण छीन लेता है।
एक डेस्कटॉप GUI प्रबंधन कनेक्शन रखता है, इसलिए एक मॉनिटरिंग स्क्रिप्ट अपना कनेक्शन खोलने की कोशिश करता है और कुछ नहीं पढ़ता, या उससे भी बुरा, GUI प्रॉम्प्ट का जवाब देना बंद कर देता है। सामान्य निष्कर्ष यह निकलता है कि डेमन अस्थिर है। कम्युनिटी डेमन में यह सीमा जानबूझकर है: नियंत्रण इंटरफ़ेस एक समय में एक ही जुड़े प्रबंधन क्लाइंट की सेवा करता है, और इस संख्या का इससे कोई संबंध नहीं है कि VPN कितने उपयोगकर्ता उठा सकता है।
एक सॉकेट, एक धारक
प्रबंधन चैनल एक ही जुड़ा क्लाइंट स्वीकार करता है। जब पहला सक्रिय हो और दूसरा आता है, तो वह प्रतीक्षा करता है या अस्वीकार कर दिया जाता है, और किसी विकल्प के पीछे कोई समानांतर सब्सक्राइबर मोड छिपा नहीं है। वर्तमान धारक का कनेक्शन हटाने पर डेमन अगले को स्वीकार कर लेता है, और यह दूसरा चैनल नहीं बल्कि एक हैंडओवर है।
इससे हर अतिरिक्त उपकरण एक प्रतिद्वंद्वी बन जाता है। अगर GUI के पास कनेक्शन है, तो पोलिंग स्क्रिप्ट या तो जुड़ नहीं पाती या केवल तब सफल होती है जब GUI हार मान चुका होता है, और यह क्रम अगले पुनः कनेक्शन पर दोहराया जाता है। अगर स्क्रिप्ट पहले जुड़ जाती है, तो GUI अपना नियंत्रण मार्ग खो देता है और उसके प्रॉम्प्ट काम करना बंद कर देते हैं। कोई भी उपकरण इस टकराव की सूचना नहीं देता, क्योंकि हर एक केवल अपना विफल कमांड देखता है।
| What you need | Mechanism that fits | What it cannot do |
|---|---|---|
| Periodic list of connected clients | Status file written on an interval | Deliver events as they happen |
| Interactive prompts and session control | The single management connection | Serve two controllers at once |
| Multiple consumers of either | One owner process that fans out | Exist without you writing it |
तय करें कि नियंत्रण का मालिक कौन सा घटक है
इंटरैक्टिव चैनल के लिए एक मालिक चुनें और उसे ही जुड़ने वाली एकमात्र चीज़ बनने दें। कनेक्शन प्रबंधित करने वाला GUI, प्रमाणीकरण प्रॉम्प्ट का उत्तर देने वाली स्क्रिप्ट और सत्र समाप्त करने वाला नियंत्रक, सभी मालिक गिने जाते हैं, और केवल एक ही यह भूमिका निभा सकता है।
जब GUI कनेक्शन का मालिक हो, तो उस इंटीग्रेशन का उपयोग करें जो वह GUI देता है, उससे लड़ने के बजाय। सॉकेट के लिए मालिक से होड़ करने पर रुक-रुक कर विफलताएँ होती हैं जो उपयोगकर्ताओं को बेतरतीब लगती हैं, और डिबग करने वाला व्यक्ति सामान्यतः दौड़ का केवल दूसरा आधा हिस्सा देखता है। ध्यान दें कि रीबूट के बाद कौन सी प्रक्रिया पहले जुड़ती है, क्योंकि यही क्रम हर बार तय करता है कि कौन जीतेगा। GUI से पहले शुरू होने वाला मॉनिटर चैनल तब तक बनाए रखेगा जब तक GUI हार न मान ले।
कलेक्टरों के लिए स्थिति स्नैपशॉट का उपयोग करें
अधिकांश मॉनिटरिंग को सूची चाहिए, बातचीत नहीं। एक आवधिक स्थिति फ़ाइल नियंत्रण चैनल को छुए बिना इसका उत्तर देती है, और GUI के जुड़े रहने के दौरान भी काम करती रहती है।
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unix
अंतराल ताज़गी का बजट है, इसलिए इसे वही रखें जो डैशबोर्ड को वास्तव में चाहिए, न कि वह सबसे छोटा मान जो सुरक्षित लगे। हर कुछ सेकंड में लिखा गया स्नैपशॉट सस्ता है; हर कुछ सेकंड में नियंत्रण सॉकेट से दोबारा जुड़ने वाली स्क्रिप्ट सस्ती नहीं है, क्योंकि हर पुनः कनेक्शन मालिक से होड़ करता है।
स्नैपशॉट न इतिहास है और न घटना फ़ीड। जो कनेक्शन एक अंतराल के भीतर आकर चले जाते हैं वे कभी दिखाई नहीं देते, इसलिए ऑडिट की आवश्यकता ऐसी फ़ाइल को पोल करके पूरी नहीं की जा सकती जो खुद को फिर से लिखती है। अगर आपको यह जानना है कि उपयोगकर्ता जुड़ा भी था या नहीं, तो स्नैपशॉट गलत उपकरण है।
फैन-आउट एक डिज़ाइन है, मोड नहीं
अगर कई उपभोक्ताओं को वास्तव में लाइव प्रबंधन डेटा चाहिए, तो सॉकेट के सामने एक भरोसेमंद घटक रखें और उसे बाकी के लिए सावधानी से चुने गए अवलोकन प्रकाशित करने दें। वही घटक पुनः कनेक्शन, प्रमाणीकरण प्रॉम्प्ट और इस निर्णय का मालिक है कि क्या उजागर करना सुरक्षित है।
इसे सोच-समझकर बनाएँ: तय करें कि कौन सी क्वेरी की अनुमति है, दर्ज करें कि किसने पूछा, और फैन-आउट परत को अनजाने में रिमोट कंट्रोल पैनल में बदलने से बचें। डेमन में सक्षम करने के लिए कोई मल्टी-क्लाइंट मोड नहीं है, और कोई कॉन्फ़िगरेशन पंक्ति ऐसा मोड नहीं बनाती। मालिक को सुरक्षा सीमा का हिस्सा मानें, क्योंकि उसके पास ऐसा इंटरफ़ेस है जो लोगों को डिस्कनेक्ट कर सकता है। इसे पुनः आरंभ करना प्रलेखित रिकवरी पथ वाला एक नियमित कार्य होना चाहिए।
सॉकेट को विशेषाधिकार मानें, मेट्रिक्स नहीं
प्रबंधन इंटरफ़ेस उपयोगकर्ताओं को डिस्कनेक्ट कर सकता है, स्थिति बदल सकता है और ऐसी घटनाएँ पढ़ सकता है जिनमें लोगों के नाम हों। इसका पासवर्ड क्लाइंट को प्रमाणित करता है और परिवहन को एन्क्रिप्ट नहीं करता, इसलिए नेटवर्क पर एक श्रोता बातचीत को हर उस व्यक्ति के सामने उजागर कर देता है जो उसे देख सकता है।
स्थानीय सॉकेट या कड़ाई से सीमित श्रोता को प्राथमिकता दें, और जाँचें कि आपका कलेक्टर वास्तव में किस प्रक्रिया को संबोधित कर रहा है, क्योंकि सर्वर उत्पाद अपने स्वयं के प्रबंधन API के साथ आते हैं जो अलग व्यवहार करते हैं। गलत डेमन पर इंगित कलेक्टर आत्मविश्वासी और गलत निष्कर्ष उत्पन्न करता है। ऐसी क्वेरी को डिबग करने से पहले पथ और स्वामी प्रक्रिया की पुष्टि करें जो कुछ भी वापस नहीं करती।