ड्युअल-स्टॅक 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 विलंब लपवणाऱ्या शर्यतीच्या वर्तनाचे स्पष्टीकरण देते. त्यापैकी कोणीही तुमच्यासाठी पॅकेट राउट करणार नाही, आणि टनेलने तेच करायचे आहे.