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