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