किल स्विचले 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 इन्डपोइन्टसम्मको बुटस्ट्र्याप मार्ग पहुँचयोग्य रहन आवश्यक हुन सक्छ, र ती अपवादहरू नीतिमा नाम राखेर उल्लेख गर्नुपर्छ, कुनै अवरोधको बेला पत्ता लगाउनुको सट्टा। टनेल फेरि माथि आउन नसकेको कारण असफल हुने चुहावट परीक्षण सुरक्षा निष्कर्ष होइन, त्यो कनेक्टिभिटी निष्कर्ष हो।