क्या वह OpenVPN सुरक्षा सुधार आपकी स्थापना से भी जुड़ा है?
पैच करना और कॉन्फ़िगर करना अलग-अलग दावे हैं। निष्पादन योग्य फ़ाइल, उसके पीछे का पैकेज और प्रोफ़ाइल वास्तव में जो जाँचें करता है, उन्हें पहचानें।
क्लाइंट को पैच करने की सलाह ताकि वह प्रमाणपत्रों को सत्यापित करे, उस पर कार्य करने के लिए बहुत अस्पष्ट है। यह किसी ठीक किए गए सॉफ़्टवेयर दोष, किसी एक प्रदाता के पुराने बिल्ड, या ऐसी प्रोफ़ाइल का वर्णन कर सकती है जिसने कभी यह जाँच माँगी ही नहीं। ये तीन अलग-अलग बदलाव हैं, तीन अलग-अलग मालिकों के साथ। आप किस स्थिति का सामना कर रहे हैं यह जाने बिना उस वाक्य पर कार्य करना ही वह तरीका है जिससे काम करता क्लाइंट बिना कारण बदल दिया जाता है।
तीनों दावों को अलग करें
सॉफ़्टवेयर दोष के पास एक सलाहकार सूचना, प्रभावित संस्करण और एक ठीक किया गया संस्करण होता है। प्रदाता के बिल्ड का अपना वितरण माध्यम और अपनी अद्यतन गति होती है। प्रोफ़ाइल की चूक के पास इनमें से कुछ भी नहीं होता, क्योंकि निष्पादन योग्य फ़ाइल ठीक है और कॉन्फ़िगरेशन आपकी धारणा से कम माँगता है। जब तक दावा इन तीनों में से एक का नाम न ले, जाँचने के लिए कुछ नहीं है।
खोजने से पहले दावे को एक वाक्य में लिखें। अगर वाक्य यह नहीं बता सकता कि क्या टूटा है, तो खोज का कोई लक्ष्य नहीं है और हर परिणाम प्रासंगिक लगता है।
| Claim | Evidence that settles it | Who owns the change |
|---|---|---|
| Software defect | Advisory naming affected versions | Package or product maintainer |
| Provider build | Release notes for that client | The provider |
| Profile omission | The configuration actually loaded | Whoever owns the profile |
वह निष्पादन योग्य फ़ाइल खोजें जो वास्तव में चलती है
किसी भी संस्करण को देखने से पहले पहचानें कि कनेक्शन क्या शुरू करता है। वितरण सेवा, डेस्कटॉप प्लगइन और विक्रेता एप्लिकेशन में से हर एक अलग निष्पादन योग्य फ़ाइल या इंजन का उपयोग कर सकता है। शेल के खोज पथ में जो भी बाइनरी मिल जाए, उसका छापा हुआ संस्करण मशीन की सूची नहीं है। उस यूनिट या प्रक्रिया को पढ़ें जिसने वास्तव में कनेक्शन किया।
systemctl cat openvpn-client@*.service
ps -o pid,cmd -C openvpn
apt-cache policy openvpn network-manager-openvpnपैकेज क्वेरी बताती है कि स्थानीय मेटाडेटा क्या स्थापित और उपलब्ध मानता है, और वह कैश पुराना हो सकता है, इसलिए पहले उसे ताज़ा करें। यह यह भी नहीं बताती कि चल रही सेवा ने पाँच मिनट पहले स्थापित बाइनरी लोड की या नहीं। पैकेज रिकॉर्ड की तुलना उस प्रक्रिया से करें जो वास्तव में जुड़ी हुई है।
संस्करण की धारणा के बजाय पैकेज के प्रमाण
वितरणों का सुरक्षा रखरखाव अक्सर सुधार पीछे ले जाता है, इसलिए पुराना दिखने वाला अपस्ट्रीम संस्करण भी पैच रख सकता है। उल्टा भी सच है: किसी अपरिचित रिपॉज़िटरी का पैकेज वर्तमान रखरखाव पर स्वतः दावा नहीं रखता। संस्करण संख्या के बजाय रिलीज़ की समर्थन स्थिति पढ़ें।
यही अंतर असली खाई और केवल पुराना दिखने वाली संख्या के बीच है। जिस रिपॉज़िटरी से पैकेज आया उसे दर्ज करें, क्योंकि वही संस्करण श्रृंखला बहुत अलग चैनलों से बहुत अलग समर्थन के साथ आ सकती है।
कॉन्फ़िगरेशन दूसरा आधा है
रखरखाव वाली निष्पादन योग्य फ़ाइल को अब भी ऐसी प्रोफ़ाइल चाहिए जो वे जाँचें माँगे जो आपको लगता है मौजूद हैं। ट्रस्ट एंकर, सामने वाले पक्ष की इच्छित भूमिका और अपेक्षित सर्वर नाम संबंधित पर अलग निर्णय हैं। भूमिका जाँच, नाम जाँच नहीं है, और कोई भी दूसरे की जगह नहीं लेती। अगर चेतावनी कॉन्फ़िगरेशन के बारे में है, तो सुधार प्रोफ़ाइल के मालिक का है।
असत्यापित प्रोफ़ाइल की भरपाई के लिए कोई मनमाना पैच स्थापित न करें, और किसी वास्तविक कार्यान्वयन दोष को ठीक करने के लिए कोई निर्देश न जोड़ें। दोनों गलतियाँ प्रगति जैसी लगती हैं, इसीलिए दोनों होती रहती हैं।
रिकॉर्ड में प्रमाण के साथ निर्णय लें
निर्णय उसी से निकलता है जो आपने स्थापित किया। प्रलेखित प्रभावित पैकेज अपने समर्थित अद्यतन की माँग करता है, असमर्थित प्लेटफ़ॉर्म को स्थानांतरण मार्ग चाहिए, और प्रदाता क्लाइंट को उस प्रदाता का मार्गदर्शन चाहिए। अस्पष्ट निर्देश को इनमें से कुछ भी लागू होने से पहले एक सलाहकार सूचना और एक प्रभावित घटक चाहिए।
सक्रिय क्लाइंट, पूर्ण संस्करण, सलाहकार सूचना और प्रोफ़ाइल का मालिक, इन्हें परिवर्तन रिकॉर्ड में साथ रखें। यह किसी ट्यूटोरियल के संदर्भ से अधिक मज़बूत है, और अगले व्यक्ति को वास्तव में इसी की ज़रूरत होगी।