क्या VPN रूट कैश आपका बदलाव छिपा रहा है? तीन चीज़ें जाँचें

बदलाव लागू न होने पर रूट कैश साफ़ करना पहली प्रवृत्ति है, और आधुनिक लिनक्स पर यह व्यर्थ श्रम है: वैश्विक IPv4 रूट कैश वर्षों पहले हटा दिया गया था, इसलिए ip route show cache कुछ भी नहीं छापता और साफ़ करने को कुछ नहीं है। जो स्थिति आपको धोखा देती है वह एक परत ऊपर रहती है: किसी सॉकेट, NAT मैपिंग, रिज़ॉल्वर या नेटवर्क मैनेजर में जिसने पुरानी प्रोफ़ाइल फिर से लागू की है। तीन प्रश्न उन मामलों को अलग करते हैं: गलत रास्ता नए प्रवाह से आ रहा है या पुराने कनेक्शन से, आपका प्लेटफ़ॉर्म रूट कैश रखता है या नहीं, और स्थिति रूटिंग में है या उसके ऊपर। इंटरफ़ेस रीसेट करने से पहले इनका उत्तर दें।

जाँच एक: पुराना रास्ता नए प्रवाह से आ रहा है?

स्थापित कनेक्शन उसी रूट को बनाए रखता है जिसके साथ वह बना था। इसीलिए टनल पर चलने वाला SSH सत्र रूटिंग तालिका के बदलाव से बच जाता है जबकि नया सत्र तुरंत नया रास्ता ले लेता है, और इसीलिए «बदलाव ने कुछ नहीं किया» का अर्थ अक्सर «पुराना सॉकेट अब भी उसे थामे हुए है» होता है। नई प्रक्रिया से परीक्षण करें, उस विंडो से नहीं जो पहले से खुली है।

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

अंतिम कमांड वह पता छापता है जिस तक नया कनेक्शन वास्तव में पहुँचा, और स्टेटस विंडो पर भरोसा किए बिना असली रास्ता देखने का यह सबसे सस्ता तरीका है। इसकी तुलना उस स्रोत पते से करें जिसे namespace या इंटरफ़ेस को उपयोग करना था।

अगर नया प्रवाह सही रास्ता लेता है और पुराना ठीक नहीं होता, तो रूटिंग देखना बंद कर दें। रूट सही था; सत्र पुराना था।

जाँच दो: क्या आपका प्लेटफ़ॉर्म रूट कैश रखता भी है?

लिनक्स पर उत्तर नहीं है, उस अर्थ में जो अधिकांश मार्गदर्शिकाएँ कहती हैं। फेंकने के लिए कोई वैश्विक गंतव्य कैश नहीं है, और चुना गया रूट रखने वाली प्रति-सॉकेट प्रविष्टि सॉकेट के साथ मुक्त हो जाती है। ip-route मैनुअल का कैश खंड ऐतिहासिक व्यवहार बताता है, ऐसा कुछ नहीं जिसे आप मौजूदा कर्नेल पर साफ़ कर सकें।

अन्य प्लेटफ़ॉर्म अलग हैं, और सलाह की नकल यहीं गड़बड़ाती है। Windows एक गंतव्य कैश रखता है जिसे आप netsh interface ip delete destinationcache से साफ़ कर सकते हैं। BSD और macOS route -n get के ज़रिए प्रति-गंतव्य खोज दिखाते हैं, और उनके कैश अपने समय-सारणी के अनुसार समाप्त होते हैं। इनमें से किसी एक पर काम करने वाला कमांड लिनक्स पर कुछ भी नहीं करता, इसलिए वही उपाय आज़माने वाले आधे लोगों को यह विफल दिखता है।

NAT या conntrack तालिका रूट कैश नहीं है, हालाँकि वह वही लक्षण पैदा करती है। आपके बदलाव से पहले अनुवादित प्रवाह अपना अनुवाद बनाए रखता है, और रूटिंग नीति आगे बढ़ जाने के बाद भी conntrack -L उसे दिखाता रहेगा। वह पुरानी स्थिति है, लेकिन रूट साफ़ करना उसे नहीं छुएगा।

जाँच तीन: स्थिति रूटिंग में है या उसके ऊपर?

कुछ और पढ़ने से पहले मौजूदा लुकअप पढ़ें: गंतव्य के लिए ip route get, फिर from और स्रोत पते के साथ वही कमांड, फिर ip rule show। अगर ये तीन आपके इरादे से मेल खाते हैं, तो रूटिंग ठीक करने की परत नहीं है, और पुराना अवलोकन कहीं और से आया है।

तीन आम संदिग्ध रूटिंग के ऊपर बैठते हैं। नेटवर्क मैनेजर आपके रूट हटाने के कुछ सेकंड बाद ही सहेजी प्रोफ़ाइल से उसे फिर से स्थापित कर सकता है, इसलिए आपका बदलाव लौटता हुआ लगता है; तालिका फिर से संपादित करने से पहले nmcli connection show --active और यूनिट की स्थिति देखें। रिज़ॉल्वर कैश पुराना पता लौटाता है, जो कैश तोड़ने वाले उपकरण से वही नाम पूछने तक रूटिंग विफलता जैसा दिखता है। किसी एप्लिकेशन का कनेक्शन पूल पुराने गंतव्य के साथ काम करने वाला सॉकेट रखता है और कर्नेल से कभी नया निर्णय नहीं माँगता।

तीन उत्तर आपको क्या निष्कर्ष निकालने देते हैं

उत्तरों को साथ रखें और मरम्मत अक्सर खुद बयान कर देती है। रूट कैश न रखने वाले प्लेटफ़ॉर्म पर नए प्रवाह का गलत रास्ता लेना इस बात का अर्थ है कि नीति वास्तव में गलत है, इसलिए वे नियम और वह तालिका पढ़ें जो टनल ने स्थापित की है। पुराने सत्र के अटकने के दौरान नए प्रवाह का सही रास्ता लेना इस बात का अर्थ है कि समस्या एप्लिकेशन या सॉकेट है। दोनों ही मामलों में सही रूट के साथ टूटा अवलोकन इस बात का अर्थ है कि स्थिति रूटिंग के ऊपर है।

सामान्य रिफ़्रेश का विरोध करें। नेटवर्क स्टैक को फिर से शुरू करना या जिस मशीन का डिफ़ॉल्ट रूट टनल है उस पर हर रूट हटाना ठीक उसी कनेक्शन को काट सकता है जिससे आप उसे ठीक कर रहे हैं, और यह उस सबूत को नष्ट करता है जो बताता कि कौन-सी परत विफल हुई।

अगर सचमुच कुछ साफ़ करना हो, तो निदान से मेल खाती सबसे छोटी चीज़ साफ़ करें: एक प्रक्रिया के सॉकेट, एक conntrack प्रविष्टि, रिज़ॉल्वर कैश। फिर वही नए-प्रवाह परीक्षण दोहराएँ और लिखें कि क्या बदला।

अपने नोट्स में तीनों स्थितियाँ अलग रखें

सहेजी कॉन्फ़िगरेशन, मौजूदा लुकअप और देखा गया प्रवाह तीन अलग तथ्य हैं, और उन्हें «कैश» में मिला देना ही दोष को दोबारा पैदा करना कठिन बनाता है। रूट का मालिक प्रोफ़ाइल या यूनिट, ip route get का आउटपुट, और वास्तविक कनेक्शन का स्रोत और गंतव्य लिखें।

उनके आगे प्लेटफ़ॉर्म और क्लाइंट संस्करण लिखें, क्योंकि Windows का गंतव्य कैश साफ़ करने वाला उपाय लिनक्स होस्ट पर लागू उपाय नहीं है, और दोनों के बीच नकल की गई प्रक्रिया गलत सबक सिखाती है। जब आप समस्या किसी और को सौंपें, तो वे तीन पंक्तियाँ उसे अनुमान लगाने के बजाय विफल स्थिति दोबारा बनाने देती हैं।