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 अपयश मार्ग अपयश मानले जाणार नाही।

टप्पा, पद्धत आणि पत्ता एका टिपात लिहा आणि तारीख टाका। तेच खाते एका महिन्यानंतर पुन्हा अयशस्वी झाल्यास, ती टीप पाच मिनिटांची तपासणी आणि नवीन तपास यातील फरक आहे। वेगवेगळ्या टप्प्यांतील अपयश वेगवेगळ्या घटना आहेत, क्लायंट एकच संवाद दाखवत असला तरी।