बूट पर शुरू होने वाली 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"

पहला आदेश पुष्टि करता है कि कौन-सी प्रोफ़ाइल मौजूद हैं और क्या कोई ऑटोकनेक्ट पर सेट है, जिस तरह बिना निगरानी वाला प्रयास शुरू ही होता है। दूसरा फ़्लैग मान उजागर करता है, और तीसरा सेवा को यह शिकायत करते दिखाता है कि किसी दिए गए सीक्रेट के लिए किसी एजेंट ने जवाब नहीं दिया। जो लॉग पंक्ति किसी सीक्रेट को एजेंट-स्वामित्व बताती है, वही एक वाक्य में पूरा निदान है।

कनेक्शन को सिस्टम स्कोप में ले जाने से उत्तर क्यों बदलता है

उपयोगकर्ता के स्वामित्व वाला कनेक्शन उसी उपयोगकर्ता के एजेंट के अधीन सक्रिय होता है, इसीलिए डेस्कटॉप ऊपर आते ही यह बिल्कुल ठीक काम करता है। इसे सिस्टम स्कोप में ले जाने से एजेंट रास्ते से हट जाता है, इसलिए वही प्रोफ़ाइल VPN कॉन्फ़िगरेशन की एक पंक्ति बदले बिना अलग व्यवहार करती है।

यह स्थानांतरण वैध डिज़ाइन है, और इसके साथ एक शर्त है: सीक्रेट सिस्टम सेवा तक पहुँचने योग्य होना चाहिए। उसे प्रोफ़ाइल में संग्रहीत करना, सिस्टम-स्कोप क्रेडेंशियल के ज़रिए देना, या सही क्षण पर इंटरैक्टिव प्रॉम्प्ट स्वीकार करना—सभी मान्य उत्तर हैं। फ़्लैग 1 छोड़कर उम्मीद करना नहीं।

अपने पासफ़्रेज़ वाली निजी कुंजी दूसरी परत जोड़ती है। संग्रहीत खाता पासवर्ड भी ऐसी कुंजी नहीं खोलेगा जो पासफ़्रेज़ माँगती है, इसलिए कुछ भी बदलने से पहले जाँचें कि विफल होने वाला चरण वास्तव में कौन-सा सीक्रेट माँग रहा है।

क्या न करें, और उसके बजाय क्या करें

हर क्रेडेंशियल फ़ाइल को सबके लिए पठनीय बनाना, या प्रमाणीकरण बंद कर देना ताकि प्रॉम्प्ट की ज़रूरत ही न हो—शुरुआती असुविधा को स्थायी रूप से खुला रहने से बदल देता है। दोनों निर्भरता को हल करने के बजाय छिपाते भी हैं, और अगला इमेज अपडेट वही विफलता लौटा देता है।

उस चरण पर वह तंत्र इस्तेमाल करें जिसे आपका वितरण बिना निगरानी वाली सक्रियता के लिए प्रलेखित करता है, फिर पुष्टि करें कि प्रोफ़ाइल के फ़्लैग उससे मेल खाते हैं। परिणाम साफ़ बूट से जाँचें, ऐसे शेल से नहीं जिसके पास पहले से एजेंट है। कनेक्शन का स्वामी, सीक्रेट का स्रोत और वह चरण लिख लें जिसे काम करना है, ताकि बाद में ऑटोस्टार्ट बदलाव चुपचाप किसी के डेस्कटॉप खोलने की निर्भरता वापस न ला सके। प्रलेखन ही ठीक की गई सेवा और अगली तिमाही में फिर टूटने वाली सेवा के बीच का अंतर है।

लॉगिन के बाद मैन्युअल पुनःप्रयास के बजाय नियंत्रित साफ़ बूट से परीक्षण करें। पुनःप्रयास उसी कारण सफल होता है जिस कारण बूट प्रयास विफल हुआ, और तेज़ परीक्षण ठीक वही सबूत नष्ट कर देता है।