एक त्रुटि, तीन रहस्य: कौन-सा 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 बोलने वाला क्लाइंट चाहिए, जबकि प्रमाणपत्र लॉगिन के लिए क्लाइंट की निजी कुंजी और सर्वर की शृंखला चाहिए। गलत इंस्टॉल करें और विफलता क्रेडेंशियल त्रुटि जैसी पढ़ी जाती है, जबकि अनुपस्थित वस्तु प्रमाणीकरण विधि स्वयं है।
एक चीज़ बदलें, फिर दोबारा जाँचें
पहले तीन तथ्य तय करें: कौन-सा प्रोटोकॉल चल रहा है, वह कितने रहस्य परिभाषित करता है, और उनमें से कौन-से मशीन के हैं न कि उपयोगकर्ता के। मशीनें पहले चरण में विफल होती हैं और लोग दूसरे में, और इन दोनों को मिलाना ही यह पूरी समस्या है।
फिर ठीक एक चीज़ बदलें और उसी क्लाइंट से दोबारा जाँचें। यह अनुशासन भ्रमित करने वाली विफलता को ऐसे सुधार में बदल देता है जिसे आप अगले व्यक्ति को बता सकते हैं, और यह ऐसे चलते कनेक्शन से अधिक उपयोगी है जिसे कोई समझा नहीं सकता।