गत महिना दुई जनाले मसँग विपरीत नतिजा मागे: एकले IPv6 VPN ले ढाकोस् भन्ने चाहन्थे, अर्कोले अफिसको प्रिन्टर चलिरहोस् भन्ने चाहन्थे। एउटै ::/0 मार्गले दुवै आफै दिन सक्दैन। त्यो मार्ग सुरुङभित्र पर्छ कि पर्दैन भन्ने तीन सर्तमा निर्भर छ, र पहिलो सर्तले धेरैजसो व्यावसायिक निकासका लागि यसलाई बाहिर राख्छ। निकासले IPv6 बोक्दैन भने डिफल्ट मार्ग त्यहाँ पठाउँदा तपाईंको ट्राफिक पठाउने ठाउँ नभएको सुरुङमा लुक्छ।

तीन सर्तले उत्तर निर्धारण गर्छन्

डिफल्ट मार्ग एक लाइन हो, ::/0, र यो अझ विशिष्ट मार्ग नभएको कुनै पनि IPv6 गन्तव्यसँग मिल्छ (RFC 4291)। यसलाई स्थापना गर्न सजिलो छ। यो गर्नुपर्छ कि भन्ने निर्णय तीन सर्तमा आउँछ।

पहिलो सर्त: तपाईं जोडिने निकासमा चल्ने IPv6 छ र त्यो यसलाई अगाडि पठाउन तयार छ। दोस्रो सर्त: तपाईंको क्लाइन्टले सुरुङको अन्तिम बिन्दुसम्म मार्ग राख्न सक्छ, जो सामान्यतया तपाईंले मार्गनिर्देशन गर्न लागेको दायराभित्र हुन्छ। तेस्रो सर्त: सुरुङबाहिर रहनुपर्ने स्थानीय IPv6 गन्तव्यहरू तपाईंले नाम लिएर भन्न सक्नुहुन्छ।

हरेक सर्त आ-आफ्नै तरिकाले असफल हुन्छ, त्यसैले अनुमान गर्दा पूरै साँझ जान्छ। असफल पहिलो सर्तले तपाईंलाई मौनता र सही देखिने मार्ग तालिका दिन्छ। असफल दोस्रो सर्तले सुरु भएको केही सेकेन्डमै ह्यान्डसेक मार्छ। असफल तेस्रो सर्तले चलिरहेको सुरुङ र प्रिन्टरनजिक असन्तुष्ट सहकर्मी छोड्छ।

What you seeDecision
Exit answers IPv6 probes, no local IPv6 devices to protectRoute ::/0 into the tunnel
Exit answers IPv6 probes, printer or NAS reachable by a global addressRoute ::/0, then give those prefixes a route of their own
Exit is IPv4-only inside the tunnelDo not route ::/0; block IPv6 on the client
Endpoint is reached over IPv6 and sits inside ::/0Install a host route for the endpoint first

के निकासले साँच्चै IPv6 बोक्छ?

IPv6 ठेगाना भएको सुरुङ इन्टरफेस अर्को पट्टिको बारेमा केही प्रमाणित गर्दैन। धेरै व्यावसायिक प्रोफाइल भित्रबाट मात्र IPv4 हुन्: सर्भरले तपाईंलाई v4 ठेगाना दिन्छ र बाँकी सबै फाल्छ। त्यसको माथि AllowedIPs बाट डिफल्ट मार्ग राख्नुहोस् र कर्नेलले खुसीसाथ IPv6 त्यस्तो इन्टरफेसमा पठाउँछ जसको साथीले त्यो कहिल्यै देख्दैन।

सुरुङ चालु हुँदा क्लाइन्टबाट जाँच्नुहोस्। ping -6 -c 3 2001:4860:4860::8888 र ip -6 route get 2001:4860:4860::8888 फरक प्रश्नको उत्तर दिन्छन्: जवाफ फर्कन्छ कि फर्कँदैन, र कर्नेलले कुन यन्त्र छान्यो। जब दोस्रोले तपाईंको सुरुङको नाम लिन्छ र पहिलोले केही फर्काउँदैन, समस्या मार्गमा होइन, निकासमा छ।

तपाईं आफै निकास चलाउनुहुन्छ भने क्लाइन्ट परीक्षण उत्तीर्ण हुन सक्छ र बाटो तैपनि बन्द गल्लीमा टुंगिन सक्छ। गेटवेमा net.ipv6.conf.all.forwarding=1 सक्रिय छ र त्यसको फायरवालले सुरुङबाट अगाडि पठाइएका प्याकेट स्वीकार्छ भनी पुष्टि गर्नुहोस्। अगाडि पठाउन इन्कार गर्ने निकासमा सही रूपमा मार्गनिर्देशित प्याकेट क्लाइन्टको तर्फबाट ठ्याक्कै मार्गनिर्देशन बगजस्तै देखिन्छ।

के क्लाइन्टले अन्तिम बिन्दुसम्मको मार्ग राख्न सक्छ?

यही त्यो घटना हो जसले मलाई मात्र IPv6 WireGuard अन्तिम बिन्दु भएको ल्यापटपमा समात्यो। अन्तिम बिन्दुको ठेगाना सामान्य विश्वव्यापी ठेगाना हो, त्यसैले यो ::/0 भित्र पर्छ। पूरै प्रिफिक्स इन्टरफेसमा मार्गनिर्देशन गर्नुहोस् र ह्यान्डसेक प्याकेटहरू आफैलाई अझै बनाउन खोजिरहेको सुरुङभित्र खेदाउनेछन्। सुरुङ कहिल्यै उठ्दैन, र क्लाइन्टको आउटपुटमा किन हो भनेर केही भन्दैन।

wg-quick लिनक्समा यसलाई सम्हाल्छ। यसले AllowedIPs बाट मार्गहरू निकाल्छ, तिनलाई आफ्नै तालिकामा राख्छ, र अन्तिम बिन्दुतर्फको ट्राफिक पहिले मुख्य तालिकाबाट समाधान होस् भनी नीति नियम थप्छ: suppress_prefixlength 0 नियम, जो ip -6 rule मा भेटिन्छ। त्यसैले wg-quick up हातले लेखिएको ip -6 route add default dev wg0 ले तपाईंलाई काट्ने ठाउँमा सफल हुन्छ।

सुरुङ उठाउनुअघि र पछि, दुवै अवस्था ip -6 route get <endpoint-v6> ले जाँच्नुहोस्। उत्तर तपाईंको सुरुङ यन्त्रतिर बदलियो भने, सुरुङलाई चाहिने बाटो तपाईंले हटाउनुभयो। मार्गहरू आफै लेख्दा, मूल गेटवेबाट अन्तिम बिन्दुसम्म होस्ट मार्ग थप्नुहोस्, वा IPv4 बाट अन्तिम बिन्दुमा जोडिनुहोस् र IPv6 पेलोडमा छोड्नुहोस्।

सुरुङबाहिर के रहनुपर्छ?

अझ विशिष्ट मार्गहरूले डिफल्टलाई हराउँछन्, त्यसैले लिङ्कमा भएको प्रिफिक्स वा आफ्नै मार्ग भएको ULA दायरा थप मेहनतबिना चलिरहन्छ। यही धेरै पूर्ण सुरुङ IPv4 सेटअप टिकिरहने शान्त कारण हो: LAN प्रिफिक्सहरू डिफल्टभन्दा बढी विशिष्ट छन् र कहिल्यै सुरुङमा पस्दैनन्।

स्थानीय यन्त्र विश्वव्यापी ठेगानाबाट पहुँचयोग्य हुँदा यो भाँचिन्छ, जो एउटै राउटरले सार्वजनिक प्रिफिक्स दिएको प्रिन्टर, NAS वा टेलिभिजनका लागि सामान्य हो। ती ठेगानाहरू ::/0 सँग मात्र मिल्छन्, अरू कसैसँग मिल्दैनन्, त्यसैले ती बाँकी सबैसँगै सुरुङमा सर्छन् र हराउँछन्।

प्रोटोकलअनुसार होइन, गन्तव्यअनुसार निर्णय गर्नुहोस्। दुई वा तीन स्थानीय होस्ट महत्त्वपूर्ण छन् भने तिनका प्रिफिक्सलाई भौतिक इन्टरफेसबाट बाहिर जाने मार्ग दिनुहोस्, वा वार्ताभएको समूहबाट हटाउनुहोस्। सूची बढिरहन्छ भने इमानदार उत्तर लिखित अपवाद सूचीसहित IPv6 का लागि स्प्लिट टनेलिङ हो, तपाईंले लगातार प्याच गरिरहने डिफल्ट होइन।

उत्तर होइन भए, यसलाई रोक्नुहोस्

IPv6 लाई मार्गबिना छोड्नु यसलाई एक्लै छोड्नुजस्तो होइन। चल्ने IPv6 डिफल्ट भएको होस्टले सुरुङले IPv4 बोकिरहेको बेला पनि यसको प्रयोग गरिरहन्छ, त्यसैले ट्राफिक VPN को छेउबाट बाहिरिन्छ र IPv6 लाई प्राथमिकता दिने हरेक सेवाले तपाईंको वास्तविक ठेगाना देख्छ। त्यो चुहावट हो, स्प्लिट सुरुङ होइन।

एउटा छान्नुहोस् र कुन छान्नुभयो लेख्नुहोस्। डिफल्ट मार्गनिर्देशन गर्नुहोस् र माथिका सम्झौता स्वीकार्नुहोस्, वा सुरुङ रहेसम्म IPv6 अक्षम गर्नुहोस्। AllowedIPs बाट प्रिफिक्स छोड्नु मात्र पर्याप्त हुँदैन, किनकि अपरेटिङ सिस्टमले आफ्नै डिफल्ट राख्छ। लिनक्समा ठूलो संस्करण sysctl -w net.ipv6.conf.all.disable_ipv6=1 हो; सूक्ष्म संस्करणले फायरवाल नियमद्वारा IPv6 लाई सुरुङबाहिर फ्याँक्छ। फोन क्लाइन्टमा त्यही काम गर्ने स्पष्ट IPv6 रोक्ने टगल हुन्छ।

चुहावटजस्तै प्रमाणित गर्नुहोस्

सुरुङ उठाउनुहोस् र टगलमा भरोसा गर्नुको सट्टा अवस्था पढ्नुहोस्। ip -6 route show default ले एउटा डिफल्ट देखाउनुपर्छ, र तपाईंको LAN बाहिरको गन्तव्यका लागि ip -6 route get ले सुरुङ यन्त्रको नाम लिनुपर्छ। डिस्कनेक्टपछि दुवै दोहोर्याउनुहोस्: सुरुङभन्दा लामो टिक्ने डिफल्ट नै तपाईंले खोजिरहनुभएको बग हो।

त्यसपछि विपरीत दिशा जाँच्नुहोस्। स्थानीय सञ्जालको होस्टबाट क्लाइन्टलाई उसको स्थानीय IPv6 ठेगानामा पुग्नुहोस्। त्यो चल्न छोड्यो भने, त्यतिबेला मार्ग तालिकाले जे भने पनि, तेस्रो सर्त कहिल्यै पूरा भएको थिएन।

नतिजा त्यहाँ लेख्नुहोस् जहाँ अर्को व्यक्तिले भेट्नेछ: कुन प्रिफिक्स स्थानीय रहन्छन्, किन, र डिस्कनेक्टपछि क्लाइन्ट के गर्छ। runbook मा दुई लाइनले अर्को इन्जिनियरलाई मध्यरातमा अन्तिम बिन्दु लूप फेरि पत्ता लगाउनबाट बचाउँछ।

सम्बन्धित लेखहरू