OpenVPN सेवा निजी कुञ्जीको पासवर्ड माग्दा रोकिन्छ: कसरी ठीक गर्ने
सेवासँग टर्मिनल हुँदैन, त्यसैले इन्क्रिप्टेड कुञ्जीलाई askpass र पढ्न योग्य फाइल चाहिन्छ। कुञ्जीको पासफ्रेज सर्भर लगइनबाट अलग राख्नुहोस् र unit जाँच्नुहोस्।
OpenVPN स्थानीय मेसिनमा निजी कुञ्जीको पासफ्रेज माग्छ, त्यसैले काम गर्ने लगइन फाइलले त्यसलाई कहिल्यै जवाफ दिँदैन। सेवामा टाइप गर्न टर्मिनल हुँदैन, र सुरुवात या त अड्किन्छ या कारण नभई इनपुटको नाम लिने जर्नल प्रविष्टिसँग असफल हुन्छ। यहाँ दुई गोप्य कुरा छन्, र unit पुनः सुरु गर्नुअघि प्रत्येकलाई आफ्नै पढ्न योग्य स्रोत चाहिन्छ। तलको क्रमले तिनलाई अलग गर्छ, त्यसपछि प्रत्येक फाइल वास्तवमै खोल्ने पहिचान जाँच्छ।
दुई अनुरोध छुट्याउनुहोस्
कुञ्जीको पासफ्रेजले स्थानीय निजी कुञ्जी डिक्रिप्ट गर्छ; खाताका प्रमाणहरूले सर्भरसँग सत्र प्रमाणित गर्छन्। ती फरक ठाउँबाट आउँछन्, फरक क्षणमा असफल हुन्छन् र फरक सन्देश दिन्छन्। तिनलाई मिसाउँदा मानिसहरू पासवर्ड रिसेट खोज्न जान्छन्, तर खाता संलग्न नै थिएन। कुन गोप्य कुरा हराएको छ भन्ने एकमात्र भरपर्दो संकेत शब्दावली हो, त्यसैले कुनै विकल्प बदल्नुअघि अनुरोधको पाठ पढ्नुहोस्।
Community OpenVPN 2.x मा askpass पहिलो पङ्क्तिमा कुञ्जीको पासफ्रेज राख्ने फाइल देखाउँछ, र auth-user-pass एउटा पङ्क्तिमा प्रयोगकर्ता नाम र अर्कोमा पासवर्ड भएको फाइल देखाउँछ। दुवैमध्ये कुनै पनि फाइलले अर्को विकल्प पूरा गर्न सक्दैन। डेस्कटप एप वा NetworkManager प्रोफाइलले दुवैलाई आफ्नै गोप्य भण्डारमा राख्न सक्छ, जुन कमाण्ड-लाइन क्लाइन्टले कहिल्यै पढ्दैन, त्यसैले कुनै पनि बाटो लेख्नुअघि तपाईं कुन क्लाइन्ट कन्फिगर गर्दै हुनुहुन्छ भनी नोट गर्नुहोस्।
दुवै विकल्पलाई पढ्न योग्य फाइलतिर देखाउनुहोस्
दुवै इनपुट चाहिने प्रोफाइल अन्तमा तीन फाइल सन्दर्भ सहित रहन्छ: इन्क्रिप्टेड कुञ्जी, त्यसलाई खोल्ने पासफ्रेज र लगइन जोडी। CA र पहिचान जाँच नछोई तिनलाई थप्नुहोस्, किनकि तिनले सर्भर को हो भनी निर्धारण गर्छन् र यो समस्याको भाग होइनन्। यदि परिनियोजनले खाता प्रमाणहरू पटक्कै प्रयोग गर्दैन भने, auth-user-pass थप्दा कोही पनि दिन नसक्ने इनपुट बन्छ।
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authतर्क नभएका विकल्पहरू बाटो भएका विकल्पभन्दा फरक व्यवहार गर्छन्, र सेवामा यो भिन्नता महत्त्वपूर्ण छ। तर्क नभएको askpass अझै कन्सोल पढ्छ, र प्रयोगकर्ता नाम मात्र भएको auth-user-pass फाइलले अझै पासवर्ड अनुरोध पर्खाइमा छोड्छ। क्लाइन्ट डेमन बनेपछि टर्मिनलबाट इनपुट माग्नै सक्दैन, त्यसैले यसरी कन्फिगर गरिएको सेवा उठ्दैन।
निरपेक्ष बाटोहरूले कार्यशील डाइरेक्टरीको प्रश्न हटाउँछन् तर पहुँच दिँदैनन्। त्यसपछि स्वामित्व, मोड र मार्ग पार गर्ने कुरा आउँछन्, र तीनवटै प्रक्रिया चल्ने खातासँग जाँचिन्छन्।
प्रोफाइलभन्दा पहिले unit को कन्फिगरेसन पढ्नुहोस्
इन्स्टेन्सले कुन कन्फिगरेसन लोड गर्ने भनी unit निर्धारण गर्छ, तपाईंले सम्पादन गरिरहेको फाइल होइन। त्यसको कमाण्ड लाइन र सबै drop-in पढ्नुहोस्, त्यसपछि कार्यशील डाइरेक्टरी हुँदै वास्तवमै प्रयोग हुने प्रोफाइलसम्म जानुहोस्। अर्को .ovpn फाइलमा थपिएको पासफ्रेज सन्दर्भले यो इन्स्टेन्सका लागि केही बदल्दैन।
तीन पढ्न-मात्र आदेशहरूले यसको धेरैजसो जवाफ दिन्छन्। पहिलोले unit र सबै drop-in छाप्छ, दोस्रोले प्रक्रियालाई बाँध्ने पहिचान र स्यान्डबक्स सेटिङ छाप्छ, र तेस्रोले अघिल्लो सुरुवातले वास्तवमै केको गुनासो गर्यो त्यो छाप्छ। होस्टमा रहेको इन्स्टेन्स नाम प्रयोग गर्नुहोस्:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome र प्रोफाइलका आफ्नै user, group र chroot विकल्पमा ध्यान दिनुहोस्। गृह डाइरेक्टरीमुनिको फाइल तपाईंको शेलमा पढ्न योग्य हुन सक्छ र गृह डाइरेक्टरीहरू लुकाइएपछि सेवाभित्र अदृश्य हुन्छ। systemd जुन खाताबाट सुरु हुन्छ त्यही खाताले अन्तमा कुञ्जी खोल्छ भन्ने छैन।
रनटाइम पहिचानले दुवै फाइल खोल्न सक्छ भनी प्रमाणित गर्नुहोस्
मोड पढ्नु मात्र पर्याप्त हुँदैन, किनकि बाटोमा रहेको हरेक डाइरेक्टरी त्यही पहिचानले पार गर्न सक्नुपर्छ। बाटोलाई घटक-घटक हिँड्नुहोस्, त्यसपछि प्रक्रियाले प्रयोग गर्ने खाताको रूपमा खोल्ने परीक्षण गर्नुहोस्। root को स्वामित्वमा रहेको र मोड 600 भएको फाइल प्रक्रिया अझै root हुँदासम्म मात्र चल्छ, र धेरै प्रोफाइलले गर्ने विशेषाधिकार घटाएपछि त्यो सत्य हुँदैन। दुई आदेशले मार्ग पार गर्ने र खोल्ने दुवै समेट्छन्:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableपहिलो आदेशले हरेक घटकको मोड छाप्छ र खाता पार गर्न नसक्ने ठाउँमा असफल हुन्छ; दोस्रोले एकमात्र महत्त्वपूर्ण प्रश्नको जवाफ दिन्छ, अर्थात् रनटाइम पहिचानले फाइल पढ्न खोल्न सक्छ कि सक्दैन। दुवैले फाइलको सामग्री छाप्दैनन्, र फाइलमा पासफ्रेज हुँदा यही मुख्य कुरा हो। लगइन फाइलका लागि पनि परीक्षण दोहोर्याउनुहोस्, किनकि दुवै प्रायः फरक स्वामित्वमा राखिन्छन्।
यदि प्रक्रियाले chroot वा सीमित namespace प्रयोग गर्छ भने त्यही परीक्षण त्यो दृश्यभित्रबाट चलाउनुहोस्, नत्र जवाफले गलत फाइलसिस्टम वर्णन गर्छ। लुकाइएको गृह डाइरेक्टरीमुनि राखिएको पासफ्रेज unit बाहिर पास भई भित्र असफल हुने परीक्षणको सामान्य उदाहरण हो।
पहिलो सुरुवात जाँच्नुहोस्, त्यसपछि पुनः जडान
इन्स्टेन्स एकचोटि सुरु गर्नुहोस् र अन्तिम नभई पहिलो असफलता पढ्नुहोस्। हराएको इनपुट फाइल, असफल कुञ्जी डिक्रिप्सन र सर्भरबाट AUTH_FAILED तीन फरक घटना हुन्, तीन फरक सुधारसहित। अनुमति चेतावनी सुधार्नाले कुञ्जी खुल्यो कि भन्ने केही प्रमाणित गर्दैन।
जर्नलको पङ्क्तिले तीनमध्ये कुन अवस्था छ भन्छ। सुधार कुन इनपुट असफल भयो भन्नेबाट आउँछ:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
त्यसपछि तपाईंलाई साँच्चै आवश्यक जीवनचक्र परीक्षण गर्नुहोस्: बुटमा सुरुवात र समर्थित कुनै पनि पुनः जडान, तपाईंको शेलबाट हातले सुरु गर्ने मात्र होइन। auth-nocache हुँदा इनपुट पहिलो प्रयोगपछि फालिन्छ, त्यसैले पछिको पुनः जडानलाई अझै पढ्न योग्य स्रोत चाहिन्छ। डेस्कटप लगइनमा खुल्ने किरिङ कसैले लगइन गर्नुअघि सुरु भएको सेवाका लागि उपलब्ध हुँदैन, र हातको परीक्षण पास भई रिबुट असफल हुने यही सामान्य कारण हो। यदि पहिलो सुरुवात सफल भई पछिको पुनः जडान असफल भयो भने, अनुमति फेरि बदल्नुअघि पुनः जडान घटनाका लागि जर्नल पढ्नुहोस्।
कुञ्जीको छेउमा पासफ्रेज राख्दा इन्क्रिप्सनले दिने कुरा घट्छ, त्यसैले त्यो फाइल र त्यसका ब्याकअप सीमित गर्नुहोस्। कुञ्जीको पासफ्रेज हटाउनुलाई हराएको इनपुटको सुधार नभई अलग प्रमाण-निर्णय मान्नुहोस्। मानव स्वीकृति वा इन्टर्याक्टिभ MFA मा निर्भर परिनियोजनलाई यसको समर्थित एजेन्ट वा व्यवस्थापन एकीकरण चाहिन्छ; स्थायी रूपमा सुरक्षित एकपटकको कोड समान विकल्प होइन।