OpenVPN systemd को पासवर्ड अनुरोधको प्रतीक्षामा छ: जवाफ दिनु पर्छ?

टर्मिनलमा systemd-tty-ask-password-agent बारे सन्देश देखा पर्छ, र टनेल माथि छैन। VPN ले पासवर्ड अस्वीकार गर्यो र अहिले केही सुधारको प्रतीक्षामा छ भन्ने लोभ्याउने पाठ हो। अझ सटीक भन्ने हो भने, कुनै सेवाले systemd सँग अन्तरक्रियात्मक इनपुट मागेको छ, र अनुरोधको जवाफ अझै दिइएको छैन। कुन सेवाले सोध्यो र कुन रहस्य चाहन्छ भन्ने दुई प्रश्न तपाईं केही पनि टाइप गर्नुअघि टुंग्याउन सक्नुहुन्छ।

कसले जवाफ दिनुपर्छ दुई सर्तले निर्धारण गर्छ

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

दुवै जवाफ स्पष्ट भएपछि निर्णय सरल हुन्छ: सेवाको आफ्नै समर्थित प्रम्प्ट मार्गबाट जवाफ दिनुहोस्। कुनै एउटा अस्पष्ट भएमा सही कदम अनुसन्धान गर्नु हो, तपाईंले जोड्न नसक्ने प्रम्प्टमा पासवर्ड टाइप गर्नु होइन।

यही पूरै नियम हो, र आदेशअघि यो भन्न लायक छ। तलको सबै यसैबाट आउँछ।

केही पनि टाइप गर्नुअघि अनुरोधको सूची हेर्नुहोस्

एजेन्टले केहीलाई पनि जवाफ नदिई के बाँकी छ सूचीबद्ध गर्न सक्छ। sudo systemd-tty-ask-password-agent --list बाँकी अनुरोधहरू प्रिन्ट गर्छ, र त्यो आउटपुट नै प्रम्प्टलाई युनिटसँग जोड्न चाहिने प्रमाण हो। प्रमाणपत्र दिनुअघि यो पढ्नुहोस्, र अनुरोधका विवरण कुनै पनि सार्वजनिक निदान पेस्टबाट बाहिर राख्नुहोस्।

सूचीलाई तपाईंले सुरु गर्नुभएको अपरेसन र त्यसको मालिक युनिटसँग जोड्नुहोस्। सूचीमा केही पनि तपाईंको कार्यसँग मिलेन भने, तपाईंले देख्नुभएको प्रम्प्ट अर्को सेवाको हो र त्यसलाई समाधान गर्नु तपाईंको काम होइन। सूचीमा युनिटको नाम नै प्रम्प्ट र सेवाबीचको एकमात्र भरपर्दो कडी हो।

तपाईंले जोड्न नसक्ने अनुरोधको जवाफ नदिनुहोस्। पर्खाइको मूल्य ढिलाइ हो, जबकि गलत प्रम्प्टको जवाफ दिने मूल्य गलत ठाउँमा प्रमाणपत्र हो।

इन्स्टेन्सलाई साँच्चै कुन रहस्य चाहिन्छ?

auth-user-pass VPN सेवासँगको खाता प्रमाणीकरणसँग सम्बन्धित छ, र प्रमाणपत्र फाइल बिना अभिलेखित व्यवहार कन्सोलमा सोध्नु हो। askpass बरु सुरक्षित कुञ्जी सामग्री खोल्ने पासफ्रेज प्राप्त गर्छ, र प्रक्रिया पृष्ठभूमिमा जानुअघि नै त्यो गर्छ। यी फरक आयुका फरक रहस्य हुन्।

फाइल ढाँचा पनि फरक छन्। खाता ढाँचाले प्रयोगकर्तानामको लाइन र पासवर्डको लाइन अपेक्षा गर्छ, जबकि कुञ्जी-पासफ्रेज फाइलले पहिलो लाइनलाई आफ्नो पासवर्डका रूपमा पढ्छ। अर्को भूमिकाको प्रमाणपत्र फाइल विधि प्रतिलिपि गर्दा सामान्यतया समाधानको सट्टा अर्को प्रम्प्ट उत्पन्न हुन्छ। गलत आकारको फाइल फाइल नहुनुभन्दा नराम्रो हुन्छ, किनभने असफलता कसैले नहेर्ने ठाउँमा सर्छ।

के टाइप गर्ने निर्णय गर्नुअघि इन्स्टेन्सले कुन निर्देश प्रयोग गर्छ जाँच्नुहोस्। निर्देशको नामले नै प्रम्प्ट कुन रहस्यका लागि हो भन्ने बताउँछ।

--query ले के गर्छ जो --list ले गर्दैन

--query कल गर्ने टर्मिनलमा प्रत्येक बाँकी अनुरोध प्रशोधन गर्छ, जो एक प्रम्प्टको जवाफ दिनभन्दा धेरै फराकिलो कार्य हो। यो OpenVPN चयनकर्ता होइन, र व्यस्त मेसिनमा यसले अरू युनिटका अनुरोधको पनि जवाफ दिन सक्छ। निगरानी मोड अझ फराकिलो छ, किनभने यसले अनुरोध आउँदै गर्दा प्रशोधन गरिरहन्छ।

काम गर्ने सबैभन्दा साँघुरो संयन्त्र प्रयोग गर्नुहोस्। एउटै सेवाका लागि, त्यो सेवाको आफ्नै प्रम्प्ट प्रवाह विश्वव्यापी एजेन्टभन्दा साँघुरो हुन्छ, र जवाफलाई सोध्ने युनिटसँग जोडेर राख्छ।

एकचोटि सूचना देखा पर्यो भनेर एकपटकको अनुरोधलाई निगरानीविहीन विश्वव्यापी एजेन्ट बनाउनु — यसरी नै अस्थायी झन्झट स्थायी डिजाइन बन्छ। होस्टभरि पासवर्ड-सूचना युनिटहरू अक्षम गर्न पनि त्यही सावधानी लागू हुन्छ।

निर्णय गर्नुहोस्, त्यसपछि छनोट अभिलेख गर्नुहोस्

निगरानीविहीन तैनाथीका लागि, जडानको मालिकसँग प्रमाणपत्र स्रोत, फाइल अनुमति र नवीकरण तालिका सहमति गर्नुहोस्। अन्तरक्रियात्मक दोस्रो कारकलाई व्यक्ति वा समर्पित सेवा पहिचान चाहिन सक्छ। प्रम्प्ट दबाउँदा त्यो प्रमाणीकरण उत्पन्न हुँदैन, र auth-user-pass हटाउँदा त्यसको आवश्यकता पर्ने सेवा मात्र बिग्रन्छ।

अन्तरक्रियापछि त्यही इन्स्टेन्सको अर्को घटना हेर्नुहोस् र निजी स्रोत परीक्षण गर्नुहोस्। केही पनि बाँकी छैन भने होस्टमा प्रत्येक OpenVPN युनिट सुरु गर्नुको सट्टा इन्स्टेन्सको अवस्थामा फर्कनुहोस्।