L2TP जुड़ता है पर PPP बातचीत विफल होती है: कौन सा चरण?

IPsec टनल बनती है, क्लाइंट एक सुरक्षित सहकर्मी दिखाता है, और फिर निजी सबनेट तक कुछ पहुँचने से पहले ही कनेक्शन मर जाता है। यह अंतराल PPP का अपना काम है: लिंक विकल्प, उपयोगकर्ता प्रमाणीकरण और पता आवंटन सब कुछ एन्क्रिप्टेड टनल बनने के बाद होते हैं। सफल पहले चरण के आदान-प्रदान से कोई पासवर्ड या आंतरिक पता नहीं मिलता। चरणों को क्रम से पढ़ें और विफलता सामान्यतः स्वयं का नाम बता देती है।

टनल केवल पहली परत है

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

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

जो अंतिम चरण सफल हुआ उसे पढ़ें

लॉग में आगे बढ़ें और पहले उस चरण पर रुकें जो पूरा नहीं हुआ। पहले LCP आता है, फिर प्रमाणीकरण, फिर IPv4 पैरामीटर के लिए IPCP।

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

LCP का समय समाप्त होना कहता है कि दोनों सिरे बुनियादी लिंक विकल्पों पर कभी सहमत नहीं हुए, जो खराब पासवर्ड नहीं बल्कि प्रोफ़ाइल का मेल न खाना या भीतरी प्रोटोकॉल का अवरुद्ध होना है। स्पष्ट प्रमाणीकरण अस्वीकृति उल्टा मामला है: लिंक ऊपर आया और एक पक्ष ने क्रेडेंशियल अस्वीकार कर दिए। सफल प्रमाणीकरण के बाद IPCP का समय समाप्त होना पता पूल या सर्वर नीति की ओर संकेत करता है। इनमें से हर एक का अलग स्वामी और अलग मरम्मत है, इसीलिए अंतिम त्रुटि पाठ से चरण अधिक मायने रखता है।

टिकट में चरण के नाम के साथ लॉग का अंश रखें। चरण की सीमा के बिना चिपकाई गई पूँछ अगले पाठक को अनुमान लगाने के लिए आमंत्रित करती है, और यहाँ अनुमान लगाने में एक घंटा लगता है।

क्लाइंट और सर्वर के बीच सहमति

दोनों सिरों को एक ही प्रमाणीकरण विधि स्वीकार करनी होती है, और सहेजी गई प्रोफ़ाइल ऐसी विधि मांग सकती है जिसे सर्वर ने पिछली तिमाही में हटा दिया था। प्रबंधित परिनियोजन सर्वर पक्ष को भी छिपाते हैं, जहाँ अस्वीकृति का कारण सामान्यतः डिवाइस के बजाय उपयोगकर्ता के नाम दर्ज होता है।

हर पुराने विकल्प के बजाय एक समर्थित विधि सक्षम करें, क्योंकि पाँच विधियाँ देने वाला क्लाइंट यह छिपा देता है कि कौन सी विफल हुई। व्यवस्थापक से सर्वर-पक्ष की नीति और सटीक अस्वीकृति मांगें, जिसके लिए किसी को पासवर्ड प्रकाशित करने की आवश्यकता नहीं है। एक क्लाइंट को बचाने के लिए सक्षम की गई पुरानी विधि फ़ाइल की नकल करने वाली हर प्रोफ़ाइल में फैल जाती है।

पता जाँचें, लॉगिन नहीं

पूरा हुआ लॉगिन उपयोगी सत्र नहीं है। IPCP आंतरिक पता तय करता है, और समाप्त पूल या क्लाइंट को अस्वीकार करने वाली नीति फिर भी जुड़ी हुई टनल को रूट करने के लिए कुछ भी बिना छोड़ सकती है।

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

पहले आंतरिक पता जाँचें, फिर उस संसाधन के लिए मार्ग और रिज़ॉल्वर जिसकी आपको वास्तव में आवश्यकता है। आंतरिक पता वह सार्वजनिक निकास नहीं है जिसकी सूचना कोई वेबसाइट देती है, और दोनों को मिला देना लोगों को ऐसे रिसाव की खोज में भेजता है जो है ही नहीं। निजी संसाधन को नाम से जाँचने से पहले पते से जाँचें, ताकि DNS विफलता को रूटिंग विफलता न समझा जाए।

चरण, विधि और पता एक नोट में लिखें और उस पर तारीख डालें। यदि वही खाता एक महीने बाद फिर विफल हो, तो वह नोट पाँच मिनट की जाँच और नई जाँच के बीच का अंतर है। अलग-अलग चरणों की विफलताएँ अलग घटनाएँ हैं, भले ही क्लाइंट एक ही संवाद दिखाए।