VPN बाहिर जाने IPv6 ट्राफिक: चुहावट भएको मार्ग पत्ता लगाउनुहोस्

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

त्यही क्रममा काम गर्नुहोस्। क्रम नमिलाई जवाफ दिँदा क्लाइन्टमा दोष छ कि भन्ने लामो बहस हुन्छ, जबकि साँचो जवाफ यही हो कि IPv6 मार्ग कहिल्यै स्थापना भएन।

कुन प्रवाह साँच्चै बाहिर गयो, र कुन एडाप्टरमा

प्रयोग गरिएको परिवारको नाम दिने परीक्षणबाट सुरु गर्नुहोस्, त्यसपछि एप्लिकेसन, पहुँच नेटवर्क, चालु प्रोफाइल र जडानले IPv6 दिन्छ कि भन्ने लेख्नुहोस्। ती चार तथ्यले दुई रनलाई तुलनीय बनाउँछन्, र चौथो मानिसहरू बिर्सन्छन्: v6 प्रिफिक्स नभएको नेटवर्कले v6 चुहावट गर्न सक्दैन, र पछि एउटा थप्ने नेटवर्कले जवाफ बदल्छ।

पृष्ठ लोड गरेर त्यसको नतिजा पढ्नुको सट्टा हरेक परिवारका लागि एउटा अनुरोध पठाउनुहोस्। एउटै पृष्ठले v6 र v4 स्रोत मिसाउन सक्छ, पृष्ठभूमि प्रक्रियाले तपाईंको अगाडिको ट्याबभन्दा फरक व्यवहार गर्न सक्छ, र क्यास गरिएको जवाफले तपाईंले परीक्षण गर्न खोजेको नेटवर्क परिवर्तनभन्दा लामो समय टिक्न सक्छ। तपाईंले परीक्षण गर्ने गन्तव्य निश्चित गरी लेख्नुहोस्, ताकि दोहोरिएको रनले त्यही कुरा नापोस्।

कर्नेलले छानेको मार्ग पढ्ने

राउटिङ तालिकाले ब्राउजरले जवाफ दिन नसक्ने प्रश्नको जवाफ दिन्छ। कुनै निश्चित गन्तव्य कहाँ जान्छ भनी प्रणालीलाई सोध्नुहोस्, र देखिने डिफल्टसँगै नीति नियम पनि समावेश गर्नुहोस्, किनकि दुवैले त्यसलाई उल्लंघन गर्न सक्छन्:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

अझ विशिष्ट प्रिफिक्स भनेको एउटा गन्तव्य टनेलबाहिर रहने र बाँकी सबै भित्र रहने सामान्य कारण हो, र नीति नियमले कुनै पनि मार्गभन्दा उच्च प्राथमिकतामा त्यही गर्न सक्छ। मेट्रिक पनि पढ्नुहोस्, किनकि एउटै प्रिफिक्सका दुई प्रविष्टि स्क्रिनको क्रमले होइन, मेट्रिकले टुंगिन्छन्। Windows मा समान सूची Get-NetRoute -AddressFamily IPv6 हो, निर्णय क्रमसँग मिल्न मेट्रिक अनुसार क्रमबद्ध। तालिकामा सही देखिने नियम पनि कम नम्बरको नीति नियमसँग हार्न सक्छ, त्यसैले नियमको सूची मार्गको सूचीसँगै एउटै सासमा आउँछ।

क्लाइन्टको IPv6 नीति कहाँबाट आउँछ

क्लाइन्ट v6 टनेलबाट लैजान बनाउन सकिन्छ, त्यसलाई अस्वीकार गर्न, वा नामित अपवादलाई अनुमति दिन, र ती तीन इरादाले तीन फरक सही नतिजा दिन्छन्। अवलोकनलाई चुहावट भन्नुअघि प्रोफाइल र क्लाइन्टकै कागजात पढ्नुहोस्, किनकि अपरेटिङ सिस्टमले अझै भौतिक लिंकमा छिमेकी खोज पठाइरहँदा v6 अवरुद्ध गर्ने क्लाइन्ट डिजाइनअनुसारै व्यवहार गर्छ।

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

साँघुरो अवलोकन, जब तालिका असहमत हुन्छ

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

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

खाली ठाउँ बन्द गर्ने तीन तरिका

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

पुनः जडान भएपछि र नेटवर्कबीच सरेपछि जाँच दोहोर्याउनुहोस्, किनकि अघिल्लो लिंकका लागि स्थापित मार्ग परिवर्तनपछि पनि टिक्न सक्छ। त्यसपछि गन्तव्य, छानिएको मार्ग, क्लाइन्ट नीति र परीक्षणले प्रयोग गरेको परिवार लेख्नुहोस्, ताकि अर्को व्यक्तिले निर्णय फेरि निकाल्नुको सट्टा पढोस्।RFC 7359 ले दोहोरो-स्ट्याक चुहावटलाई बग होइन, डिजाइन समस्या रूपमा अभिलेख गर्छ, र काम गर्ने v4 टनेलले सबै ढाक्छ भनी कसैले दाबी गर्दा उद्धृत गर्नुपर्ने सन्दर्भ त्यही हो।