किल स्विच केवल IPv4 ब्लॉक करता है: IPv6 फिर भी क्यों निकल जाता है

टनल गिर जाती है, किल स्विच बताता है कि उसने काम किया, और डाउनलोड चलता रहता है। IPv4 नियमों में कुछ भी टूटा नहीं है। ऐप बस ऐसे रास्ते पर चला गया जिसके लिए वे नियम कभी लिखे ही नहीं गए थे।

डुअल-स्टैक डिवाइस के बाहर निकलने के दो स्वतंत्र रास्ते होते हैं। उनमें से एक पर ब्लॉक आधा ब्लॉक है।

दो नियम-सेट, दो डिफ़ॉल्ट

Linux पर, iptables और ip6tables अलग-अलग नीतियों वाली अलग-अलग तालिकाएँ हैं। IPv4 तालिका की INPUT और OUTPUT श्रृंखलाओं को DROP पर सेट करने से IPv6 तालिका में कुछ नहीं बदलता, जहाँ डिफ़ॉल्ट आमतौर पर ACCEPT होता है। यही विभाजन nftables में भी मौजूद है, जहाँ आप एक फ़ैमिली की जाँच कर सकते हैं और पा सकते हैं कि केवल एक ही आपके नियम ले जाती है। यह असमानता सामान्य है, और पूरी समस्या यही है।

इसीलिए एक किल स्विच पूरी तरह सावधान दिख सकता है और आंशिक रूप से व्यवहार कर सकता है। जिस स्क्रिप्ट ने IPv4 नियम लिखे वह चली, काउंटर बढ़ रहे हैं, लॉग पंक्ति दिखाई देती है, और एक IPv6 पैकेट भौतिक इंटरफ़ेस से पूरी तरह अछूता निकल जाता है।

पढ़ें कि आपका क्लाइंट वास्तव में क्या इंस्टॉल करता है, न कि मार्केटिंग पेज क्या वादा करता है। कुछ क्लाइंट IPv6 को टनल में भेजते हैं, कुछ उसे जानबूझकर ब्लॉक करते हैं, और कुछ उसे यूँ ही छोड़ देते हैं जबकि प्लेटफ़ॉर्म-स्तरीय लॉकडाउन कोई दूसरा नियम लागू करता है। यहाँ विक्रेता का दस्तावेज़ ही एकमात्र भरोसेमंद स्रोत है।

इंटरफ़ेस कॉन्फ़िगरेशन आपको क्या बताता है

wg-quick का मैनुअल पेज अपने उदाहरण कॉन्फ़िगरेशन में IPv6 नियम शामिल करता है, और कारण ठीक यही अंतराल है। उदाहरण सजावट नहीं है। यह इसलिए मौजूद है क्योंकि केवल IPv4 नियम दूसरी फ़ैमिली को खुला छोड़ देते।

उदाहरण का आधा कॉपी करने से आधी नीति बनती है। यही इस लीक का सबसे आम स्रोत है। एक ब्लॉग पोस्ट ने लंबाई के कारण उदाहरण को छोटा किया। फिर छोटा किया गया संस्करण वह टेम्पलेट बन गया जिसे सबने दोबारा इस्तेमाल किया।

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

अगर दूसरा कमांड अनुमति देने वाली नीति छापता है जबकि पहला DROP छापता है, तो आपने क्लाइंट को छुए बिना जवाब ढूँढ लिया है। यही असमानता बग है।

एक लुकअप पूरी कहानी क्यों नहीं है

एक नाम एक साथ A रिकॉर्ड और AAAA रिकॉर्ड दोनों लौटा सकता है, और सभी ऐप एक तरह से नहीं चुनते। नेटवर्क IPv6 देता है तो ब्राउज़र उसे पसंद कर सकता है और विफलता पर वापस आ सकता है, जबकि बैकग्राउंड सिंक या अपडेटर अपना रिज़ॉल्वर और अपनी प्राथमिकता इस्तेमाल करता है। इसलिए IPv4 पर एक सफल परीक्षण एक रास्ता साबित करता है, नीति नहीं।

नेटवर्क बदलाव भी जवाब बदलते हैं। दूसरे Wi-Fi नेटवर्क से जुड़ना, नींद से जागना या मोबाइल पर जाना डिवाइस को नया IPv6 प्रीफ़िक्स दे सकता है, और ऑफ़िस LAN पर पर्याप्त दिखने वाली नीति उसे कवर न करे।

टनल के बंद होने की स्थिति का परीक्षण करें

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

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

दोनों फ़ैमिली को बंद होकर विफल होना चाहिए। अगर IPv4 अनुरोध का समय समाप्त हो जाए और IPv6 अनुरोध स्टेटस कोड लौटाए, तो नीति अधूरी है, और टनल का कितना भी पुनः परीक्षण इसे नहीं बदलेगा।

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