डेस्कटॉप GUI व्यवस्थापन कनेक्शन धरून ठेवते, म्हणून मॉनिटरिंग स्क्रिप्ट स्वतःचे कनेक्शन उघडण्याचा प्रयत्न करते आणि काहीच वाचत नाही, किंवा त्याहून वाईट म्हणजे GUI प्रॉम्प्टना उत्तर देणे थांबवते। नेहमीचा निष्कर्ष असा असतो की डेमन अस्थिर आहे। समुदाय डेमनमध्ये ही मर्यादा हेतुपुरस्सर आहे: नियंत्रण इंटरफेस एका वेळी एकाच जोडलेल्या व्यवस्थापन क्लायंटची सेवा करतो, आणि या संख्येचा VPN किती वापरकर्ते वाहू शकतो याच्याशी काहीही संबंध नाही।

एक सॉकेट, एक धारक

व्यवस्थापन चॅनेल एकच जोडलेला क्लायंट स्वीकारते। पहिला सक्रिय असताना दुसरा आला, तर तो प्रतीक्षा करतो किंवा नाकारला जातो, आणि कोणत्याही पर्यायामागे समांतर सदस्यता मोड लपलेला नाही। सध्याचा धारक डिस्कनेक्ट केल्यास डेमन पुढील क्लायंट स्वीकारतो, आणि हे दुसरे चॅनेल नसून हस्तांतरण आहे।

यामुळे प्रत्येक अतिरिक्त साधन स्पर्धक बनते। जर GUI कडे कनेक्शन असेल, तर पोलिंग स्क्रिप्ट एकतर जोडली जात नाही किंवा GUI हार मानल्यावरच यशस्वी होते, आणि पुढील पुन्हा कनेक्शनला हा क्रम पुन्हा होतो। जर स्क्रिप्ट आधी जोडली गेली, तर GUI आपला नियंत्रण मार्ग गमावते आणि त्याचे प्रॉम्प्ट काम करणे थांबवतात। दोन्हीपैकी कोणतेही साधन संघर्षाची नोंद देत नाही, कारण प्रत्येकाला फक्त स्वतःची अयशस्वी आज्ञा दिसते।

What you needMechanism that fitsWhat it cannot do
Periodic list of connected clientsStatus file written on an intervalDeliver events as they happen
Interactive prompts and session controlThe single management connectionServe two controllers at once
Multiple consumers of eitherOne owner process that fans outExist without you writing it

नियंत्रणाचा मालक कोणता घटक आहे हे ठरवा

परस्परसंवादी चॅनेलसाठी एक मालक निवडा आणि तोच जोडला जाणारा एकमेव घटक असू द्या। कनेक्शन व्यवस्थापित करणारा GUI, प्रमाणीकरण प्रॉम्प्टना उत्तर देणारी स्क्रिप्ट आणि सत्र संपवणारा नियंत्रक हे सर्व मालक मानले जातात, आणि ही भूमिका एकच घेऊ शकतो।

जेव्हा GUI कनेक्शनचा मालक असतो, तेव्हा त्याच्याशी भांडण्याऐवजी तो GUI देत असलेले एकीकरण वापरा। सॉकेटसाठी मालकाशी स्पर्धा केल्यास अधूनमधून अशा अयशस्वी घटना घडतात ज्या वापरकर्त्यांना अनियमित वाटतात, आणि दोष शोधणारी व्यक्ती सहसा शर्यतीचा फक्त दुसरा अर्धा भाग पाहते। रीबूटनंतर कोणती प्रक्रिया आधी जोडते हे लक्षात ठेवा, कारण तोच क्रम प्रत्येक वेळी कोण जिंकेल हे ठरवतो। GUI च्या आधी सुरू होणारा मॉनिटर GUI हार मानेपर्यंत चॅनेल धरून ठेवेल।

संकलकांसाठी स्थिती स्नॅपशॉट वापरा

बहुतेक मॉनिटरिंगला यादी हवी असते, संवाद नाही। नियमितपणे लिहिली जाणारी स्थिती फाइल नियंत्रण चॅनेलला स्पर्श न करता हे उत्तर देते, आणि GUI जोडलेले असतानाही ती काम करत राहते।

status /run/openvpn/server.status 10
management /run/openvpn/server.sock unix

मध्यांतर हे ताजेपणाचे बजेट आहे, म्हणून ते डॅशबोर्डला प्रत्यक्षात हवे तेच ठेवा, सुरक्षित वाटणाऱ्या सर्वात लहान मूल्यावर नाही। दर काही सेकंदाला लिहिला जाणारा स्नॅपशॉट स्वस्त आहे; दर काही सेकंदाला नियंत्रण सॉकेटशी पुन्हा जोडणारी स्क्रिप्ट स्वस्त नाही, कारण प्रत्येक पुनः कनेक्शन मालकाशी स्पर्धा करते।

स्नॅपशॉट हा इतिहास नाही आणि घटना प्रवाहही नाही। एका मध्यांतरात येऊन जाणारी कनेक्शन्स कधीच दिसत नाहीत, म्हणून स्वतःवर पुन्हा लिहिणाऱ्या फाइलला पोल करून लेखापरीक्षणाची गरज पूर्ण होऊ शकत नाही। वापरकर्ता जोडला गेला होता की नाही हे तुम्हाला जाणून घ्यायचे असेल, तर स्नॅपशॉट चुकीचे साधन आहे।

फॅन-आउट ही रचना आहे, मोड नाही

अनेक ग्राहकांना खरोखर थेट व्यवस्थापन डेटा हवा असेल, तर सॉकेटसमोर एक विश्वासार्ह घटक ठेवा आणि त्याला बाकीच्यांसाठी काळजीपूर्वक निवडलेली निरीक्षणे प्रकाशित करू द्या। तोच घटक पुनः कनेक्शन, प्रमाणीकरण प्रॉम्प्ट आणि काय उघड करणे सुरक्षित आहे या निर्णयाचा मालक आहे।

ते जाणीवपूर्वक तयार करा: कोणत्या क्वेरीला परवानगी आहे ते ठरवा, कोणी विचारले त्याची नोंद करा, आणि फॅन-आउट स्तर अनवधानाने रिमोट कंट्रोल पॅनेलमध्ये बदलणे टाळा। डेमनमध्ये सक्षम करण्यासाठी कोणताही मल्टी-क्लायंट मोड नाही, आणि कोणतीही कॉन्फिगरेशन ओळ असा मोड तयार करत नाही। मालकाला सुरक्षा सीमेचा भाग माना, कारण त्याच्याकडे लोकांना डिस्कनेक्ट करू शकणारा इंटरफेस आहे। तो पुन्हा सुरू करणे हे नोंदवलेल्या पुनर्प्राप्ती मार्गासह नियमित काम असावे।

सॉकेटला विशेषाधिकार माना, मेट्रिक्स नाही

व्यवस्थापन इंटरफेस वापरकर्त्यांना डिस्कनेक्ट करू शकतो, स्थिती बदलू शकतो आणि लोकांची नावे असलेल्या घटना वाचू शकतो। त्याचा पासवर्ड क्लायंटचे प्रमाणीकरण करतो आणि वाहतुकीचे एन्क्रिप्शन करत नाही, म्हणून नेटवर्कवरील श्रोता ती बोलणी पाहू शकणाऱ्या प्रत्येकासमोर उघड करतो।

स्थानिक सॉकेट किंवा कडकपणे मर्यादित श्रोत्याला प्राधान्य द्या, आणि तुमचा संकलक प्रत्यक्षात कोणत्या प्रक्रियेला संबोधत आहे ते तपासा, कारण सर्व्हर उत्पादने आपल्या स्वतःच्या व्यवस्थापन API सह येतात ज्या वेगळ्या पद्धतीने वागतात। चुकीच्या डेमनकडे निर्देशित संकलक आत्मविश्वासपूर्ण आणि चुकीचे निष्कर्ष देतो। काहीही परत न देणाऱ्या क्वेरीचे निराकरण करण्यापूर्वी मार्ग आणि मालक प्रक्रिया पुष्टी करा।

संबंधित लेख