NetworkManager नियंत्रण राखाडी? परवानग्यांपूर्वी मालकी तपासा

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

काहीही बदलण्यापूर्वी तीन फक्त-वाचन आदेश प्रकरणे वेगळी करतात।

तीन प्रश्न क्रमाने विचारा

nmcli device status
nmcli general permissions
nmcli connection show

हे अशा प्रणालीसाठी तपासणी आदेश आहेत जी प्रत्यक्षात NetworkManager वापरते, आणि सामान्य वापरकर्ता म्हणून ते चालवणे सुरक्षित आहे। आउटपुट कुठेही पेस्ट करत असाल तर खाजगी कनेक्शन तपशील सार्वजनिक लॉगपासून दूर ठेवा।

उपकरणाची स्थिती इंटरफेस व्यवस्थापित आणि वापरण्यायोग्य आहे का याचे उत्तर देते। परवानगी दृश्य कॉल करणाऱ्या सत्राला काय करण्याची परवानगी आहे याचे उत्तर देते। कनेक्शन यादी कोणते प्रोफाइल अस्तित्वात आहेत हे दाखवते; जुळणारा VPN संपादक किंवा आयात प्लगइन स्थापित आहे याचा ते पुरावा देत नाही।

मालकी आणि परवानगी वेगवेगळे दोष आहेत

न व्यवस्थापित असे चिन्हांकित केलेले उपकरण NetworkManager च्या नियंत्रणाबाहेर आहे, आणि कितीही परवानगी असली तरी कार्यरत टॉगल मिळणार नाही। ifupdown प्लगइन हे एक सामान्य कारण आहे: त्याचे managed सेटिंग interfaces फाइलमधील नोंदी कशा हाताळल्या जातात हे ठरवते, आणि उरलेला स्टॅन्झा इंटरफेसला जुन्या साधनाखाली ठेवू शकतो। फाइलचे अस्तित्व तिचा आशय हटवण्याची सूचना नाही, आणि तुम्ही न लिहिलेल्या नोंदी काढणे हा कनेक्टिव्हिटी गमावण्याचा चांगला मार्ग आहे।

परवानगी हा स्वतंत्र अक्ष आहे। NetworkManager रूट नसलेल्या कॉलरना PolicyKit मार्फत अधिकृत करते, आणि नोंदवलेले उत्तर yes, auth किंवा no असू शकते। अधिकृतता एजंट नसलेले सत्र auth नोंदवते आणि नंतर डेस्कटॉपवर शांतपणे अयशस्वी होते, जे गहाळ एजंटऐवजी तुटलेले नियंत्रण वाटते।

दोन्हीपैकी एकही डेस्कटॉप रूट म्हणून चालवून दुरुस्त करू नका

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

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

प्लगइनचा प्रश्न संपादकाबद्दलही आहे

VPN कनेक्शन तयार करणे किंवा आयात करण्यासाठी तो कनेक्शन प्रकार पुरवणारे प्लगइन आवश्यक आहे, आणि डेस्कटॉपवर सहसा संपादक एकत्रीकरण देखील आवश्यक असते। संपादक फॉर्म नसताना सेवा-बाजूचे पॅकेज असू शकते, म्हणूनच मेनू नोंद अस्तित्वात असूनही अयशस्वी होऊ शकते। एकच पॅकेज सर्व स्थापित करते असे गृहीत धरण्याऐवजी वितरणाच्या पॅकेजिंगशी दोन्ही अर्धे तपासा।

स्वतंत्र क्लायंट बायनरी देखील पुरावा नाही। OpenVPN बायनरी स्थापित केल्याने डेस्कटॉप संपादकाला OpenVPN प्रोफाइल तयार करण्यासाठी फॉर्म मिळत नाही।

जबाबदार सीमा दुरुस्त करा, नंतर पडताळा

कोणती सीमा चुकीची आहे हे कळल्यावर फक्त तीच बदला। उपकरण व्यवस्थापित म्हणून चिन्हांकित करणे, परवानगी देणे किंवा संपादक पॅकेज स्थापित करणे या तीन वेगवेगळ्या जोखीम प्रोफाइल्सच्या तीन वेगळ्या क्रिया आहेत, आणि त्या मिसळल्यास निकाल कोणालाही जोडता येत नाही। मालकी हलवावी लागली तर कन्सोल किंवा out-of-band प्रवेश उपलब्ध असताना करा, कारण तिथली चूक दुरुस्त करण्यासाठी वापरत असलेले नेटवर्क काढून टाकू शकते।

मग खऱ्या खात्याने आणि खऱ्या प्रोफाइलने पडताळा: मार्ग, DNS दृश्य आणि गुप्त कुठे साठवले आहे याची खात्री करा। सुरू केलेली बटणे ही इंटरफेस स्थिती आहे, टनेल चालत असल्याचा पुरावा नाही। तिकिटात उपकरण स्थिती, परवानगीचे उत्तर आणि प्लगइन आवृत्ती नोंदवा, जेणेकरून पुढच्या व्यक्तीला कोणती सीमा प्रत्यक्षात बदलली हे कळेल।