एक त्रुटी, तीन रहस्ये: कोणते VPN क्रेडेन्शियल अयशस्वी झाले?
क्लायंट प्रत्येक टप्प्यासाठी एक त्रुटी दाखवतो। कोणीही तपासले नसलेला पासवर्ड रीसेट करण्यापूर्वी असोसिएशन, वापरकर्ता देवाणघेवाण आणि पद्धत वाचा।
«प्रमाणीकरण अयशस्वी झाले» हे सर्व्हर प्रमाणपत्र, मशीनची पूर्व-सामायिक की किंवा वापरकर्ता पासवर्ड याकडे निर्देश करू शकते। त्यापैकी कोणते याचा अर्थ आहे हे प्रोटोकॉलवर अवलंबून आहे, कारण प्रत्येक प्रोटोकॉल वेगळा रहस्यांचा संच परिभाषित करतो। चुकीचे रीसेट केल्यास त्रुटी जशीच्या तशी राहते। काहीही संपादित करण्यापूर्वी प्रोटोकॉल किती पुरावे मागतो हे निश्चित करणे हाच मार्ग आहे।
विरुद्ध दिशांना निर्देश करणारे दोन पुरावे
टनेलला योग्य गेटवे गाठला का आणि वेगळेपणे वापरकर्ता कोण आहे याचे उत्तर द्यावे लागते। गेटवेचा पुरावा मशीन पातळीवर आहे: सर्व्हर प्रमाणपत्र, पूर्व-सामायिक की किंवा स्थिर सार्वजनिक की। वापरकर्त्याचा पुरावा व्यक्ती पातळीवर आहे: पासवर्ड, टोकन, क्लायंट प्रमाणपत्र, किंवा काहीही नाही। हे विश्वासाच्या विरुद्ध दिशा आहेत आणि वेगळी सामग्री वापरतात।
IKEv2 गेटवेचा पुरावा IKE_AUTH मध्ये करतो आणि EAP वापरल्यास त्यानंतर वापरकर्त्याचा पुरावा वेगळ्या देवाणघेवाणीत चालवतो। IKEv2 विनिर्देश हे दोन्ही वेगळे विभाग म्हणून ठेवतो, जे एक संदेश दोन्ही फेऱ्या व्यापतो तेव्हा कुठे पाहावे याचा जोरदार इशारा आहे।
संदेश नाही, टप्पा वाचा
कोणता टप्पा अयशस्वी झाला याची पर्वा न करता क्लायंट एकच त्रुटी मालिका दाखवतो, त्यामुळे मालिका स्वतः जवळजवळ कोणतीही माहिती देत नाही। माहिती देते ती प्रत्येक टप्प्यावर तपासता येणारी स्थिती: असोसिएशन आहे का, वापरकर्ता देवाणघेवाण सुरू झाली का आणि क्लायंटने गेटवेला हवी असलेली पद्धत सादर केली का। तक्ता टप्प्यांची मांडणी प्रोटोकॉलच्या नावाने नाही तर त्याच पद्धतीने करतो।
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
वापरकर्ता पुन्हा टाइप करू शकणाऱ्या क्रेडेन्शियलबद्दल फक्त दुसरी ओळ आहे। उर्वरित तीन कॉन्फिगरेशनच्या वस्तुस्थिती आहेत, आणि हीच विसंगती अशा अनेक अहवाल काहीही न बदलणाऱ्या पासवर्ड रीसेटने संपण्याचे कारण आहे। कोणत्याही फील्डला स्पर्श करण्यापूर्वी तुमच्या पुराव्याशी जुळणारी ओळ वाचा।
दोन रहस्यांचा प्रोटोकॉल आपली पत्ती दाखवतो
L2TP IPsec वर गणना दृश्यमान करते, कारण दोन्ही तपासण्या वेगळ्या प्रक्रियांमध्ये होतात। IPsec स्तर प्रथम पूर्व-सामायिक की किंवा प्रमाणपत्राने वर यायला हवा, आणि त्यानंतरच त्यातील PPP वापरकर्ता लॉगिनचा प्रयत्न करतो।
मशीनचे रहस्य चुकीचे असल्यास असोसिएशन तयार होत नाही आणि वापरकर्त्याचे क्रेडेन्शियल कधीही वापरले जात नाही। मशीनचे रहस्य बरोबर आणि वापरकर्त्याचे रहस्य चुकीचे असल्यास असोसिएशन अस्तित्वात असते आणि टनेल आधीच वर आल्यानंतर PPP लॉगिन नाकारतो। दोन्ही दोन वेगळ्या घटनांमधून स्क्रीनवर तोच संदेश देतात।
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerरिकामी असोसिएशन यादी वापरकर्ता स्तर तात्काळ वगळते, म्हणून पासवर्डपूर्वी ती तपासा। वारंवार PPP अयशस्वी असलेले स्थापित असोसिएशन दुसऱ्या दिशेने, वापरकर्ता स्तर किंवा त्यातील प्रमाणीकरण प्रोटोकॉलकडे निर्देश करते। दोन्हीपैकी कोणताही निष्कर्ष क्लायंटच्या त्रुटी मजकुरातून उपलब्ध नाही।
फक्त पासवर्ड असलेला प्रवेश प्रत्यक्षात कशावर अवलंबून आहे
फक्त पासवर्ड असलेला प्रवेश L2TP, PPTP, SSTP आणि EAP असलेल्या IKEv2 साठी सामान्य आहे। WireGuard मध्ये अशा प्रकारचा पर्याय अजिबात नाही, कारण त्याचे सहकारी वापरकर्ते नाहीत, किल्या आहेत। OpenVPN साठी उत्तर सर्व्हरच्या क्लायंट प्रमाणपत्राच्या आवश्यकतेतून येते: प्रमाणपत्र आणि पासवर्ड दोन्ही मागणारा गेटवे फील्डमध्ये काहीही टाइप केले तरी फक्त-पासवर्ड क्लायंट नाकारत राहील।
तुम्हाला कोणता घटक हवा आहे हे त्याच उत्तरातून येते। IKEv2 अंतर्गत पासवर्ड लॉगिनसाठी EAP बोलणारा क्लायंट हवा, तर प्रमाणपत्र लॉगिनसाठी क्लायंटची खाजगी की आणि सर्व्हरची साखळी हवी। चुकीचे इन्स्टॉल केल्यास प्रमाणीकरण पद्धत स्वतःच गहाळ असतानाही अयशस्वीता क्रेडेन्शियल त्रुटीसारखी वाचली जाते।
एक गोष्ट बदला, मग पुन्हा तपासा
प्रथम तीन वस्तुस्थिती निश्चित करा: कोणता प्रोटोकॉल चालू आहे, तो किती रहस्ये परिभाषित करतो, आणि त्यापैकी कोणते वापरकर्त्याचे नाही तर मशीनचे आहेत। मशीन पहिल्या टप्प्यावर अयशस्वी होतात आणि माणसे दुसऱ्यावर, आणि या दोन्हींचा गोंधळ हीच ही पूर्ण समस्या आहे।
नंतर नेमकी एक गोष्ट बदला आणि त्याच क्लायंटवरून पुन्हा तपासा। ती शिस्त गोंधळात टाकणाऱ्या अयशस्वीतेचे अशा दुरुस्तीत रूपांतर करते जी तुम्ही पुढच्या व्यक्तीला सांगू शकता, आणि ती कोणीही समजावून सांगू न शकणाऱ्या चालणाऱ्या कनेक्शनपेक्षा अधिक उपयुक्त आहे।