OpenVPN मार्ग मेट्रिक: छानिएको मार्ग किन अझै हार्छ

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

पहिले प्रोफाइल, त्यसपछि स्थापित तालिका, र अन्तमा चयन नियमहरू हेर्नुहोस्। त्यो क्रम क्लाइन्टले मार्ग कसरी बनाउँछ भन्नेसँग मेल खान्छ र तुलनामा कहिल्यै नपर्ने मान मिलाउनबाट रोक्छ।

मार्गको लाइनलाई फिल्ड क्रममा पढ्नुहोस्

Community OpenVPN 2.6 क्लाइन्टले IPv4 route लाइनमा चार फिल्ड स्वीकार्छ: नेटवर्क, नेटमास्क, गेटवे र वैकल्पिक मेट्रिक। गेटवेको ठाउँमा विशेष vpn_gateway किवर्ड राखिन्छ। यसको अर्थ यो जडानका लागि VPN पक्षको अर्को हप हो, राउटिङ तालिकाको नम्बर होइन र तपाईंको भौतिक राउटर पनि होइन। यो चुक्यो भने लाइनको बाँकी भागले यसले के गर्छ भन्ने गलत धारणासहित पढिन्छ। network-options सन्दर्भ ले चारै फिल्डको वर्णन गर्छ।

निजी गन्तव्यका लागि लाइन यस्तो हुन सक्छ:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

स्पष्ट 30 त्यो मार्गमा लागू हुन्छ, र 50 प्रोफाइलमा सङ्ख्या छोडिएका अन्य सबै मार्गका लागि पूर्वनिर्धारित रहन्छ। लाइनलाई बायाँबाट दायाँ पढ्नु कुन मान कहाँ लागू हुन्छ भन्न पर्याप्त हुन्छ।

route-metric पूर्वनिर्धारित हो, श्रेणी होइन

route-metric आफ्नै सङ्ख्या नभएका मार्गका लागि वैकल्पिक मान तोक्छ। यसले मार्गलाई अरू कुनै कुराभन्दा माथि धकेल्दैन, र स्पष्ट मेट्रिकसहित स्थापित मार्गहरूको क्रम फेर्दैन।

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

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

क्लाइन्टले के स्थापना गर्यो जाँच्नुहोस्

पुनः जडान पूरा भएपछि प्रोफाइललाई होइन, कर्नेललाई सोध्नुहोस्।

ip route show ले क्लाइन्टले थपेका मार्ग सूचीबद्ध गर्छ, र ip route get 172.20.5.10 ले अझ उपयोगी प्रश्नको उत्तर दिन्छ: यो गन्तव्यले वास्तवमा कुन मार्ग कुन स्रोत ठेगानासहित प्रयोग गर्छ। गन्तव्य तालिकामा छैन भने क्लाइन्टले त्यो स्थापना गरेको छैन।

स्थानीय निर्देशना, सर्भर पुश वा अर्को नेटवर्क व्यवस्थापक ले त्यही प्रिफिक्स थप्न वा हटाउन सक्छ, र अन्तिममा लेख्ने जित्छ। काम गर्दा अन्त्य बिन्दुको मार्गलाई ध्यानमा राख्नुहोस्, किनकि जडानलाई यसले बनाइरहेको टनेलबाट नजाने टाढाको सर्भरसम्मको बाटो चाहिन्छ।

सानो मेट्रिक किन अझै हार्छ

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

त्यही तर्क कुनै पनि ओभरल्यापिङ जोडीमा लागू हुन्छ। भित्रको ठेगानाका लागि /24 ले /16 लाई हराउँछ, सङ्ख्या जे भए पनि, किनकि खोजीले पहिले सबैभन्दा विशिष्ट मिलान छान्छ र त्यसपछि मात्र समानहरूबीच मेट्रिक तुलना गर्छ।

यो मेट्रिक बगजस्तो देखिने तर नभएको भाग हो। कुनै पनि सङ्ख्या बदल्नुअघि दुवै उम्मेदवारको प्रिफिक्स लम्बाइ जाँच्नुहोस्।

नीति नियमहरू तालिकाभन्दा पहिले चल्छन्

Linux मा ip rule ले कुन राउटिङ तालिका हेर्ने निर्णय गर्छ। नियमहरू प्राथमिकता क्रममा मूल्याङ्कन गरिन्छन्, त्यसैले अघिल्लो तालिकाले मुख्य तालिका पढ्नुअघि नै मार्ग फर्काउन सक्छ। मुख्यभित्रको मेट्रिकले पहिले हेरिएको तालिकाको मिलानलाई उछिन्न सक्दैन।

ip rule show प्रयोग गरी त्यसपछि विशिष्ट तालिका सोध्नुहोस्, उदाहरणका लागि ip route show table 100, त्यो नियमले के फर्काउँछ हेर्न। VPN क्लाइन्ट वा कन्टेनर रनटाइमले नियम थपेको भए उत्तर तपाईं पढिरहेको तालिकामा नभई त्यहाँ हुन सक्छ। स्रोत ठेगाना पनि महत्त्वपूर्ण छ, किनकि नियम स्रोतसँग मिलेर एउटै गन्तव्यलाई टनेल ट्राफिक र LAN ट्राफिकका लागि फरक रूपमा समाधान गर्न सक्छ।

गन्तव्य जाँच्नुहोस्, श्रेणी होइन

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

IPv6 र DNS लाई यो जाँचबाट बाहिर राख्नुहोस्। ती फरक निर्देशनले कन्फिगर गरिन्छन् र फरक संयन्त्रले समाधान गरिन्छन्, र चल्ने IPv4 मार्गले तिनका बारेमा केही पनि भन्दैन। एकपटकमा एउटा तह बदल्नुहोस् र प्रश्न पुनः चलाउनुहोस्।