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 असफलता रुटिङ असफलता मानिन नपरोस्।

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