डेस्कटप 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 जोडिएको रहँदा पनि काम गरिरहन्छ।

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

अन्तराल ताजगीको बजेट हो, त्यसैले यसलाई ड्यासबोर्डलाई साँच्चै चाहिने कुरामा राख्नुहोस्, सुरक्षित देखिने सबैभन्दा सानो मानमा होइन। हरेक केही सेकेन्डमा लेखिने स्न्यापसट सस्तो हुन्छ; हरेक केही सेकेन्डमा नियन्त्रण सकेटसँग पुनः जोडिने स्क्रिप्ट सस्तो हुँदैन, किनकि हरेक पुनः जडानले मालिकसँग प्रतिस्पर्धा गर्छ।

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

फ्यान-आउट एउटा डिजाइन हो, मोड होइन

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

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

सकेटलाई विशेषाधिकार मान्नुहोस्, मेट्रिक्स होइन

व्यवस्थापन इन्टरफेसले प्रयोगकर्तालाई विच्छेद गर्न सक्छ, स्थिति बदल्न सक्छ र मानिसहरूको नाम भएका घटना पढ्न सक्छ। यसको पासवर्डले क्लाइन्ट प्रमाणित गर्छ र यातायात इन्क्रिप्ट गर्दैन, त्यसैले नेटवर्कमा सुन्ने व्यक्तिले कुराकानी हेर्न सक्ने जोकोहीसमक्ष खुला गरिदिन्छ।

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

सम्बन्धित लेखहरू