एक कार्यालय हर लैपटॉप को वही IPsec गुप्त कुंजी दे सकता है जबकि हर व्यक्ति अपने अलग खाते से साइन इन करता है, इसीलिए «कुंजी सही है» और «पासवर्ड सही है» दोनों सत्य हो सकते हैं और लॉगिन फिर भी विफल हो सकता है। L2TP और IPsec अलग-अलग चरणों में अलग-अलग पक्षों को प्रमाणित करते हैं। दोनों परतों की तुलना, और उन्हें अलग करने वाला त्रुटि कोड, इनमें से अधिकांश टिकटों को दोनों मान फिर बदलने से तेज़ी से बंद कर देते हैं। चरण परस्पर विनिमेय नहीं हैं, और आपके सामने का संदेश पहले ही बता रहा है कि कौन-सा चल रहा है।

दो परतें, दो अलग पहचानें

पहले IPsec साथी प्रमाणीकरण चलता है। क्लाइंट और गेटवे किसी भी टनल पेलोड के सुरक्षित होने से पहले पूर्व-साझा कुंजी या प्रमाणपत्र से एक-दूसरे को अपनी पहचान सिद्ध करते हैं। L2TP सत्र के भीतर PPP का आदान-प्रदान उसके बाद चलता है, और वहीं आपका उपयोगकर्ता नाम और पासवर्ड सर्वर के खाता भंडार के विरुद्ध जाँचा जाता है।

चरण स्वतंत्र हैं, इसलिए वैध उपयोगकर्ता खाता गलत IPsec कुंजी नहीं बचा सकता, और सही कुंजी समाप्त हो चुका पासवर्ड नहीं बचा सकती। टिकट में दोनों को अलग-अलग लिखें और निदान आमतौर पर उस पहली लॉग पंक्ति से निकल आता है जो किसी चरण का नाम लेती है।

Observed failureStage that rejected itField to touch
Security layer error 789 during initial negotiationIKE and IPsec peer authenticationThe pre-shared key or the certificate
Error 691, credentials not recognisedPPP user authenticationUser name, password, or account policy
Tunnel forms, then drops on the first packetNeither, usually routing or MTUAddress pool and interface configuration
Prompt repeats with no error textOften the client type selectionThe connection profile, not the secret

साझा गुप्त कुंजी साथी को सिद्ध करती है

पूर्व-साझा कुंजी एक समूह क्रेडेंशियल है जो गेटवे और उससे जुड़ने वाले हर क्लाइंट के पास होता है। यह सिद्ध करती है कि साथी कुंजी जानता है, और इससे IKE वे कुंजियाँ निकालता है जो कनेक्शन की रक्षा करती हैं। उस आदान-प्रदान में कुछ भी कीबोर्ड पर बैठे इंसान की पहचान नहीं करता। यही पूरा कारण है कि उसी टनल में उपयोगकर्ता-स्तरीय दूसरा लॉगिन मौजूद है।

उस डिज़ाइन का निरसन के लिए व्यावहारिक परिणाम है। एक लैपटॉप खोने का मतलब है उसका उपयोग करने वाले हर डिवाइस के लिए गुप्त कुंजी बदलना, जब तक कि तैनाती प्रमाणपत्रों की ओर न जाए, जहाँ बाकी को छुए बिना एक डिवाइस हटाया जा सकता है। यह सौदा प्रशासनिक श्रम बनाम नुकसान के दायरे का है।

प्रोफ़ाइल में टाइप की गई कुंजी स्क्रीनशॉट और चैट से लीक होने वाला सबसे आसान क्रेडेंशियल भी है। इसे व्यक्तिगत पासवर्ड नहीं, बल्कि साझा अधोसंरचना सामग्री मानें, क्योंकि यह ठीक वही है।

लॉगिन PPP का है

L2TP सत्र के भीतर PPP प्रमाणीकरण पर बातचीत करता है और सर्वर से आपके टाइप किए गए मानों की जोड़ी सत्यापित करने को कहता है। Windows में ये वही उपयोगकर्ता नाम और पासवर्ड हैं जो प्रोफ़ाइल माँगता है, और राउटर में वही जिसका संदर्भ PPP प्रोफ़ाइल देता है। यह खाता भंडार के विरुद्ध जाँचा जाता है, कुंजी के विरुद्ध नहीं। दो लोग लैपटॉप और कुंजी साझा कर सकते हैं और फिर भी इस चरण पर अलग पहचाने जाते हैं।

चूँकि यह उपयोगकर्ता प्रमाणीकरण है, सामान्य खाता नीतियाँ सभी लागू होती हैं: समाप्त पासवर्ड, लॉक किया गया खाता, डायल-इन अनुमति, या ऐसा नाम जिसमें डोमेन होना चाहिए। त्रुटि 691 उस संयोजन को अस्वीकृत बताती है, इसलिए कुछ भी दोबारा टाइप करने से पहले सर्वर का लेखा रिकॉर्ड पढ़ें।

त्रुटि को फ़ील्ड चुनने दें

त्रुटि 789 सुरक्षा परत का नाम लेती है और IPsec चरण की ओर संकेत करती है। पुष्टि करें कि दोनों पक्षों की पूर्व-साझा कुंजी बिल्कुल मेल खाती है, गेटवे जिस साथी पहचान की अपेक्षा करता है वह क्लाइंट द्वारा भेजी गई पहचान से मेल खाती है, और क्लाइंट किसी दूसरे प्रकार के बजाय L2TP/IPsec के लिए कॉन्फ़िगर है।

त्रुटि 691 क्रेडेंशियल का नाम लेती है और PPP की ओर संकेत करती है। गुप्त कुंजी बदलने से पहले खाते की स्थिति और नाम का सटीक प्रारूप जाँचें, क्योंकि दोनों एक साथ बदलने से वह साक्ष्य नष्ट हो जाता है जो आप पढ़ रहे थे।

जब टनल बन जाए और ट्रैफ़िक फिर भी रुके, तो प्रमाणीकरण फ़ील्ड संपादित करना पूरी तरह बंद कर दें। पता पूल, क्लाइंट सबनेट तक वापसी मार्ग और MTU देखें: दोनों परतों की तुलना तभी मदद करती है जब विफलता अभी भी उनके भीतर हो।

संबंधित लेख