OpenVPN प्रबंधन सॉकेट: नियंत्रण चैनल, मेट्रिक्स नहीं

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

मान्यता, और उसकी कीमत

मान्यता यह है कि प्रबंधन श्रोता मेट्रिक्स एंडपॉइंट के बराबर है: एक कलेक्टर जोड़िए, काउंटर पढ़िए, आगे बढ़िए। वास्तव में होता यह है कि कलेक्टर नियंत्रण क्षमताओं वाला सत्र खोलता है, और परिनियोजन के बारे में आपकी हर अन्य धारणा अब इस पर निर्भर है कि वह कलेक्टर अच्छा व्यवहार करे।

इंटरफ़ेस में कुछ भी केवल-पढ़ने वाले मोड का प्रचार नहीं करता। चुनने के लिए कोई प्रेक्षक भूमिका नहीं है, और कॉन्फ़िगरेशन में एक उपयोगकर्ता नाम उसे नहीं बनाता।

स्वीकृत क्लाइंट वास्तव में क्या रखता है

समुदाय डेमन एक बार में केवल एक सक्रिय प्रबंधन क्लाइंट स्वीकार करता है। इस एक स्लॉट का अर्थ है कि एक GUI, एक स्क्रिप्ट और एक मॉनिटरिंग एजेंट सभी जुड़ नहीं सकते; पहला सत्र थामे रहता है तब दूसरा प्रतीक्षा करता है या विफल हो जाता है। अगर आपका डिज़ाइन एक साथ कई पाठकों को मानता है, तो वह पहले से ही गलत है।

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

अपना सॉकेट, खुला नहीं

Unix-डोमेन सॉकेट नियंत्रण पथ को नेटवर्क से बाहर रखता है, जिससे बदलता टनल पता समस्या से हट जाता है। यह अनुमति का प्रश्न नहीं हटाता। मूल निर्देशिका सेवा खाते द्वारा लिखने योग्य और नियंत्रक के खाते द्वारा पहुँचने योग्य होनी चाहिए, और ये दो अलग अनुमतियाँ हैं:

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

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

अनुमति त्रुटि दूर करने के लिए सॉकेट को सबके लिए खोल देना वही एक सुधार है जिससे बचना चाहिए। यह स्थानीय नियंत्रण चैनल को ऐसी चीज़ में बदल देता है जिसे होस्ट पर कोई भी प्रक्रिया चला सकती है।

TCP पर उसे प्रकाशित करना वही डिज़ाइन नहीं है

श्रोता को TCP पोर्ट पर ले जाना उसे अधिक सुरक्षित या अधिक सुविधाजनक नहीं बनाता। प्रबंधन पासवर्ड स्पष्ट पाठ में भेजा जाता है, इसलिए TCP श्रोता क्रेडेंशियल और सत्र दोनों को उस किसी भी व्यक्ति के सामने उजागर करता है जो पथ देख सकता है। किसी अन्य होस्ट से उस तक पहुँचने के लिए अधिकृत प्रशासन चैनल, या एक छोटा स्थानीय एजेंट चाहिए जो केवल आपको आवश्यक अवलोकन दे।

स्पष्ट पाठ परिवहन पर पासवर्ड गोपनीयता के बिना प्रमाणीकरण है, और यह संयोजन दिखने से बुरा है क्योंकि यह सुरक्षित महसूस होता है।

वे स्टार्टअप निर्भरताएँ जो आपने नहीं माँगीं

कई प्रबंधन विकल्प डेमन के जीवनचक्र को बदल देते हैं। नियंत्रक के जुड़ने तक स्टार्टअप रोके रखना, या नियंत्रक के गायब होने पर समाप्त करना, एक वैकल्पिक प्रेक्षक को कठोर निर्भरता बना देता है। तब क्रैश होने वाला मॉनिटरिंग एजेंट टनल को भी साथ ले डूबेगा।

सॉकेट के अलावा कुछ भी सक्षम करने से पहले उन विकल्पों की समीक्षा करें। वैकल्पिक अवलोकन वैकल्पिक ही रहना चाहिए, और पुनःआरंभ नीति को ग्राफ़ के लिए जोड़े गए कलेक्टर से जोड़ना नहीं चाहिए।

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

स्वीकृति कैसी दिखती है

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

प्रबंधन इंटरफ़ेस का दस्तावेज़ एकल-क्लाइंट मॉडल और प्रोटोकॉल की विशेषाधिकार प्राप्त प्रकृति का वर्णन करता है, और डैशबोर्ड उसकी ओर इंगित करने से पहले पढ़ने योग्य हिस्सा यही है।