दो परीक्षण पृष्ठ आपस में नहीं मिलते: एक टनल से प्रदाता का पता बताता है, दूसरा आपका घरेलू प्रीफ़िक्स बताता है, और स्पष्ट निष्कर्ष यह है कि 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 टनल सब कुछ ढक लेती है, तब यही उद्धृत करने का संदर्भ है।

संबंधित लेख