टनेल जोडिन्छ, त्यसपछि पहुँच लिंकमा लिज नवीकरणले यसलाई मार्छ, र लगले मार्गलाई होइन, समय समाप्तिलाई दोष दिन्छ। VPN कन्फिगरेसनमा केही बदलिएको छैन, र यही संकेत हो: यसको बाहिर केही बदलियो। DHCP घटनाले ठेगाना वा गेटवे पुनः लेख्यो, र टनेलको इन्डपोइन्ट पुग्नयोग्य राख्ने होस्ट मार्ग अब अस्तित्वमा नभएको अर्को हपतर्फ संकेत गर्छ। यो राउटिङ समस्या हुनुअघि स्वामित्वको समस्या हो।

लक्षणलाई आधा-पूर्वनिर्धारित मार्गसँग तुलना गर्नुहोस्

redirect-gateway def1 सहित, OpenVPN पूर्वनिर्धारित मार्ग प्रतिस्थापन गर्नुको सट्टा 0.0.0.0/1 र 128.0.0.0/1 स्थापना गर्छ। दुवै मिलेर सम्पूर्ण ठेगाना ठाउँ ढाक्छन्, र तिनीहरू प्रिफिक्स लम्बाइले मात्र 0.0.0.0/0 लाई हराउँछन्। त्यसैले अझ विशिष्ट मिलान बिनाको कुनै पनि गन्तव्य टनेलमा प्रवेश गर्छ।

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

अरू केही छुनुअघि तालिकाको आकार पुष्टि गर्नुहोस्। ip route show ले दुवै आधा र सर्भर ठेगानाका लागि होस्ट मार्ग सूचीबद्ध गर्नुपर्छ; होस्ट मार्ग नभएमा बाँकी अनुसन्धानसँग स्पष्ट सुरुवात बिन्दु हुन्छ।

मेट्रिक नबदली आधा-पूर्वनिर्धारित किन जित्छन्

कम मेट्रिकले लामो प्रिफिक्सलाई हराउँदैन। /1 मार्गहरू जित्छन् किनभने कर्नेलले पहिले सबैभन्दा विशिष्ट मार्ग मिलाउँछ, त्यसैले पूर्वनिर्धारित मार्गमा मेट्रिक बढाउँदा टनेलतर्फ जाने ट्राफिक कहाँ जान्छ भन्नेमा केही बदलिँदैन। मेट्रिकको पछि दौडिनु यो निदानमा सबैभन्दा सामान्य गलत मोड हो।

ip route get 203.0.113.10 प्रयोग गरेर चयन जाँच्नुहोस्, यसमा सर्भरको वास्तविक ठेगाना राखेर। उत्तरले कर्नेलले वास्तवमै प्रयोग गर्ने इन्टरफेस र अर्को हप बताउँछ, र त्यो तालिका पढेर त्यसमाथि सोच्नुभन्दा बढी जानकारीपूर्ण हुन्छ।

त्यो आदेश टनेल सुरु हुनुअघि, चलिरहेको बेला, र लिज घटनापछि चलाउनुहोस्। एउटै आदेशबाट तीन उत्तर, र विचलन बिन्दु देखिन थाल्छ।

एउटा होइन, तीन स्न्यापसट लिनुहोस्

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

स्न्यापसटहरू समयछापसहित एउटै फाइलमा राख्नुहोस्, किनभने पछिको रोचक प्रश्न क्रम हो। DHCP घटना OpenVPN ले आफ्नो मार्ग ताजा गर्नुअघि आयो कि पछि? उत्तरले यो कसले सुधार्नुपर्छ भन्ने निर्धारण गर्छ। गलत घडीको समयछाप नहुनुभन्दा नराम्रो हुन्छ, त्यसैले राउटिङ तालिका भएको होस्टबाट लिनुहोस्।

जब इन्डपोइन्ट ठेगानाको सट्टा नामको रूपमा कन्फिगर गरिएको छ, प्रत्येक स्न्यापसटमा यसलाई पनि समाधान गर्नुहोस्। पहुँच लिंकमा DNS परिवर्तनले कुनै पनि मार्ग नछोइकन इन्डपोइन्ट सार्न सक्छ।

कुन घटकले अपवाद ताजा गर्छ निर्धारण गर्नुहोस्

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

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

मालिकलाई कन्फिगरेसनभित्र रेकर्ड गर्नुहोस्। पुनः जडान डिबग गर्ने अर्को व्यक्तिले अपवाद मार्गको जिम्मेवारी VPN होइन, हुक हो भन्ने जान्नुपर्छ।

पुनः जडान मात्र होइन, जीवनचक्र परीक्षण गर्नुहोस्

dhcpcd -n eth0 ले वा लिज छोडेर फेरि लिएर नवीकरण बाध्य गर्नुहोस्, त्यसपछि इन्डपोइन्टका लागि ip route get फेरि जाँच्नुहोस्। यो दुई पटक गर्नुहोस्, किनभने दोस्रो चरणले दोहोरो मार्ग थप्ने हुकहरू समात्छ। त्यसपछि रिबुट गर्नुहोस्, किनभने स्थायित्व शुद्धताभन्दा फरक गुण हो।

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

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