अमान्य सीक्रेट एक कंटेनर समस्या है, पासवर्ड नियम नहीं
अस्वीकार किया गया क्रेडेंशियल शायद कभी गेटवे तक पहुँचा ही नहीं। पहले इनपुट कंटेनर, प्रमाणीकरण चरण और स्वयं खाते की तुलना कीजिए।
अमान्य सीक्रेट देखकर आम तौर पर एक ही निष्कर्ष निकलता है: VPN को विराम चिह्न पसंद नहीं हैं। यह निष्कर्ष आम तौर पर गलत होता है, क्योंकि संदेश अक्सर स्थानीय प्रसंस्करण से आता है, इससे पहले कि कोई गेटवे खाते को देखे। दो डिज़ाइन वही पासवर्ड भेजते हैं, एक ग्राफ़िकल फ़ील्ड और एक क्रेडेंशियल फ़ाइल, और वे अलग-अलग जगहों पर विफल होते हैं। ऐसे पासवर्ड को सरल बनाने से पहले कंटेनरों की तुलना कीजिए जो शुरू से ही ठीक था।
त्रुटि गेटवे से पहले आती है
स्थानीय सत्यापन, बंद रहस्य भंडार, गुम एजेंट और ख़राब क्रेडेंशियल फ़ाइल ये सभी ऐसी विफलताएँ पैदा करते हैं जिन्हें उपयोगकर्ता एक ही अस्वीकृति के रूप में अनुभव करता है। इनमें से किसी में भी प्रमाणीकरण सर्वर शामिल नहीं है। गेटवे की अपनी अस्वीकृति एक अलग घटना है, और वह आम तौर पर अलग संदेश और अलग समय के साथ आती है। वह तब होती है जब सुरंग मौजूद है और क्रेडेंशियल भेजे जा चुके हैं।
इसलिए पहला सवाल यह नहीं है कि कौन-से अक्षर वैध हैं, बल्कि यह है कि प्रयास कहाँ रुका। जिस क्लाइंट ने कभी कनेक्शन नहीं खोला, उसे किसी ने अस्वीकार नहीं किया। जो चरण आपने देखा उसे लिख लीजिए, क्योंकि हर आगे का कदम उसी वर्गीकरण पर निर्भर है।
यह अंतर यह भी बदलता है कि इसे कौन ठीक करेगा। कंटेनर की समस्या डिवाइस और उसके मालिक की है, जबकि खाते की अस्वीकृति उस व्यक्ति की है जो प्रमाणीकरण बैकएंड चलाता है।
कंटेनरों की तुलना कीजिए, अक्षरों की नहीं
ग्राफ़िकल पासवर्ड फ़ील्ड, कीचेन प्रविष्टि, दो पंक्तियों वाली क्रेडेंशियल फ़ाइल और ऑटोमेशन का सीक्रेट हर एक वही मान अलग लिफ़ाफ़े में ले जाता है। लिफ़ाफ़े के अपने नियम होते हैं, और आम तौर पर वही नियम टूटते हैं। मान शायद ही कभी समस्या होता है; मान का परिवहन समस्या होता है। इन दो विचारों को अलग रखिए और निदान छोटा हो जाएगा।
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
समुदाय के OpenVPN 2.6 क्लाइंट विकल्प उस दो-पंक्ति फ़ाइल का वर्णन करते हैं auth-user-pass के लिए, जिसमें वह व्यवहार भी शामिल है जब पासवर्ड पंक्ति न हो: क्लाइंट तब पूछता है। यही एक विवरण उन रिपोर्टों की पूरी श्रेणी समझाता है जिनमें कहा जाता है कि वह पासवर्ड माँग रहा है जो मैं पहले ही दे चुका हूँ। यह आपको यह भी बताता है कि खाली दूसरी पंक्ति एक अर्थपूर्ण स्थिति है, कोई हानिरहित स्वरूपण विकल्प नहीं।
उद्धरण चिह्न फिर एक अलग परत है: साधारण क्रेडेंशियल फ़ाइल में उद्धरण चिह्न डेटा के रूप में संग्रहीत होते हैं, जबकि शेल उन्हें हटा देता है इससे पहले कि प्रोग्राम कुछ देखे। वही अक्षर एक जगह हानिरहित है और दूसरी जगह संरचनात्मक। तालिका आपको यह नहीं बता सकती कि आपके क्लाइंट ने कौन-सा कंटेनर इस्तेमाल किया, इसलिए पंक्ति चुनने से पहले क्लाइंट का अपना कॉन्फ़िगरेशन पढ़िए।
पंक्ति विराम भी संरचनात्मक हैं। पंक्ति-सीमांकित फ़ील्ड वाली फ़ाइल ऐसा मान नहीं ले जा सकती जिसमें नई पंक्ति हो, और यह प्रारूप की सीमा है, पासवर्ड की मज़बूती पर कोई फ़ैसला नहीं। सीक्रेट को किसी अनौपचारिक फ़ाइल में फ़िट करने के लिए काटने के बजाय उस डिलीवरी तंत्र का उपयोग कीजिए जिसे परिनियोजन समर्थित करता है।
शेल की क्षति के बिना क्रेडेंशियल फ़ाइल बनाइए
सबसे सुरक्षित स्थानीय मार्ग सीक्रेट को शेल इतिहास और प्रक्रिया के आर्ग्युमेंट सूची से बाहर रखता है। दोनों फ़ील्ड इंटरैक्टिव रूप से पढ़िए, फिर वे दो पंक्तियाँ लिखिए जिनकी क्लाइंट अपेक्षा करता है। बाकी सब कुछ ऐसी कॉन्फ़िगरेशन फ़ाइल में रह सकता है जिसकी समीक्षा आसान हो।
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsपहले दो कमांड उपयोगकर्ता नाम और फिर पासवर्ड को बिना दिखाए पढ़ते हैं, तीसरा दोनों पंक्तियाँ लिखता है, चौथा फ़ाइल को प्रतिबंधित करता है, और अंतिम उस फ़ाइल के साथ क्लाइंट शुरू करता है। ध्यान दीजिए कि read -r बैकस्लैश सुरक्षित रखता है, और ठीक ऐसा ही विवरण काम करने वाले पासवर्ड को विफल कर देता है जब वह छूट जाए।
फ़ाइल को बिना उद्धरण वाले वेरिएबल या शेल विस्तार से भरे here-दस्तावेज़ से बनाने से बचिए। दोनों अक्षरों को फ़ाइल तक पहुँचने से पहले बदल सकते हैं, और परिणामी विफलता VPN की अस्वीकृति जैसी दिखती है क्योंकि डिस्क पर पासवर्ड वास्तव में उससे अलग है जो आप जानते हैं। अगर ऐसा संदेह हो, तो सीक्रेट को प्रिंट किए बिना फ़ाइल की बाइट लंबाई की तुलना अपेक्षित मान से कीजिए। एक या दो बाइट का अंतर उद्धरण दुर्घटना का संकेत है।
पहली त्रुटि से चरण पढ़िए
एक प्रयास का पहला विशिष्ट संदेश रखिए, फिर उसका वर्गीकरण कीजिए। स्थानीय सत्यापन त्रुटि, गुम निजी कुंजी, अनुपलब्ध सीक्रेट एजेंट और गेटवे प्रमाणीकरण विफलता चार अलग परिणाम हैं जिनके चार अलग स्वामी हैं। इनमें से केवल एक खाते से जुड़ा है।
अगर गेटवे वास्तव में सही ढंग से पहुँचाए गए क्रेडेंशियल को अस्वीकार कर रहा है, तो प्रशासक के साथ खाते, प्रमाणीकरण बैकएंड और किसी भी आवश्यक चुनौती की जाँच कीजिए। सामान्य प्रमाणीकरण विफलता किसी निषिद्ध अक्षर का नाम नहीं लेती।
स्वीकृत मान को सही तंत्र से बहाल कीजिए, उसे अक्षरों और अंकों तक घटाने के बजाय। पासवर्ड नीति ऑपरेटर की है, और जो भी उपाय चुपचाप उसे हरा दे वह समाधान नहीं है। यह अगले व्यक्ति से असली दोष भी छिपा देता है, जो उसी त्रुटि से कमज़ोर पासवर्ड और बेहतर विचार के बिना मिलेगा।