क्‍या साझा pppd विकल्प फ़ाइल आपका दूसरा VPN तोड़ देती है?

आप एक ज़िद्दी PPTP प्रोफ़ाइल को कनेक्ट कराने के लिए एक पंक्ति जोड़ते हैं, और एक हफ़्ते बाद वह L2TP क्लाइंट काम करना बंद कर देता है जो महीनों से चल रहा था। सतही निष्कर्ष यही निकलता है कि अब दोनों प्रोटोकॉल आपस में टकरा रहे हैं। अधिकतर मामलों में दोनों क्लाइंट pppd शुरू करते हैं, दोनों एक ही डिफ़ॉल्ट पढ़ते हैं, और आपने जो पंक्ति जोड़ी वह उस प्रोफ़ाइल तक सीमित ही नहीं थी जिसे आप ठीक कर रहे थे। साझा विकल्प फ़ाइल ही असली जोड़ है, और प्रोटोकॉल निर्दोष हैं।

क्लाइंट शुरू होते समय क्या विरासत में लेता है

PPP-आधारित क्लाइंट शायद ही अपनी कमांड लाइन शून्य से बनाता है। यह pppd शुरू करता है, जो पहले सिस्टम डिफ़ॉल्ट पढ़ता है, फिर कोई यूज़र या टर्मिनल फ़ाइल, फिर क्लाइंट द्वारा दिए गए आर्ग्युमेंट, और क्लाइंट उसे किसी peer फ़ाइल की ओर भी इंगित कर सकता है। इनमें से हर परत कोई plugin, प्रमाणीकरण विधि या route निर्देश ले जा सकती है, और जो पहली परत किसी संरक्षित विकल्प को सेट कर देती है वह उसे बाद के बदलावों के विरुद्ध लॉक कर सकती है।

इसलिए उपयोगी प्रश्न यह नहीं है कि कौन-सा VPN टूटा है, बल्कि यह है कि वह सेटिंग किस परत से आई। जो क्लाइंट अपने आर्ग्युमेंट खुद बनाता है वह स्वयंपूर्ण दिखता है, फिर भी सिस्टम फ़ाइल में मौजूद सब कुछ विरासत में ले लेता है।

बदलने से पहले पंक्ति का स्रोत तय करें

शुरुआत उस प्रोसेस को देखकर करें जो कनेक्शन चालू रहने के दौरान चल रहा है। कमांड लाइन दिखाती है कि कौन-सी फ़ाइलें स्पष्ट रूप से दी गई थीं, और जो वहाँ नामित नहीं हैं वे डिफ़ॉल्ट पथ से आई हैं।

ps -o pid=,args= -C pppd

अगर आर्ग्युमेंट सूची में कोई peer नाम है तो उस फ़ाइल को पढ़ें। अगर नहीं है, तो जिस सेटिंग का आप पीछा कर रहे हैं वह किसी साझा पथ में रहती है। pppd मैनुअल में वह क्रम दिया है जिसमें ये फ़ाइलें पढ़ी जाती हैं और यह भी कि कौन-से विकल्प एक सामान्य यूज़र ओवरराइड नहीं कर सकता; इसी कारण बाद की कोई पंक्ति कभी-कभी कुछ भी नहीं करती। plugin पथ जैसे संरक्षित विकल्प को बाद की यूज़र-स्तरीय पंक्ति से बदला नहीं जा सकता, इसलिए गलत फ़ाइल संपादित करने का कोई दिखाई देने वाला असर नहीं होता।

हर क्लाइंट के पीछे चलने वाली plugin पंक्ति

सिस्टम फ़ाइल में लोड किया गया plugin सबसे बड़ा दोषी है, क्योंकि वह बदल देता है कि नया PPP प्रोसेस क्या लोड करने की कोशिश करेगा, चाहे यूज़र ने कोई भी बटन दबाया हो। L2TP plugin इसका उत्कृष्ट उदाहरण है: एक प्रोफ़ाइल के लिए सही, पर उन्हीं डिफ़ॉल्ट से शुरू होने वाले PPTP प्रोफ़ाइल के लिए निरर्थक या हानिकारक।

इसे उस peer फ़ाइल में ले जाएँ जिसे क्लाइंट चुनता है, या जब क्लाइंट समर्थन देता है तो उसकी अपनी प्रति-कनेक्शन सेटिंग्स में। इसे पूरी तरह हटा देना दूसरे क्लाइंट को ठीक करके पहले को तोड़ देता है, और इन समस्याओं का सफ़र टीमों के बीच इसी तरह होता है।

स्थानांतरण के बाद हर क्लाइंट जाँचें

दोनों कनेक्शन एक ही मशीन से, एक के बाद एक, जाँचें और सफलता के डायलॉग के बजाय वार्ता में तय हुए विकल्प पढ़ें। नीचे दिया dump वह विकल्प-समूह छापता है जो pppd ने वास्तव में जोड़ा, और वही एकमात्र सूची है जो मायने रखती है।

sudo pppd call office debug dump

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