किल स्विच फक्त 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 एंडपॉइंटपर्यंतचा बूटस्ट्रॅप मार्ग पोहोचण्यायोग्य राहण्याची गरज असू शकते, आणि ते अपवाद धोरणात नाव देऊन नमूद केले पाहिजेत, काही बिघाडाच्या वेळी शोधण्याऐवजी। टनेल परत येऊ शकत नाही म्हणून अपयशी होणारी गळती चाचणी सुरक्षा निष्कर्ष नाही, तो कनेक्टिव्हिटी निष्कर्ष आहे।