Linux मा VPN ले धकेलेका रुट र स्थिर रुटबीच कसरी फरक गर्ने
टनेलसँगै देखिने प्रिफिक्स तीन स्रोतबाट आउन सक्छ। तालिका तुलना गर्नुहोस्, मेट्रिक जाँच्नुहोस् र त्यसपछि यसलाई बारम्बार पुनः स्थापना गर्ने स्रोत ठीक गर्नुहोस्।
टनेल माथि आउँदा ल्यापटपमा प्रिफिक्स देखिन्छ, त्यसैले VPN ले स्थापना गरेको जस्तो लाग्छ। त्यसो हुन सक्छ, तर त्यही नतिजा कनेक्टको समयमा चल्ने क्लाइन्ट स्क्रिप्ट, सबनेट सूचीबद्ध गर्ने कनेक्सन प्रोफाइल, वा सुरुदेखि नै भएको र इन्टरफेस अस्तित्वमा आएपछि मात्र काम गर्न थालेको स्थिर रुटबाट पनि आउन सक्छ। गलत स्रोत रोज्नु भनेको प्रत्येक सफाइपछि रुट फर्किन्छ र अर्को व्यक्तिले त्यही सुधार दोहोर्याउँछ। तलको क्रमले केही बदल्नु अघि यी तीनलाई छुट्याउँछ।
चरण 1: प्रिफिक्स स्थापना गर्ने संयन्त्रको नाम दिनुहोस्
विभिन्न प्रोटोकलले फरक-फरक तरिकाले पहुँच प्रदान गर्छन्, र यी सबैलाई घोषणा भन्नुले भिन्नता लुकाउँछ। OpenVPN सर्भरले नियन्त्रण च्यानलमा रुट निर्देशन धकेल्छ र pull फिल्टरले रोकेन भने क्लाइन्टले त्यो स्थापना गर्छ। WireGuard कन्फिगरेसनले अनुमति दिइएका प्रिफिक्सहरू स्थानीय रूपमा सूचीबद्ध गर्छ, जुन क्लाइन्टले क्रिप्टो-की रुटिङ र आफूले थप्ने रुट दुवैका लागि प्रयोग गर्छ। IPsec टनेलले साथीसँग ट्राफिक चयनकर्ताहरूमा सहमति गर्छ, र कर्नेलले ती चयनकर्ताबाट रुट स्थापना गर्छ।
कुनै पनि तालिका पढ्नु अघि तपाईंको टनेलले यीमध्ये कुन प्रयोग गर्छ पहिचान गर्नुहोस्। कनेक्टको समयमा धकेलिएको रुट रुटिङ प्रोटोकलको घोषणा होइन, र प्रिफिक्स टाढाको छेउपछि पुग्न सकिने वाचा पनि दिँदैन। सुधार कहाँ पर्छ भन्ने यसले निर्धारण गर्ने भएकाले प्रिफिक्सको छेउमा संयन्त्र लेख्नुहोस्।
चरण 2: एउटा कनेक्टभरि तालिका तुलना गर्नुहोस्
टनेल तल हुँदा मुख्य तालिका सुरक्षित गर्नुहोस्, माथि ल्याउनुहोस्, फेरि सुरक्षित गर्नुहोस् र दुई क्याप्चर तुलना गर्नुहोस्। देखा परेको सबै कनेक्सनको जीवनचक्रको हो, र बाँकी रहेको सबै स्थानीय कन्फिगरेसनको हो।
ip route show table main > /tmp/route-down.txt ले त्यो क्याप्चर गर्नुहोस्, कनेक्ट गर्नुहोस् र फेरि क्याप्चर गर्नुहोस्। साइटले IPv6 प्रयोग गर्छ भने ip -6 route का लागि पनि त्यही गर्नुहोस्, किनकि त्यहाँ नभएको प्रिफिक्सले रुटिङसँग सम्बन्ध नभएको देखिने खराबी उत्पन्न गर्छ।
चरण 3: उपस्थिति मात्र होइन, मेट्रिक पढ्नुहोस्
एउटै प्रिफिक्सका दुई प्रविष्टि सँगै रहन सक्छन्, र कर्नेलले कम मेट्रिक रोज्छ। मेट्रिक 50 भएको स्थिर रुट दुवै देखिए पनि 100 मा धकेलिएको रुटलाई जितिरहन्छ, त्यसैले ‘रुट त्यहाँ छ’ र ‘ट्राफिकले त्यो प्रयोग गर्छ’ फरक भनाइ हुन्।
ip route get 10.20.5.7 ले कर्नेललाई सिधै सोध्नुहोस् र यसले रिपोर्ट गर्ने इन्टरफेस पढ्नुहोस्। तालिकामा टनेलको रुट रहँदा ट्राफिक भौतिक एडाप्टरबाट बाहिर जान्छ भने त्यो मेट्रिक वा प्रिफिक्सको लम्बाइले व्याख्या गर्छ, VPN क्लाइन्टले होइन। टनेलपछि छ भन्ने थाहा भएको होस्ट र छैन भन्ने थाहा भएको होस्टका लागि खोज दोहोर्याउनुहोस्, र फरकले विभाजन उद्देश्यअनुसार चल्छ कि चल्दैन देखाउँछ।
चरण 4: टनेलभन्दा लामो बाँच्ने प्रविष्टि खोज्नुहोस्
स्थिर रुट डिजाइनअनुसार विच्छेदनबाट बाँच्छन्, र पुराना प्रविष्टि त्यहीँबाट आउँछन्। अब नभएको इन्टरफेसमा देखाउने स्थायी रुटले सबनेटलाई चुपचाप निल्न सक्छ, र पुनः प्रयोग भएको इन्टरफेस नाममा देखाउने रुटले रिबुटपछि निजी ट्राफिकलाई गलत ढोकाबाट पठाउन सक्छ।
तपाईंको वितरणले प्रयोग गर्ने ठाउँमा स्थायी पक्ष जाँच्नुहोस्, त्यो systemd-networkd इकाइ, NetworkManager प्रोफाइल वा क्लाइन्टको up डिरेक्टरीको स्क्रिप्ट हुन सक्छ। ip route del ले जीवित तालिका ठीक गर्नु अर्को कनेक्टसम्म मात्र टिक्छ। त्यो मेटाउने कामलाई मर्मत होइन, परिकल्पनाको परीक्षण मान्नुहोस्।
टाढाको छेउले गलत कभरेज दिन्छ भने सबै फिल्टर गर्नुको सट्टा अपरेटरसँग राख्नुहोस्। सबै धकेलिएका सेटिङ छोड्दा प्रोफाइल निर्भर रहेको DNS र विभाजित टनेल नीति पनि छोडिन्छ।
चरण 5: क्लाइन्टलाई दोष दिनु अघि फर्किने मार्ग पुष्टि गर्नुहोस्
साइट-टु-साइट वा टनेलपछिको सबनेटका लागि टाढाको पक्षलाई तपाईंको क्लाइन्ट ठेगानामा फर्किने रुट र गेटवेमा फर्वार्डिङ सक्रिय चाहिन्छ। एकतर्फी मार्ग क्लाइन्ट रुटिङ बगजस्तै देखिन्छ, तर ह्यान्डशेक र बाहिर जाने प्याकेट दुवै सफल हुन्छन्।
रिभर्स-पाथ फिल्टरिङले Linux गेटवेमा दोस्रो जाल थप्छ। रुटले अनुमान गरेभन्दा फरक इन्टरफेसमा आउने उत्तर कडा मोडमा खारेज हुन्छ, र दुई प्रदायकबाट जाने असममित मार्गले त्यो भरपर्दो रूपमा निम्त्याउँछ। फिल्टरिङ कारण हो कि होइन गेटवेमा, क्लाइन्टमा होइन, रहेका ड्रप काउन्टरले बताउँछन्।
चरण 6: ping होइन, स्रोत परीक्षण गर्नुहोस्
रोजिएको रुट सही भएपछि वास्तविक स्रोत खोल्नुहोस् र फर्किने ट्राफिक पुष्टि गर्नुहोस्। ping उत्तरले एक दिशामा मार्ग प्रमाणित गर्छ र सेवाबारे केही होइन, र क्यास गरिएको कनेक्सनमा उत्तर दिने सेवाले अझ कम प्रमाणित गर्छ।
त्यसपछि फेरि कनेक्ट गरेपछि पूरै जाँच दोहोर्याउनुहोस्। क्रमको मूल्य यो हो कि यसले अर्को कनेक्टले के गर्ने अनुमान गर्छ, त्यसैले तुलना र मेट्रिक दुवै टिकटमा पर्छन्।