L2TP/IPsec विफल: IPsec, टनल प्रमाणीकरण या PPP लॉगिन को अलग करें

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

तीन प्रमाणीकरण चरण, तीन अलग पहचान

IPsec सिद्ध करता है कि सिरे किसके हैं, पूर्व-साझा कुंजी या प्रमाणपत्र का उपयोग करके। वह पहचान मशीनों या गेटवे की होती है, कीबोर्ड पर बैठे इंसान की कभी नहीं। जब सहकर्मी इस चरण पर सहमत नहीं हो पाते, तो कोई भी L2TP पैकेट विनिमय ही नहीं होता।

L2TP नियंत्रण कनेक्शन एक दूसरा, अलग चुनौती-प्रतिक्रिया विनिमय जोड़ सकता है, जिसे एक साझा रहस्य चलाता है जो दोनों सिरों के पास होना चाहिए।

RFC 2661 उस नियंत्रण-कनेक्शन प्रमाणीकरण को वैकल्पिक बनाता है, जो समझाता है कि वही गलती दो सर्वरों पर अलग लक्षण क्यों पैदा करती है। जिस परिनियोजन ने कभी टनल रहस्य कॉन्फ़िगर नहीं किया, वह चरण पूरी तरह छोड़ देता है; जिसने इसे केवल एक ओर कॉन्फ़िगर किया, वह PPP दिए जाने से पहले ही विफल हो जाता है। फिर PPP उपयोगकर्ता को PAP, CHAP या MSCHAPv2 से प्रमाणित करता है और नाम उस खाता भंडार को सौंपता है जो स्थानीय हो सकता है, chap-secrets में, या RADIUS पर। उस समय गलत पासवर्ड फिर भी आपको काम करती टनल और विफल सत्र के साथ छोड़ देता है।

कॉन्फ़िग बदलने से पहले रुकने का स्थान पढ़ें

ipsec --version से शुरू करें ताकि आप जान सकें कि स्थिति आउटपुट strongSwan का है या Libreswan का। फिर सर्वर लॉग पढ़ें, क्लाइंट संवाद नहीं, क्योंकि सर्वर दर्ज करता है कि किस चरण ने मना किया।

एक पंक्ति अकसर टिकट तय कर देती है: IKE या प्रस्ताव की शिकायत पहला चरण है, नियंत्रण-कनेक्शन संदेश दूसरा चरण है, और PPP विधि या खाता अस्वीकृति तीसरा चरण है। उस पंक्ति को समय-चिह्न के साथ टिकट में कॉपी करें। क्लाइंट की ओर से अनुमान लगाना उस एकमात्र सबूत को बर्बाद करता है जो आपके पास पहले से है।

कुंजी सामग्री और पासवर्ड उस पेस्ट से बाहर रखें; चरण का नाम काम को दिशा देता है, और लीक हुई पूर्व-साझा कुंजी टिकट को और बुरे परिणामों के साथ फिर खोल देती है।

पहला चरण: क्या IPsec के पास एसोसिएशन है?

strongSwan पर ipsec statusall चलाएँ या Libreswan पर ipsec whack --status और गैर-शून्य काउंटर वाला स्थापित चाइल्ड एसोसिएशन खोजें। ip xfrm state दोनों पर कर्नेल का दृश्य दिखाता है। काउंटर बढ़ते हुए स्थापित SA की जोड़ी का अर्थ है कि पहला चरण पूरा है और आप आगे बढ़ सकते हैं।

एसोसिएशन का बिल्कुल न होना पीयर पते, प्रस्ताव सेट, या पूर्व-साझा कुंजी की ओर इशारा करता है, और कभी-कभी ऐसे उपकरण की ओर जो UDP 500 को फिर से लिखता है पर UDP 4500 गिरा देता है। जो एसोसिएशन बनकर कुछ सेकंड बाद गायब हो जाता है वह आमतौर पर क्रेडेंशियल समस्या नहीं बल्कि दोनों सिरों के बीच लाइफ़टाइम की असंगति होती है। कुछ भी फिर से टाइप करने से पहले जाँचें कि दोनों पक्ष एक ही एन्क्रिप्शन और हैश प्रस्ताव सूचीबद्ध करते हैं। यदि नहीं, तो कोई कुंजी कभी काम नहीं करेगी।

एसोसिएशन गायब होने पर रुकें। उस समय PPP विकल्प संपादित करना कुछ नहीं बदलता और असली खराबी को अगले व्यक्ति से छिपा देता है।

दूसरा चरण: क्या L2TP नियंत्रण कनेक्शन ने प्रमाणीकरण किया?

IPsec चालू होने पर, L2TP डेमन पर स्थापित स्थिति तक पहुँचने वाले नियंत्रण कनेक्शन पर नजर रखें, क्योंकि उससे पहले PPP शुरू नहीं हो सकता। नियंत्रण कनेक्शन पर अस्वीकृति का अर्थ है कि टनल रहस्य सिरों के बीच अलग है, या एक सिरा ऐसा रहस्य माँगता है जो दूसरा कभी नहीं भेजता। क्लाइंट अकसर shared secret लेबल वाला एक ही फ़ील्ड दिखाते हैं, और वह आमतौर पर L2TP के बजाय IPsec का होता है। उसे भरने से टनल रहस्य कॉन्फ़िगर नहीं होता, और उसे खाली करने से वह बंद नहीं होता।

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

केवल वही सत्र जो PPP पर बातचीत शुरू करता है, वास्तव में टनल चरण पार कर चुका है।

तीसरा चरण: क्या PPP खाते को अस्वीकार कर रहा है?

PPP विफलता बाहर से अलग दिखती है: टनल स्थापित है, सत्र शुरू होता है, और डेमन प्रमाणीकरण विधि की विफलता या खाता अस्वीकृति दर्ज करता है। उस संदेश में नामित विधि पढ़ें। PAP और CHAP अलग कारणों से विफल होते हैं, और जो सर्वर एक को मना करता है वह केवल उसी को पेश करने वाले क्लाइंट को अस्वीकार करेगा।

Linux सर्वर पर, डेमन द्वारा PPP को दिया जाने वाला विकल्प फ़ाइल जाँचें, आमतौर पर /etc/ppp/options.xl2tpd, और पुष्टि करें कि कौन-सी विधियाँ स्वीकार की जाती हैं और खाते कहाँ हल होते हैं। RADIUS में मौजूद पर स्थानीय रहस्य फ़ाइल में न होने वाला नाम साफ़ तौर पर विफल होता है और गलत पासवर्ड जैसा लगता है। फिर जाँचें कि क्लाइंट ऐसी विधि पेश करता है जो सर्वर स्वीकार करता है, न कि अधिक मज़बूत विधि जिस पर बातचीत सर्वर मना करता है। इस चरण को ठीक करने के लिए पूर्व-साझा कुंजी बदलना एक दोपहर बर्बाद करता है और कुछ नहीं बदलता।

जब सत्र आखिरकार उठता है, पता आवंटन, DNS और रूट अभी भी बिना जाँचे हैं, और हर एक अपने तरीके से चुपचाप विफल होता है। अपने नोट्स में तीनों परतें अलग रखें: सही कुंजी के साथ गलत खाता हमेशा विफल होता है, और एक परत को ठीक करना कभी दूसरी को ठीक नहीं करता।