तपाईं एक लाइन थप्नुहुन्छ ताकि जिद्दी PPTP प्रोफाइल जोडियोस्, र एक हप्तापछि महिनौंदेखि चलेको L2TP क्लाइन्ट रोकिन्छ। स्पष्ट व्याख्या यो हो कि दुई प्रोटोकल अहिले ठोक्किन्छन्। प्रायः दुवै क्लाइन्टले pppd सुरु गर्छन्, दुवैले एउटै पूर्वनिर्धारित मान पढ्छन्, र तपाईंले थपेको लाइन कहिल्यै तपाईंले सुधारिरहेको प्रोफाइलमा सीमित थिएन। साझा विकल्प फाइल नै त्यो जोडाइ हो, र प्रोटोकलहरू निर्दोष छन्।

क्लाइन्ट सुरु हुँदा के उत्तराधिकारमा पाउँछ

PPP आधारित क्लाइन्टले आफ्नो कमाण्ड लाइन शून्यबाट विरलै बनाउँछ। यसले pppd सुरु गर्छ, जसले प्रणालीका पूर्वनिर्धारित मान, त्यसपछि कुनै पनि प्रयोगकर्ता वा टर्मिनल फाइल, त्यसपछि क्लाइन्टले पठाउने आर्गुमेन्टहरू पढ्छ, र क्लाइन्टले यसलाई सहकर्मी फाइलतर्फ पनि निर्देशित गर्न सक्छ। ती प्रत्येक तहले प्लगइन, प्रमाणीकरण विधि वा मार्ग निर्देशिका बोक्न सक्छ, र संरक्षित विकल्प सेट गर्ने पहिलो तहले यसलाई पछिल्ला परिवर्तनहरूबाट लक गर्न सक्छ।

त्यसैले उपयोगी प्रश्न कुन VPN बिग्रिएको छ भन्ने होइन, तर कुन तहले सेटिङ दियो भन्ने हो। आफ्नै आर्गुमेन्ट उत्पन्न गर्ने क्लाइन्ट आत्मनिर्भर देखिन्छ र तैपनि प्रणाली फाइलमा भएको सबै उत्तराधिकारमा पाउँछ।

परिवर्तन गर्नुअघि लाइनको उत्पत्ति पत्ता लगाउनुहोस्

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

ps -o pid=,args= -C pppd

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

हरेक क्लाइन्टपछि आउने प्लगइन लाइन

प्रणाली फाइलमा लोड गरिएको प्लगइन सबैभन्दा नराम्रो दोषी हो किनभने प्रयोगकर्ताले कुन बटन थिच्यो भन्ने पर्वाह नगरी नयाँ PPP प्रक्रियाले के लोड गर्न खोज्छ भन्ने कुरा यसले बदल्छ। L2TP प्लगइन उत्कृष्ट उदाहरण हो: एउटा प्रोफाइलका लागि सही, त्यही पूर्वनिर्धारितबाट सुरु हुने PPTP प्रोफाइलका लागि अर्थहीन वा हानिकारक।

यसलाई क्लाइन्टले छान्ने सहकर्मी फाइलमा, वा क्लाइन्टले समर्थन गर्छ भने उसको आफ्नै प्रति-जडान सेटिङमा सार्नुहोस्। यसलाई पूर्ण रूपमा मेटाउँदा दोस्रो क्लाइन्ट सुध्रिन्छ र पहिलो बिग्रिन्छ, र यी समस्या टोलीहरूबीच यसैगरी यात्रा गर्छन्।

सारेपछि हरेक क्लाइन्ट जाँच्नुहोस्

दुवै जडान एउटै मेसिनबाट एकपछि अर्को गरी परीक्षण गर्नुहोस्, र सफलताको संवादको सट्टा वार्ता गरिएका विकल्प पढ्नुहोस्। तलको डम्पले pppd ले वास्तवमै जम्मा गरेको विकल्प-समूह छाप्छ, र त्यही एउटै महत्त्वपूर्ण सूची हो।

sudo pppd call office debug dump

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

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