VPN लीक ठीक करने के लिए IPv6 बंद करें? बेहतर है नीति तय करें
लिंक-लोकल पता लीक नहीं है और वैश्विक IPv6 मार्ग भी नहीं। पहले ब्लॉक करने, ले जाने और अछूता छोड़ने में से चुनें।
IPv6 रेंज का एक पता टेस्ट पेज पर दिखता है, टनल स्पष्ट रूप से उसे नहीं ले जा रही, और इंटरनेट की सबसे लोकप्रिय सलाह है IPv6 को हर जगह बंद कर देना। वह कमांड पैनल को चुप ज़रूर कर देता है। यह उस प्रोटोकॉल को भी हटा देता है जिस पर एक्सेस नेटवर्क निर्भर हो सकता है, और यह आपको बिना किसी अंदाज़े के छोड़ देता है कि पता असली लीक था, लिंक-लोकल इंटरफ़ेस पता था, या कोई रिज़ॉल्वर अपना काम कर रहा था। सही नियंत्रण तीन शर्तें तय करती हैं, और उनमें से केवल एक ब्लॉक करने की ओर ले जाती है।
पहचानें कि उपकरण ने वास्तव में क्या मापा
सबसे आम झूठा अलार्म लिंक-लोकल पता है, जो fe80: से शुरू होता है और हर IPv6-सक्षम इंटरफ़ेस पर मौजूद रहता है, चाहे मशीन IPv6 से इंटरनेट तक पहुँचे या न पहुँचे। यह इंटरफ़ेस सूचियों और कुछ एप्लिकेशन निदानों में दिखता है, और आपके ट्रैफ़िक पथ के बारे में कुछ नहीं कहता।
दूसरा झूठा अलार्म fc00::/7 के भीतर एक अद्वितीय स्थानीय पता है, जो नेटवर्क के भीतर इस्तेमाल की जाने वाली निजी रेंज है। होस्ट के हर पते को छापने वाला उपकरण उसे सार्वजनिक पते के बगल में खुशी से सूचीबद्ध करेगा। जल्दी पढ़ने वाला कोई इसे लीक कहता है और फिर ऐसी समस्या पर एक घंटा बिताता है जो मौजूद ही नहीं है।
तीसरा कोई झूठा अलार्म नहीं है। टनल के बाहर इंटरनेट तक पहुँचने वाला वैश्विक पता ही असली लीक है, और कुछ भी तय करने से पहले उसे मापना उचित है:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coअगर पहला कमांड वैश्विक पता छापता है और तीसरा ऐसा सार्वजनिक IPv6 पता लौटाता है जो टनल का नहीं है, तो टनल के बाहर आपका असली मार्ग है। अगर पहला लिंक-लोकल प्रविष्टियों के अलावा कुछ नहीं छापता, तो ठीक करने के लिए कोई लीक कभी थी ही नहीं।
नियंत्रण तीन शर्तें तय करती हैं
निर्णय "IPv6 अच्छा" या "IPv6 बुरा" नहीं है। निर्णय यह है कि आप तीन स्थितियों में से किसमें हैं, और हर एक का सही उत्तर अलग है और गलती करने पर कीमत भी अलग है।
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
पहली पंक्ति वही है जो लोग आमतौर पर मतलब रखते हैं, और वह वाजिब है। जिस क्लाइंट के एग्ज़िट में IPv6 समर्थन नहीं है, उसे होस्ट का अपना IPv6 ट्रैफ़िक चुपचाप बाहर नहीं जाने देना चाहिए, क्योंकि वही प्रलेखित डुअल-स्टैक लीक है। मुद्दा इसे घोषित नीति के रूप में ब्लॉक करना है, कर्नेल में प्रोटोकॉल बंद करना नहीं। दिखने वाला परिणाम एक जैसा है और बाद में केवल एक ही जाँचा जा सकता है।
तीसरी पंक्ति वह जगह है जहाँ सामान्य सलाह सक्रिय रूप से हानिकारक हो जाती है। मोबाइल ऑपरेटर और कुछ घरेलू कनेक्शन IPv4 गंतव्यों के लिए अनुवाद के साथ IPv6-only नेटवर्क चलाते हैं। वहाँ IPv6 हटाइए और आप नेटवर्क द्वारा दी जाने वाली एकमात्र ट्रांसपोर्ट हटा देंगे, जो उस बाधा से कहीं बुरा आउटेज पैदा करता है जिसे आप डीबग कर रहे थे।
अगर एग्ज़िट में IPv6 नहीं है, तो जानबूझकर ब्लॉक करें
क्लाइंट की अपनी व्यवस्था को प्राथमिकता दें, क्योंकि वह ठीक तब लागू होती है जब टनल चालू हो और टनल गिरने पर वापस हट जाती है। OpenVPN के पास इसके लिए विकल्प है, और iptables के पास अन्य क्लाइंट के लिए समतुल्य नियम है:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableनिर्देश प्रोफ़ाइल में रहता है; नियम उस फ़ायरवॉल में रहता है जिसे आप देख और हटा सकते हैं। दोनों बंद रहकर विफल होते हैं, जो आप चाहते हैं, और दोनों कॉन्फ़िगरेशन डिफ़ में दिखते हैं, जो स्टार्टअप स्क्रिप्ट में दबा कर्नेल sysctl नहीं दिखता।
लिखिए कि वह क्यों है। बिना टिप्पणी वाला ब्लॉकिंग नियम अगला वह व्यक्ति हटा देता है जिसे IPv6 किसी असंबंधित काम के लिए चाहिए, और फिर लीक चुपचाप लौट आती है।
अगर एग्ज़िट IPv6 ले जाता है, तो उसे रूट करें और दोनों फ़ैमिली जाँचें
सर्वर समर्थन करे तो IPv6 ले जाना बेहतर उत्तर है, और यह बहुत कठिन नहीं है। शर्त यह है कि टनल इंटरफ़ेस के पास उस फ़ैमिली का पता हो और उसका डिफ़ॉल्ट मार्ग भौतिक इंटरफ़ेस से बाहर नहीं, टनल के भीतर जाए:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coमार्ग खोज ही निर्णायक परीक्षण है: अगर वह टनल इंटरफ़ेस का नाम लेता है, तो IPv6 ट्रैफ़िक ले जाया जा रहा है। फिर दो curl कॉल पुष्टि करते हैं कि हर फ़ैमिली क्या देखती है, और उनकी तुलना ही यह साबित करने का तरीका है कि दोनों पथ अब एक ही एग्ज़िट से निकलते हैं।
सफल कनेक्शन पर रुकिए नहीं। टनल फिर से जोड़ें और दोबारा जाँचें, क्योंकि सर्वर केवल आरंभिक कॉन्फ़िगरेशन में भेजे तो धकेला गया IPv6 मार्ग पुनःस्थापन पर खो सकता है। फिर एक बहिष्कृत गंतव्य जाँचें, क्योंकि स्प्लिट-टनल नियमों में ही दोनों फ़ैमिली सबसे अधिक मतभेद रखती हैं।
अगर एक्सेस नेटवर्क केवल IPv6 है, तो उसे अछूता छोड़ें
कुछ नेटवर्क केवल IPv6 देते हैं और अपेक्षा करते हैं कि डिवाइस ऑपरेटर की ओर अनुवाद व्यवस्था से IPv4 सेवाओं तक पहुँचेगा। ऐसी मशीन पर IPv6 बंद करना सुरक्षा सुधार नहीं है; यह किसी भी चीज़ तक का एकमात्र मार्ग हटा देता है। यह खुद पैदा किया गया आउटेज है, ऐसे टेस्ट नतीजे के लिए जो किसी को ज़रूरी नहीं था।
यहाँ गलती का लक्षण अलग और अप्रिय है: टनल बनती दिखती है, नाम विभेदन काम करता है, और कुछ भी लोड नहीं होता। IPv6 बदलाव के बाद ऐसा दिखे तो सेटिंग तुरंत बहाल करें और निदान कहीं और जारी रखें।
आप जो भी चुनें, निर्णय को प्रोफ़ाइल या फ़ायरवॉल में स्पष्ट रखें, उसे उससे बाँधें जिसका एग्ज़िट वास्तव में समर्थन करता है, और वह डुअल-स्टैक व्यवहार नोट करें जिसका वर्णन RFC 7359 की डुअल-स्टैक चर्चा करती है। घोषित ब्लॉक एक नीति है। बंद किया गया प्रोटोकॉल ऐसा उपाय है जिसका कोई अंकेक्षण नहीं कर सकता, और टेस्ट पेज से दोनों एक जैसे दिखते हैं।