ppp0 या ppp1? स्क्रिप्ट के लिए PPP VPN सत्र का नामकरण

हुक स्क्रिप्ट चलती है, ppp0 पढ़ती है और उस समय वह नाम रखने वाले किसी भी इंटरफ़ेस पर रूट लागू करती है। कभी वह वही टनल होती है जो आपका इरादा था; कभी वह एक मिनट पहले जुड़ा कोई सत्र होता है। अगला पुनःकनेक्शन संख्या को खिसका देता है, और वही स्क्रिप्ट चुपचाप गलत लिंक कॉन्फ़िगर कर देती है। समाधान यह है कि इंटरफ़ेस उसी कॉल से लें जो अभी चली, और इच्छित प्रोफ़ाइल को उसके साथ रखें।

विकल्पों से हुक तक एक सत्र का पीछा करें

वहीं से शुरू करें जहाँ सत्र बनता है। xl2tpd उस टनल के pppoptfile द्वारा नामित विकल्प फ़ाइल के साथ pppd शुरू करता है, इसलिए प्लगइन, यूनिट संख्या और कोई भी प्रोफ़ाइल मार्कर वहीं तय होते हैं, किसी वैश्विक फ़ाइल में नहीं। कोई कनेक्शन मैनेजर अपने स्वयं के विकल्प बना सकता है, यानी /etc/ppp/options संपादित करना इस बात का प्रमाण नहीं है कि आपकी चिंता वाली टनल बदली है। जब लिंक ऊपर आता है, pppd डिस्ट्रिब्यूशन के डिस्पैचर से सूचना स्क्रिप्ट चलाता है। वे स्क्रिप्ट इंटरफ़ेस का नाम पहले आर्ग्युमेंट के रूप में और प्रोफ़ाइल मार्कर छठे आर्ग्युमेंट के रूप में प्राप्त करती हैं।

परिवेश वही तथ्य IFNAME और PPP_IPPARAM जैसे नामों के अंतर्गत रखता है, लेकिन उनकी उपलब्धता स्थापित डिस्पैचर पर निर्भर करती है। किसी चर पर भरोसा करने से पहले डिस्पैचर पढ़ें: कुछ डिस्ट्रिब्यूशन अपस्ट्रीम आर्ग्युमेंट क्रम रखते हैं, अन्य आपकी स्क्रिप्ट बुलाने से पहले परिवेश फ़िल्टर करते हैं। केवल $1 और छठा आर्ग्युमेंट इस्तेमाल करने वाली स्क्रिप्ट दोनों व्यवस्थाओं में काम करती है।

कॉल से इंटरफ़ेस पढ़ें

पारंपरिक हुक इंटरफ़ेस पहले प्राप्त करता है। वह स्थितिगत मान वही इंटरफ़ेस पहचानकर्ता है जो उस सत्र का वर्णन करता है जिसने स्क्रिप्ट चलाई। इसे ऊपर एक चर में सहेजें, फिर उसी चर का उपयोग रूट, फ़ायरवॉल नियमों और टियरडाउन के लिए करें।

ipparam office-vpn

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

नाम केवल तब माँगें जब इनकार सही हो

स्थिर नाम आर्ग्युमेंट पढ़ने से आसान लगता है, लेकिन यह विफलता का व्यवहार बदल देता है। unit विकल्प बाहर जाने वाले कनेक्शन के लिए संख्या माँगता है, और जब वह यूनिट पहले से व्यस्त हो तो pppd गतिशील आवंटन पर लौट जाता है। उस परिणाम में कुछ भी आपकी प्रोफ़ाइल के लिए ppp0 आरक्षित नहीं करता।

ifname ppp-office

ifname विकल्प अलग व्यवहार करता है: यदि माँगा गया नाम पहले से उपयोग में है या आवंटित नहीं किया जा सकता, तो pppd दूसरा चुनने के बजाय बाहर निकल जाता है। यह नीति का चुनाव है, कोई सौंदर्यपरक नामांतरण नहीं। इसका उपयोग तब करें जब एक ही प्रोफ़ाइल का दूसरा समवर्ती उदाहरण अस्वीकार किया जाना चाहिए, और पुष्टि करें कि स्थापित pppd और आपका कनेक्शन मैनेजर विकल्प को आगे भेजते हैं।

किसी भी तरह, स्क्रिप्ट जो नाम देखती है वही काम करने योग्य है। कॉन्फ़िगर किया गया नाम कॉल पढ़ने की आवश्यकता नहीं हटाता, क्योंकि पुनः आरंभ किया गया सत्र पिछले से भिन्न नाम प्रस्तुत कर सकता है।

टियरडाउन को अपने कॉन्फ़िगर किए सत्र से मिलाएँ

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

वह स्थिति जाँचें जो बग उजागर करती है: पहला अभी जुड़ा रहते हुए दूसरा PPP सत्र ऊपर लाएँ, फिर पहले को दोबारा जोड़ें और देखें कि हुक कौन-सा इंटरफ़ेस बताता है। एक सत्र के साथ सफल रन नाम आवंटन के बारे में कुछ भी सिद्ध नहीं करता। VPN बंद रखकर दोहराएँ ताकि पुष्टि हो कि टियरडाउन कोई पुराना रूट नहीं छोड़ता।

मार्कर, इंटरफ़ेस और हुक का पथ डिप्लॉयमेंट नोट्स में रखें। रीबूट के बाद संख्या बदलने पर वे तीन मान बताते हैं कि बिना किसी कॉन्फ़िगरेशन संपादन के स्क्रिप्ट ने अलग व्यवहार क्यों किया।