अवैध सीक्रेट्स ही कंटेनरची समस्या आहे, पासवर्डचा नियम नाही
नाकारलेले क्रेडेन्शियल कदाचित गेटवेपर्यंत पोहोचलेच नसेल. आधी इनपुट कंटेनर, प्रमाणीकरणाचा टप्पा आणि खातेच तपासा.
"अवैध सीक्रेट्स" दिसल्यावर सहसा एकच निष्कर्ष निघतो: VPN ला विरामचिन्हे आवडत नाहीत. तो निष्कर्ष सहसा चुकीचा असतो, कारण संदेश बहुतेकदा कोणत्याही गेटवेने खाते पाहण्यापूर्वी स्थानिक प्रक्रियेतून येतो. एकच पासवर्ड दोन रचना पोहोचवतात — ग्राफिकल फील्ड आणि क्रेडेन्शियल फाइल — आणि त्या वेगवेगळ्या ठिकाणी अयशस्वी होतात. सुरुवातीपासून ठीक असलेला पासवर्ड सोपा करण्यापूर्वी कंटेनरची तुलना करा.
त्रुटी गेटवेच्या आधी येते
स्थानिक पडताळणी, बंदिस्त सीक्रेट स्टोअर, गहाळ एजंट आणि चुकीच्या स्वरूपाची क्रेडेन्शियल फाइल — हे सर्व वापरकर्त्याला एकच नकार म्हणून जाणवणारे अपयश निर्माण करतात. त्यातील एकही प्रमाणीकरण सर्व्हरशी संबंधित नाही. गेटवेचा स्वतःचा नकार ही वेगळी घटना असते आणि ती सहसा वेगळ्या संदेशासह व वेगळ्या वेळेस येते. ती बोगदा तयार झाल्यानंतर आणि क्रेडेन्शियल पाठवल्यानंतर घडते.
म्हणून पहिला प्रश्न कोणती अक्षरे वैध आहेत हा नसून प्रयत्न कुठे थांबला हा आहे. ज्या क्लायंटने कधीच कनेक्शन उघडले नाही त्याला कोणीही नाकारले नाही. तुम्ही पाहिलेला टप्पा लिहून ठेवा, कारण पुढील प्रत्येक पायरी त्या वर्गीकरणावर अवलंबून आहे.
हा फरक कोण दुरुस्त करेल हेही बदलतो. कंटेनरची समस्या उपकरणाची आणि त्याच्या मालकाची असते, तर खात्याचा नकार प्रमाणीकरण बॅकएंड चालवणाऱ्याचा असतो.
अक्षरांची नाही, कंटेनरची तुलना करा
GUI पासवर्ड फील्ड, कीचेन नोंद, दोन ओळींची क्रेडेन्शियल फाइल आणि ऑटोमेशन सीक्रेट — प्रत्येकजण तेच मूल्य वेगळ्या लिफाफ्यात घेऊन जातो. लिफाफ्याचे स्वतःचे नियम असतात आणि तेच नियम सहसा मोडतात. मूल्य क्वचितच समस्या असते; मूल्याची वाहतूक समस्या असते. या दोन कल्पना वेगळ्या ठेवा म्हणजे निदान लहान होते.
| 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-document ने फाइल तयार करणे टाळा. दोन्ही अक्षरे फाइलपर्यंत पोहोचण्यापूर्वी बदलू शकतात आणि त्यातून येणारे अपयश VPN चा नकार वाटते, कारण डिस्कवरील पासवर्ड तुम्हाला माहीत असलेल्या पासवर्डपेक्षा खरोखर वेगळा असतो. असे संशय असल्यास सीक्रेट न छापता फाइलची बाइट लांबी अपेक्षित मूल्याशी तुलना करा. एक-दोन बाइटचा फरक हा अवतरण अपघाताचा स्वाक्षरी असतो.
पहिल्या त्रुटीवरून टप्पा वाचा
एका प्रयत्नातील पहिला विशिष्ट संदेश ठेवा, नंतर त्याचे वर्गीकरण करा. स्थानिक पडताळणी त्रुटी, गहाळ खाजगी की, अनुपलब्ध सीक्रेट एजंट आणि गेटवे प्रमाणीकरण अपयश हे चार वेगळे निकाल आणि चार वेगळे मालक आहेत. त्यातील फक्त एक खात्याबद्दल आहे.
गेटवे खरोखर योग्यरित्या पोहोचवलेले क्रेडेन्शियल नाकारत असेल, तर खाते, प्रमाणीकरण बॅकएंड आणि आवश्यक आव्हान तपासा प्रशासकासोबत. सर्वसाधारण प्रमाणीकरण अपयश निषिद्ध अक्षराचे नाव घेत नाही.
मंजूर मूल्य योग्य यंत्रणेद्वारे पुनर्संचयित करा, ते अक्षरे आणि अंकांपर्यंत कमी करून नाही. पासवर्ड धोरण ऑपरेटरचे असते आणि ते गुपचूप पराभूत करणारा उपाय दुरुस्ती नसतो. तो पुढच्या व्यक्तीपासून खरा दोष लपवतो, ज्याला त्याच त्रुटीचा, कमकुवत पासवर्डसह आणि अधिक चांगल्या कल्पनेशिवाय सामना करावा लागेल.