ppp0 कि ppp1? स्क्रिप्टका लागि PPP VPN सत्रको नामकरण
pppd ले हरेक सत्रलाई इन्टरफेस नाम र प्रोफाइल मार्कर दिन्छ। दुवै हुकबाट पढ्नुहोस्, ppp0 बाट होइन। स्थिर नाम तब मात्र आरक्षित गर्नुहोस् जब अस्वीकार जानाजानी हो।
हुक स्क्रिप्ट चल्छ, ppp0 पढ्छ र त्यो क्षणमा त्यो नाम भएको जुनसुकै इन्टरफेसमा मार्गहरू लागू गर्छ। कहिले त्यो तपाईंले चाहेको टनेल हुन्छ; कहिले एक मिनेट अघि जोडिएको सत्र हुन्छ। अर्को पुनःजडानले नम्बर सार्छ, र त्यही स्क्रिप्टले चुपचाप गलत लिङ्क कन्फिगर गर्छ। समाधान भनेको भर्खरै चलेको कलबाट इन्टरफेस लिनु र इच्छित प्रोफाइल त्यसैसँग लैजानु हो।
विकल्पबाट हुकसम्म एउटा सत्र पछ्याउनुहोस्
सत्र सिर्जना हुने ठाउँबाट सुरु गर्नुहोस्। xl2tpd त्यो टनेलको pppoptfile ले नाम दिएको विकल्प फाइलसँग pppd सुरु गर्छ, त्यसैले प्लगइन, युनिट नम्बर र कुनै पनि प्रोफाइल मार्कर विश्वव्यापी फाइलमा होइन, त्यहीँ तय हुन्छ। कनेक्सन म्यानेजरले आफ्नै विकल्पहरू उत्पन्न गर्न सक्छ, अर्थात् /etc/ppp/options सम्पादन गर्नु तपाईंलाई चासो भएको टनेल बदलियो भन्ने प्रमाण होइन। लिङ्क माथि आएपछि pppd वितरणको डिस्प्याचरबाट सूचना स्क्रिप्टहरू चलाउँछ। ती स्क्रिप्टहरूले इन्टरफेसको नाम पहिलो आर्गुमेन्टका रूपमा र प्रोफाइल मार्कर छैटौंका रूपमा प्राप्त गर्छन्।
वातावरणले त्यही तथ्यहरू IFNAME र PPP_IPPARAM जस्ता नाममा बोक्छ, तर तिनको उपलब्धता स्थापित डिस्प्याचरमा निर्भर गर्छ। चलमा भर पर्नुअघि डिस्प्याचर पढ्नुहोस्: केही वितरणहरूले upstream आर्गुमेन्ट क्रम राख्छन्, अरूले तपाईंको स्क्रिप्ट बोलाउनुअघि वातावरण फिल्टर गर्छन्। केवल $1 र छैटौं आर्गुमेन्ट प्रयोग गर्ने स्क्रिप्ट दुवै अवस्थामा चल्छ।
कलबाट इन्टरफेस पढ्नुहोस्
परम्परागत हुकले इन्टरफेस पहिले प्राप्त गर्छ। त्यो स्थान मान भनेको स्क्रिप्ट चलाउने सत्र वर्णन गर्ने इन्टरफेस पहिचानकर्ता हो। यसलाई माथि एउटा चलमा राख्नुहोस्, त्यसपछि त्यही चल मार्ग, फायरवाल नियम र टियरडाउनका लागि प्रयोग गर्नुहोस्।
ipparam office-vpn
विकल्पहरू परिभाषित हुने ठाउँमा प्रोफाइल मार्कर जोड्नुहोस्, स्क्रिप्टमा होइन। टनेलको विकल्प फाइलमा त्यो लाइन भएमा त्यो फाइलबाट बन्ने हरेक सत्रले छैटौं आर्गुमेन्टका रूपमा office-vpn बोक्छ। स्क्रिप्टले मार्करअनुसार शाखा बनाउन सक्छ र वास्तविक इन्टरफेसमा कार्य गर्न सक्छ। कोडमा दुवैलाई अलग राख्नुहोस्, किनकि मार्कर स्थिर छ र इन्टरफेस हरेक सत्रका लागि बाँडिन्छ।
अस्वीकार सही हुँदा मात्र नाम माग्नुहोस्
स्थिर नाम आर्गुमेन्ट पढ्नुभन्दा सरल देखिन्छ, तर यसले असफलताको व्यवहार बदल्छ। unit विकल्पले बाहिर जाने कनेक्सनका लागि नम्बर माग्छ, र त्यो युनिट पहिले नै व्यस्त भएमा pppd गतिशील बाँडफाँटमा फर्कन्छ। त्यो नतिजामा केहीले पनि तपाईंको प्रोफाइलका लागि ppp0 आरक्षित गर्दैन।
ifname ppp-office
ifname विकल्प फरक व्यवहार गर्छ: मागिएको नाम पहिले नै प्रयोगमा छ वा तोक्न सकिँदैन भने pppd अर्को छान्नुको सट्टा बाहिरिन्छ। त्यो नीतिको छनोट हो, देखावटी नाम परिवर्तन होइन। एउटै प्रोफाइलको दोस्रो समकालीन प्रतिलाई अस्वीकार गर्नुपर्दा यो प्रयोग गर्नुहोस्, र स्थापित pppd र तपाईंको कनेक्सन म्यानेजरले विकल्प पास गर्छन् भनी पुष्टि गर्नुहोस्।
जे भए पनि, स्क्रिप्टले देख्ने नाम नै कार्य गर्नुपर्ने नाम हो। कन्फिगर गरिएको नामले कल पढ्ने आवश्यकता हटाउँदैन, किनकि पुनः सुरु गरिएको सत्रले अघिल्लोभन्दा फरक नाम प्रस्तुत गर्न सक्छ।
टियरडाउनलाई तपाईंले कन्फिगर गरेको सत्रसँग मिलाउनुहोस्
मार्ग र फायरवाल नियमहरू तिनीहरू बनाउने स्क्रिप्टभन्दा लामो बाँच्छन्, त्यसैले टियरडाउनले सत्रको स्वामित्वमा भएका वस्तुहरू ठ्याक्कै हटाउनुपर्छ। नियमहरूलाई इन्टरफेससँगै प्रोफाइल मार्करले पनि ट्याग गर्नुहोस्, र त्यही ट्यागले मेट्नुहोस्। दुई टनेल एकैसाथ माथि हुन सक्छन् भने ppp उल्लेख गर्ने सबै मेट्नु भनेको एउटा विच्छेदले अर्को कनेक्सन तोड्ने तरिका हो।
बग उजागर गर्ने अवस्था परीक्षण गर्नुहोस्: पहिलो अझै जोडिएको बेला दोस्रो PPP सत्र माथि ल्याउनुहोस्, त्यसपछि पहिलो पुनः जोड्नुहोस् र हुकले कुन इन्टरफेस रिपोर्ट गर्छ हेर्नुहोस्। एउटा सत्रसँग सफल चालले नाम बाँडफाँटबारे केही पनि प्रमाणित गर्दैन। VPN रोकिएको अवस्थामा दोहोर्याउनुहोस्, टियरडाउनले पुरानो मार्ग छोड्दैन भनी पुष्टि गर्न।
मार्कर, इन्टरफेस र हुकको बाटो परिनियोजन टिप्पणीमा राख्नुहोस्। रिबुटपछि नम्बर बदलिँदा ती तीन मानहरूले कुनै कन्फिगरेसन सम्पादनबिना स्क्रिप्टले फरक व्यवहार किन गर्यो भन्ने व्याख्या गर्छन्।