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 उत्तर एक दिशा में मार्ग सिद्ध करता है और सेवा के बारे में कुछ नहीं, और कैश किए गए कनेक्शन पर उत्तर देने वाली सेवा और भी कम सिद्ध करती है।

फिर दोबारा कनेक्ट के बाद पूरी जाँच दोहराएँ। क्रम का मूल्य यह है कि वह अनुमान लगाता है कि अगला कनेक्ट क्या करेगा, इसलिए तुलना और मीट्रिक दोनों टिकट में आते हैं।