डुअल-स्टैक VPN: एड्रेस फ़ैमिली क्लाइंट चुनता है, आप नहीं

टनल चालू है, IPv4 साइटें लोड हो रही हैं, और एक होस्टनेम का समय समाप्त हो रहा है। तुरंत निष्कर्ष यह निकलता है कि VPN खराब है या क्रेडेंशियल ग़लत हैं, और आमतौर पर दोनों में से कोई सच नहीं होता। नाम ने IPv4 और IPv6 दोनों पते लौटाए, ऐप्लिकेशन ने एक चुना, और उन उम्मीदवारों में से केवल एक के पास काम करने वाला रास्ता था। चुनाव का फ़ैसला क्लाइंट ने लिया; टनल बस वह कवर नहीं कर रही थी जो उसने चुना था।

चुनाव कवरेज का वादा नहीं है

RFC 6724 में वर्णित डिफ़ॉल्ट एड्रेस चयन तय करता है कि कई उपलब्ध होने पर होस्ट किस स्रोत-गंतव्य जोड़ी को प्राथमिकता देगा। Happy Eyeballs उसके ऊपर कनेक्शन रणनीति जोड़ता है: यह दोनों फ़ैमिली में प्रयास शुरू करता है और जो पहले जवाब दे उसे रखता है, ताकि उपयोगकर्ता को टूटी फ़ैमिली के टाइमआउट का इंतज़ार न करना पड़े।

दोनों में से कोई तंत्र रास्ता नहीं बनाता। यदि आपकी टनल केवल IPv4 ले जाती है, तो AAAA उम्मीदवार अब भी एक वैध गंतव्य है जिसे क्लाइंट आज़मा सकता है, और विफलता त्रुटि के बजाय धीमी लोडिंग के रूप में दिखती है, क्योंकि ब्राउज़र पीछे हट गया। उपयोगकर्ता धीमी साइट की शिकायत करता है, टूटी की नहीं, और सहायता टिकट उसी अस्पष्टता को विरासत में लेता है। स्थिर फ़ैमिली के साथ इसे दोहराएँ और रिपोर्ट स्पष्ट हो जाती है।

इसी पीछे हटने के कारण लक्षण ऐप्लिकेशन के हिसाब से असंगत है। ब्राउज़र देरी छिपाता है; स्थिर फ़ैमिली वाला कमांड-लाइन क्लाइंट आपको असली विफलता तुरंत दिखाता है।

पता लगाएँ कि अनुरोध ने वास्तव में कौन-सी फ़ैमिली इस्तेमाल की

नाम से शुरू करें, टनल से नहीं। दोनों रिकॉर्ड प्रकार पूछें और लिखें कि क्या लौटा:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

यदि v4 अनुरोध सफल होता है और v6 अनुरोध विफल होता है, तो आपने समस्या को ऐसे रूप में दोहराया है जिसे आप डीबग कर सकते हैं। यदि शेल से दोनों सफल होते हैं और ब्राउज़र फिर भी विफल रहता है, तो टनल को छूने से पहले ऐप्लिकेशन के अपने रिज़ॉल्वर या कैश किए गए उत्तर को देखें।

फ़ैमिली और गंतव्य अपने नोट्स में रखें। जो टिकट कहता है कि साइट VPN पर लोड नहीं होती, उसे कोई जाँच नहीं सकता, जबकि जो टिकट कहता है कि AAAA विफल होता है और A काम करता है, वह किसी खास रास्ते की ओर इशारा करता है।

उस फ़ैमिली के लिए रास्ता जाँचें

विफल हो रही फ़ैमिली के लिए कर्नेल से पूछें कि वह कौन-सा रास्ता इस्तेमाल करेगा और उसकी तुलना टनल के कॉन्फ़िगर किए गए पतों से करें। Linux पर, ip -6 route get गंतव्य के लिए वह इंटरफ़ेस और स्रोत दिखाता है जिन्हें चुना जाएगा।

फिर टनल को ही जाँचें। WireGuard पीयर मान्य IP की सूची रखते हैं, और 0.0.0.0/0 के लिए प्रविष्टि IPv6 के बारे में कुछ नहीं कहती। यदि पीयर की सूची में IPv6 प्रीफ़िक्स नहीं है, तो क्लाइंट के पास AAAA ट्रैफ़िक टनल में भेजने का कोई कारण नहीं है, और पैकेट उसी रास्ते बाहर जाता है जो होस्ट अन्यथा करता।

फ़ायरवॉल नियम और NAT नीति हर फ़ैमिली के लिए उसी जाँच की हक़दार हैं। IPv4 के लिए लिखा नियम किसी भी प्लेटफ़ॉर्म पर IPv6 को कवर नहीं करता, और यही सबसे आम कारण है कि एक फ़ैमिली काम करती है जबकि दूसरी नहीं।

स्क्रीनशॉट आसान बनाने के लिए IPv6 बंद न करें

सिस्टम-व्यापी IPv6 बंद करने से लक्षण गायब हो जाएगा और आप निदान के बिना रह जाएँगे। यह किसी भी ऐसे गंतव्य को भी तोड़ता है जो केवल IPv6 है, और अगले ऐप्लिकेशन के लिए वही बग छिपा देता है। यदि किसी मशीन को सचमुच IPv6 इस्तेमाल नहीं करना चाहिए, तो वह मालिक और परीक्षण वाली जानबूझकर बनाई नीति है। किसी घटना के दौरान इसे बंद करना दोनों में से कुछ नहीं है।

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

टिकट में क्या लिखें

चार चीज़ें दर्ज करें: होस्टनेम, विफल हुई फ़ैमिली, कर्नेल ने जो रास्ता चुना, और फ़ैमिली-विशिष्ट अनुरोध का परिणाम। यही सेट किसी और के लिए विफलता दोहराने के लिए काफ़ी है, बिना अंदाज़ा लगाए कि आपका मतलब दो रास्तों में से कौन-सा था।

RFC 6724 के एड्रेस चयन नियम बताते हैं कि क्लाइंट ने जिस उम्मीदवार को प्राथमिकता दी उसे क्यों दी, और RFC 8305 उस दौड़-व्यवहार को समझाता है जिसने देरी छिपाई। इनमें से कोई आपके लिए पैकेट रूट नहीं करेगा, और टनल को यही हिस्सा करना है।