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

सीक्रेटको जाँच कहिल्यै किन हुँदैन

PPP प्रमाणीकरणमा वार्ता हुन्छ: सर्भरले विधिहरू प्रस्ताव गर्छ, क्लाइन्टले आफूले सक्ने कुराले जवाफ दिन्छ, र कुनै पनि प्रमाणपत्र साटासाट हुनुअघि दुवै एकमा सहमत हुन्छन्। जब सर्भरले मात्र EAP-PEAP दिन्छ र क्लाइन्टको pppd ले त्यो लागू गर्दैन, तब कुराकानी प्रस्तावको चरणमै सकिन्छ। सर्भरले प्रमाणीकरण असफलता अभिलेख गर्छ किनभने असफल भएको चरण त्यही हो, पासवर्ड तुलना गरेर अपर्याप्त भेटिएकोले होइन।

त्यसैले गलत पासवर्ड र विधिको अमिल्दोपन दुवैमा त्रुटि उस्तै हुन्छ। लगले मात्र तिनीहरूलाई छुट्याउँछ, र त्यो पनि क्लाइन्टलाई विस्तृत हुन अनुमति भएमा मात्र।

वार्ता पढ्नुहोस्, अन्तिम त्रुटि होइन

डिबगिङ खुला राखेर जडान अग्रभागमा चलाउनुहोस् र प्रमाणीकरणका लाइनहरू माथिबाट पढ्नुहोस्। लगले प्रस्ताव गरिएको विधि, स्वीकार गरिएको विधि र आदानप्रदान कहाँ रोकियो भन्ने बताउँछ। जुन प्रोफाइल CHAP वा MSCHAPv2 बाट कहिल्यै बाहिर निस्कँदैन जबकि सर्भरले PEAP अपेक्षा गर्छ, त्यो विधिको समस्या हो, प्रमाणपत्रको होइन। त्यो लगको अन्तिम लाइन क्लाइन्टले हार मानेको ठाउँ हो, कारण भएको ठाउँ होइन।

sudo pppd call provider debug nodetach

त्यो आउटपुट राख्नुहोस्। यो सर्भर नीति बदल्नुअघि नेटवर्क मालिकलाई चाहिने प्रमाण पनि हो, र पासवर्ड नै खेलमा थियो कि भन्ने प्रश्न पनि टुंग्याउँछ।

दोस्रो कारण सीक्रेट फाइलमा लुकेको छ

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

sudo cat -A /etc/ppp/chap-secrets

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

सर्भर कसको हो त्यसअनुसार सुधार छान्नुहोस्

सर्भर तपाईंको हो भने, त्यो खाताका लागि MSCHAPv2 लाई अनुमति दिनु सबैभन्दा सानो परिवर्तन हो, र तपाईंले जानाजानी कमजोर विधि स्वीकार गर्नुभयो भनी अभिलेख गर्नुपर्छ। यो अरू कसैको हो भने, EAP-PEAP लागू गर्ने क्लाइन्ट नै इमानदार सुधार हो; pppd लाई प्याच गर्दा अमिल्दोपन तपाईंको मर्मत समस्या बन्छ। प्रोटोकलको छनोट अझै खुला छ भने, PPTP डिजाइनको सबैभन्दा कमजोर भाग हो र प्याच गरिएको क्लाइन्ट जीवित राख्नुभन्दा स्थानान्तरण सामान्यतया सस्तो पर्छ। त्यो निर्णय प्रोफाइलको छेउमा लेख्नुहोस्, अर्को व्यक्तिले फेरि नखोलोस्।

तपाईंले जुनसुकै बाटो रोज्नुभए पनि, पछि अर्को नेटवर्कको दोस्रो मेसिनबाट परीक्षण गर्नुहोस्। सङ्ग्रहित प्रोफाइलले पुरानो विधि प्रस्ताव गरिरहन सक्छ र सुधारिएको सर्भर बिग्रिएको जस्तो देखिन सक्छ। त्यसपछि डिबग सेटिङ हटाउनुहोस्, किनभने विस्तृत PPP लगहरू साझा वर्कस्टेशनमा तपाईंले चाहेभन्दा बढी कैद गर्न सक्छन्।

सम्बन्धित लेखहरू