स्थानीय रुटले VPN को पूर्वनिर्धारित रुटलाई किन हराउँछ

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

जोडिएको प्रिफिक्स पूर्वनिर्धारित रुटभन्दा बढी विशिष्ट हुन्छ

टनेलले सामान्यतया पूर्वनिर्धारित रुट वा प्रिफिक्सको समूह राख्छ, जबकि स्थानीय इन्टरफेसले जोडिएको प्रिफिक्स र पूरै LAN का लागि रुट बोक्छ। तिनीहरूबीच सबैभन्दा लामो प्रिफिक्सको मिलानले निर्णय गर्छ, त्यसैले LAN प्रिफिक्सभित्रको गन्तव्य कहिल्यै टनेलसम्म पुग्दैन। त्यसैले प्रिन्टर, राउटरको प्रशासन पृष्ठ र स्थानीय NAS VPN चालु हुँदा पनि पहुँचयोग्य रहन्छन्। त्यसैले ओभरल्याप हुने दायराभित्रको टाढाको स्रोत गलत मेसिनमा जान्छ।

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

कर्नेलले गर्ने छनोट पढ्नुहोस्

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

ip route get 10.20.30.41
ip route show table all | grep -E '10\.|default'
ip rule show

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

स्थानीय पहुँच एउटा छुट्टै अनुमति हो

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

दुई तह फरक तरिकाले असफल हुन्छन्। रोकिएको स्थानीय बाटो रुट हुँदाहुँदै पनि समयसमाप्ति दिन्छ, जबकि ओभरल्याप हुने रुटले गलत होस्टबाट जवाफ दिन्छ। तिनलाई छुट्याउन एउटा प्रश्न मात्र लाग्छ र फायरवाल परिवर्तनको एक दिन बच्छ, र फरवार्डिङ व्यवस्था strongSwan का फरवार्डिङ नोटहरू मा वर्णन गरिएको छ।

होस्ट रुटको थुप्रो नलगाई ओभरल्याप सुधार्नुहोस्

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

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