के 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 गन्तव्य क्यास सफा गर्ने उपाय लिनक्स होस्टमा लागू हुने उपाय होइन, र दुवैबीच प्रतिलिपि गरिएको प्रक्रियाले गलत पाठ सिकाउँछ। तपाईंले समस्या अरू कसैलाई दिँदा ती तीन लाइनले उसलाई अनुमान नगरी असफल अवस्था फेरि उत्पादन गर्न दिन्छ।