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

एका L2TP/IPsec कनेक्शनमध्ये तीन गोष्टींचे प्रमाणीकरण होते, आणि त्यातील फक्त एकामध्ये डायल करणारी व्यक्ती सहभागी असते। IPsec टनेलचे टोक सिद्ध करते, L2TP नियंत्रण कनेक्शन स्वतःच्या गुप्ततेने समवेतांना पुन्हा सिद्ध करू शकते, आणि नंतर PPP सत्रातील वापरकर्ता खाते सिद्ध करते। कोणत्याही टप्प्यातील अयशस्वीता क्लायंट संवादात सामान्य लॉगिन त्रुटीसारखी दिसते आणि सर्व्हर लॉगमध्ये पूर्णपणे वेगळी दिसते। टप्पे क्रमाने पूर्ण करा आणि पहिल्या अयशस्वी टप्प्यावर थांबा, कारण न तपासलेल्या टप्प्याखालील प्रत्येक टप्पाही न तपासलेला असतो।

तीन प्रमाणीकरण टप्पे, तीन वेगळ्या ओळखी

IPsec पूर्व-सामायिक किल्ली किंवा प्रमाणपत्र वापरून टोके कोणाची आहेत हे सिद्ध करते। ती ओळख यंत्रे किंवा गेटवेची असते, कीबोर्डसमोरच्या माणसाची कधीही नाही। या टप्प्यावर समवेत एकमत होऊ शकत नाहीत तेव्हा एकही L2TP पॅकेटची देवाणघेवाण होत नाही।

L2TP नियंत्रण कनेक्शन दुसरी, स्वतंत्र आव्हान-प्रतिसाद देवाणघेवाण जोडू शकते, जी दोन्ही टोकांकडे असावी लागणाऱ्या सामायिक गुप्ततेने चालवली जाते।

RFC 2661 त्या नियंत्रण कनेक्शन प्रमाणीकरणाला ऐच्छिक बनवते, ज्यामुळे तीच चूक दोन सर्व्हरवर वेगळी लक्षणे का निर्माण करते हे स्पष्ट होते। ज्या तैनातीने कधीही टनेल गुप्तता सेट केली नाही ती टप्पा पूर्णपणे वगळते; जिने फक्त एका बाजूला सेट केली ती PPP देऊ केले जाण्यापूर्वीच अयशस्वी होते। नंतर PPP वापरकर्त्याचे PAP, CHAP किंवा MSCHAPv2 ने प्रमाणीकरण करते आणि नाव स्थानिक, chap-secrets किंवा RADIUS वरील असू शकणाऱ्या खाते साठ्याकडे सोपवते। त्या क्षणी चुकीचा पासवर्ड तरीही तुम्हाला कार्यरत टनेल आणि अयशस्वी सत्रासह सोडतो।

कॉन्फिग संपादित करण्यापूर्वी थांबण्याचे ठिकाण वाचा

स्टेटस आउटपुट strongSwan चे आहे की Libreswan चे हे कळण्यासाठी ipsec --version ने सुरुवात करा। नंतर क्लायंट संवाद नाही तर सर्व्हर लॉग वाचा, कारण कोणत्या टप्प्याने नकार दिला हे सर्व्हर नोंदवते।

सहसा एक ओळ तिकीट ठरवते: 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 आणि मार्ग अद्याप तपासलेले नाहीत, आणि प्रत्येक स्वतःच्या पद्धतीने शांतपणे अयशस्वी होते। तुमच्या टिपांमध्ये तीन स्तर वेगळे ठेवा: योग्य किल्ली आणि चुकीचे खाते नेहमी अयशस्वी होते, आणि एक स्तर दुरुस्त केल्याने दुसरा कधीही दुरुस्त होत नाही।