बूटवर सुरू होणारी VPN सेवा तुमची कीरिंग का वाचू शकत नाही
बूटच्या वेळच्या VPN कडे उसनवारी करण्यासाठी कोणताही अनलॉक सीक्रेट एजंट नाही। सर्व्हरने कधीही नाकारलेला पासवर्ड रीसेट करण्यापूर्वी कनेक्शनचे सीक्रेट फ्लॅग वाचा।
लॉगिननंतर काम करणारे आणि त्याआधी अयशस्वी होणारे कनेक्शन सहसा याचा अर्थ बूटच्या वेळचा प्रयत्न सीक्रेट मिळवू शकला नाही, सर्व्हरने एखादे नाकारले असे नाही। क्रेडेन्शियल अस्तित्वात आहे; ते मागणारा संदर्भ नाही। हाच एक फरक अनावश्यक पासवर्ड रीसेट वाचवतो।
विनंतीचा मागोवा घ्या: डेस्कटॉप सत्र असण्यापूर्वीच काहीतरी कनेक्शन सुरू करते, आणि सहसा उत्तर देणारे सीक्रेट स्टोअर अजून अनलॉक झालेले नाही। दोन्ही संदर्भ सीक्रेट कोणाचे आहे यावर सहमत नाहीत, आणि प्रोफाइल नोंदवते की त्यापैकी कोणी ते पुरवायचे आहे।
बूट मार्ग प्रत्यक्षात काय मागतो
बूटच्या वेळी, NetworkManager वापरकर्ता सत्र, सत्र D-Bus आणि अनलॉक कीरिंगशिवाय सिस्टम सेवा म्हणून सुरू होते। कनेक्शन प्रोफाइल तरीही वर उचलता येते, पण सेवा स्वतः पोहोचू शकेल अशा सीक्रेटनेच। सीक्रेट एजंटच्या मालकीचे जे काही असेल ते एखादा माणूस लॉगिन करून एजंट दिसेपर्यंत थांबते। सेवा तिच्या कॉन्फिगरेशननुसारच काम करत आहे; बदलायची गोष्ट म्हणजे प्रोफाइल।
अपयश कीरिंगमध्ये लपलेले नाही, कनेक्शनमध्येच लिहिलेले आहे।
कनेक्शनवरील सीक्रेट फ्लॅग वाचणे
कनेक्शनला विचारा की ते काय अपेक्षित आहे, डेस्कटॉपला काय आठवते ते नाही। फ्लॅग स्तंभ थेट प्रश्नाचे उत्तर देतो, आणि डिस्कवरील प्रोफाइल फाइलमध्ये तो रीबूटनंतरही टिकतो।
प्रोफाइल यादीपासून सुरुवात करा, मग कोणते कनेक्शन स्वतः वर येण्यासाठी सेट आहे याची खात्री करा। मग एक कनेक्शन डंप करा आणि पासवर्ड फ्लॅग वाचा:
nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show nmcli connection show "Work VPN" | grep -i -E "password|secret|key" journalctl -b -u NetworkManager --grep "secret"
पहिला आदेश कोणती प्रोफाइल आहेत आणि एक ऑटोकनेक्टवर सेट आहे का हे तपासतो, देखरेख नसलेला प्रयत्न सुरू होतोच तसा। दुसरा फ्लॅग मूल्ये उघड करतो, आणि तिसरा दिलेल्या सीक्रेटसाठी कोणत्याही एजंटने उत्तर दिले नाही अशी सेवा तक्रार करताना दाखवतो। सीक्रेटला एजंट-मालकीचे म्हणणारी लॉग ओळ म्हणजे एका वाक्यातील संपूर्ण निदान।
| Flag value | Where the secret lives | Behaviour before login |
|---|---|---|
| 0 | Stored in the connection profile | Available to the system service |
| 1 | Owned by a secret agent | Blocks until the agent is unlocked |
| 2 | Never stored | Prompts on every activation |
| 4 | Not required | Never requested at all |
कनेक्शन सिस्टम स्कोपमध्ये हलवल्याने उत्तर का बदलते
वापरकर्त्याच्या मालकीचे कनेक्शन त्या वापरकर्त्याच्या एजंटखाली सक्रिय होते, म्हणूनच डेस्कटॉप वर आल्यावर ते अगदी व्यवस्थित चालते। ते सिस्टम स्कोपमध्ये हलवल्याने एजंट मार्गातून निघून जातो, त्यामुळे तेच प्रोफाइल VPN कॉन्फिगरेशनची एकही ओळ न बदलता वेगळे वागते।
ते हलवणे हे कायदेशीर रचना आहे, आणि त्याबरोबर एक अट येते: सीक्रेट सिस्टम सेवेपर्यंत पोहोचण्यायोग्य असले पाहिजे। ते प्रोफाइलमध्ये साठवणे, सिस्टम-स्कोप क्रेडेन्शियलद्वारे पुरवणे, किंवा योग्य क्षणी इंटरॅक्टिव्ह प्रॉम्प्ट स्वीकारणे—हे सर्व वैध उत्तरे आहेत। फ्लॅग 1 सोडून आशा करणे नाही।
स्वतःच्या पासफ्रेजसह खाजगी की दुसरा थर जोडते। साठवलेला खाते पासवर्डही पासफ्रेज मागणारी की अनलॉक करणार नाही, म्हणून काहीही बदलण्यापूर्वी अयशस्वी होणारा टप्पा प्रत्यक्षात कोणते सीक्रेट मागत आहे ते तपासा।
काय करू नये, आणि त्याऐवजी काय करावे
प्रत्येक क्रेडेन्शियल फाइल सर्वांना वाचनीय करणे, किंवा प्रॉम्प्टची गरज नसावी म्हणून प्रमाणीकरण बंद करणे—सुरुवातीची गैरसोय कायमच्या उघडपणाशी बदलते। दोन्ही अवलंबित्व सोडवण्याऐवजी लपवतात, आणि पुढील इमेज अपडेट तेच अपयश परत आणते।
त्या टप्प्यावर तुमचे वितरण देखरेखमुक्त सक्रियतेसाठी जे यंत्रणा दस्तऐवजीकरण करते ती वापरा, मग प्रोफाइलचे फ्लॅग तिच्याशी जुळतात याची खात्री करा। निकाल स्वच्छ बूटमधून तपासा, आधीच एजंट असलेल्या शेलमधून नाही। कनेक्शनचा मालक, सीक्रेटचा स्रोत आणि जो टप्पा काम करायला हवा तो लिहून ठेवा, जेणेकरून नंतरचा ऑटोस्टार्ट बदल एखाद्याने आधी डेस्कटॉप अनलॉक करण्याचे अवलंबित्व शांतपणे परत आणू शकणार नाही। दस्तऐवजीकरण हेच दुरुस्त केलेली सेवा आणि पुढील तिमाहीत पुन्हा तुटणारी सेवा यातील फरक आहे।
लॉगिननंतरच्या हाताने पुनःप्रयत्नाऐवजी नियंत्रित स्वच्छ बूटमधून चाचणी करा। पुनःप्रयत्न बूटचा प्रयत्न अयशस्वी झाला त्या कारणानेच यशस्वी होतो, आणि वेगवान चाचणी नेमका तोच पुरावा नष्ट करते।