के त्यो 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प्याकेज प्रश्नले स्थानीय मेटाडाटाले के स्थापित र उपलब्ध मान्छ भन्ने जनाउँछ, र त्यो क्यास पुरानो हुन सक्छ, त्यसैले पहिले त्यसलाई ताजा गर्नुहोस्। यसले चलिरहेको सेवाले पाँच मिनेट अघि स्थापित बाइनरी लोड गरेको छ कि छैन पनि भन्दैन। प्याकेज रेकर्डलाई वास्तवमै जोडिएको प्रक्रियासँग तुलना गर्नुहोस्।
संस्करणको धारणाभन्दा प्याकेजको प्रमाण
वितरणहरूको सुरक्षा मर्मतले प्रायः सुधारहरू पछाडि सार्छ, त्यसैले पुरानो देखिने अपस्ट्रिम संस्करणमा पनि प्याच हुन सक्छ। उल्टो पनि सत्य हो: अपरिचित भण्डारबाट आएको प्याकेजसँग वर्तमान मर्मतको स्वतः दाबी हुँदैन। संस्करण नम्बरभन्दा रिलिजको समर्थन स्थिति पढ्नुहोस्।
त्यो भिन्नता नै वास्तविक खाडल र केवल पुरानो देखिने नम्बरबीचको भिन्नता हो। प्याकेज कुन भण्डारबाट आयो त्यो लेख्नुहोस्, किनकि एउटै संस्करण स्ट्रिङ धेरै फरक मार्गबाट धेरै फरक समर्थनसहित आउन सक्छ।
कन्फिगरेसन अर्को आधा हो
मर्मत गरिएको कार्यान्वयन योग्य फाइललाई पनि तपाईंलाई लाग्छ कि छ भन्ने जाँचहरू माग्ने प्रोफाइल चाहिन्छ। विश्वास एङ्कर, अर्को पक्षको अभिप्रेत भूमिका र अपेक्षित सर्भर नाम सम्बन्धित तर अलग निर्णय हुन्। भूमिका जाँच नाम जाँच होइन, र कुनैले अर्कोको स्थान लिँदैन। यदि चेतावनी कन्फिगरेसनबारे हो भने सुधार प्रोफाइलको मालिकको हो।
प्रमाणित नगरिएको प्रोफाइलको क्षतिपूर्ति गर्न मनपरी प्याच स्थापना नगर्नुहोस्, र वास्तविक कार्यान्वयन त्रुटि मर्मत गर्न कुनै निर्देश नथप्नुहोस्। दुवै गल्ती प्रगति जस्तो लाग्छ, त्यसैले दुवै हुँदै रहन्छन्।
रेकर्डमा रहेको प्रमाणसहित निर्णय गर्नुहोस्
निर्णय तपाईंले स्थापित गरेको कुराबाट आउँछ। अभिलेखित प्रभावित प्याकेजले त्यसको समर्थित अद्यावधिक माग्छ, असमर्थित प्लेटफर्मलाई स्थानान्तरण मार्ग चाहिन्छ, र प्रदायकको क्लाइन्टलाई त्यो प्रदायकको मार्गदर्शन चाहिन्छ। अस्पष्ट निर्देशलाई यीमध्ये कुनै पनि लागू हुनु अघि सूचना र प्रभावित घटक चाहिन्छ।
सक्रिय क्लाइन्ट, पूर्ण संस्करण, सूचना र प्रोफाइलको मालिकलाई परिवर्तन रेकर्डमा सँगै राख्नुहोस्। त्यो ट्युटोरियल सन्दर्भभन्दा बलियो छ, र अर्को व्यक्तिलाई वास्तवमै त्यही चाहिन्छ।