Android VPN IPv6 वर चालते, तरीही ब्राउझर IPv4 निवडतो

VPN सुरू आहे, खाजगी वेब UI लॅपटॉपवरून IPv6 वर उत्तर देत आहे, आणि Android फोन तेच पान अजूनही IPv4 वर उघडतो किंवा ते लोड करण्यास नकार देतो. AAAA रेकॉर्ड आहे. टनेल IPv6 पत्ता नोंदवते. क्लायंटमध्ये काहीही चुकीचे वाटत नाही. निकाल चार वेगवेगळे निर्णय ठरवतात: कोणत्या रिझोल्व्हरने उत्तर दिले, VpnService ने Android ला काय घोषित केले, ब्राउझर कोणते पत्ता-कुटुंब वापरून पाहण्यास तयार होता, आणि पॅकेट जाऊन-येऊन करू शकते का. डीफॉल्ट रूट जोडून लक्षण बदलेल या अपेक्षेऐवजी याच क्रमाने हे हाताळा.

टप्पा 1: AAAA क्वेरीला कोणत्या रिझोल्व्हरने उत्तर दिले हे सिद्ध करा

Android कडे एकच DNS मार्ग नाही. VPN त्याच्या नेटवर्कसाठी DNS सर्व्हर ढकलू शकते, सिस्टम पात्र वाटणाऱ्या होस्टनावांसाठी Private DNS वापरू शकते, आणि Chrome chrome://settings/security वरून स्वतःचा एन्क्रिप्टेड रिझोल्व्हर चालवू शकतो. जिथे टनेल 10.61.0.1 ढकलते पण Private DNS सार्वजनिक प्रदात्याकडे निर्देश करते अशा फोनवर, तुमच्या खाजगी झोनमधील नाव त्या झोनच्या मालकीच्या मशीनद्वारे सोडवले जात नाही. ब्राउझरला त्या नावावर अधिकार नसलेल्या रिझोल्व्हरकडून उत्तर मिळते आणि ते अनुपस्थित मानले जाते, आणि त्रुटीच्या मजकुरात DNS चा उल्लेख कधीच होत नाही.

दुसरे काहीही बदलण्यापूर्वी टनेलच्या रिझोल्व्हरला थेट विचारा. पहिल्या दोन कमांड दाखवतात की Android ने सक्रिय नेटवर्कला कोणते DNS सर्व्हर जोडले आणि Private DNS स्वयंचलित आहे की कठोर मोडमध्ये; तिसरी फोनवरून नाही, तर टनेलमधील कोणत्याही क्लायंटवरून चालते.

adb shell dumpsys connectivity | grep -A3 "DnsAddresses"
adb shell settings get global private_dns_mode
nslookup -type=AAAA nas.lan 10.61.0.1

टप्पा 2: VpnService ने प्रत्यक्षात काय घोषित केले ते वाचा

Android बाजू अनुमानित नाही, स्पष्ट आहे. VpnService.Builder addAddress ने पत्ते, addRoute ने रूट, addDnsServer ने DNS सर्व्हर जोडते, आणि allowFamily ने संपूर्ण टनेल एका पत्ता-कुटुंबात मर्यादित करू शकते. allowFamily(AF_INET) कॉल करून नंतर IPv6 रूट जोडणाऱ्या बिल्डरने सिस्टमला दोन विरोधाभासी गोष्टी सांगितल्या, आणि सिस्टम कुटुंब-निर्बंधच ठेवते. fd00:61::/64 व्यापणारा रूट दुसऱ्या प्रीफिक्समधील इंटरफेस पत्त्यासोबत जोडल्यास त्याच कारणाने अयशस्वी होतो: पत्ता आहे, पण त्या रूटसाठी तो on-link नाही.

अ‍ॅपमधील टॉगलवर विश्वास ठेवण्याऐवजी घोषणा वाचा. dumpsys netd tun इंटरफेसला जोडलेले पत्ते आणि रूट छापते, आणि dumpsys connectivity मधील प्रति-नेटवर्क LinkProperties नेटवर्क दावा करत असलेल्या कुटुंबांच्या शेजारी DNS यादी दाखवते.

adb shell ip -6 addr show tun0
adb shell ip -6 route show table all | grep tun0
adb shell dumpsys connectivity | grep -E "LinkAddresses|Routes"

tun इंटरफेसवर IPv6 पत्ता असूनही सेवेच्या प्रीफिक्सशी कोणताही रूट जुळत नसेल, तर ब्राउझर येण्यापूर्वीच IPv6 डिलिव्हरी तुटलेली आहे. हा प्रयत्न करण्यास नकार देणाऱ्या ब्राउझरपेक्षा वेगळा बग आहे, आणि त्याला वेगळी दुरुस्ती हवी.

टप्पा 3: IPv6 वापरून पाहायचे का हे ब्राउझर ठरवतो

Chromium ला मिळणाऱ्या प्रत्येक AAAA रेकॉर्डचा वापर करत नाही. त्याच्या होस्ट रिझोल्व्हरमध्ये IPv6 पोहोच-तपासणी आणि उमेदवार गाळणी असते, जी नेटवर्कला ते वाहून नेण्यास अक्षम मानल्यास IPv6 वगळू शकते किंवा त्याची प्राधान्यक्रम कमी करू शकते, आणि रिझोल्व्हरचा स्रोत ती तपासणी आसपासच्या अटींसह दाखवतो. तर्क आवृत्ती आणि फ्लॅगवर अवलंबून आहे, आणि म्हणूनच एकाच टनेलवरील दोन फोन वेगळे वागू शकतात. उमेदवार तयार झाल्यावर Happy Eyeballs प्रत्येक कनेक्शनसाठी कुटुंबांची शर्यत लावते, त्यामुळे हळू उत्तर देणारा IPv6 मार्ग वेगाने उत्तर देणाऱ्या IPv4 कडून हारू शकतो.

निर्णयाचा अंदाज न घेता तो पाहा. chrome://net-export द्वारे रेकॉर्ड करून netlog व्ह्यूअरमध्ये पुन्हा चालवलेले सत्र प्रत्येक रिझोल्यूशन आणि निवडलेले कुटुंब दाखवते; chrome://net-internals/#dns कॅशे केलेले निकाल दाखवते. तुमच्या स्वतःच्या रिझोल्व्हरवर AAAA असलेल्या नावासाठी फक्त A रेकॉर्ड परत करणारे रिझोल्यूशन थेट याच टप्प्याकडे निर्देश करते.

टप्पा 4: पॅकेट जाऊन-येऊन करू शकते याची खात्री करा

पत्ता निवडणे म्हणजे डिलिव्हरी नव्हे. Android प्रति-नेटवर्क राउटिंग टेबल आणि धोरण नियम ठेवते जे fwmark ने टेबल निवडतात, त्यामुळे मुख्य टेबलमध्ये दिसणारा रूट सॉकेट वापरत असलेला रूट असतोच असे नाही. नियम वाचणे आणि स्रोत पत्त्यासाठी गंतव्य सोडवण्यास कर्नेलला सांगणे या दोन्हींचे विभाजन करते.

adb shell ip -6 rule show
adb shell ip -6 route get fd00:61::20 from fd00:61::10

प्रश्नाचे उत्तर route get चे आउटपुट देते. ते tun0 सांगते पण पॅकेट तरीही मरत असतील, तर फोनकडे परत जाण्याऐवजी टनेलच्या MTU आणि गेटवेच्या IPv6 फॉर्वर्डिंगकडे जा.

::/0 जोडल्याने सहसा अधिक बिघडते का

::/0 जोडल्याने टनेलचा दावा एका प्रीफिक्सवरून प्रत्येक IPv6 गंतव्यावर बदलतो. फोनवर ते पोहोच-तपासणी पूर्ण करू शकते, कारण तुमच्या प्रीफिक्सबाहेरील चाचणी पत्ता आता राउटेबल दिसतो. पण ते गेटवेवर IPv6 अपस्ट्रीम क्षमता निर्माण करत नाही, आणि अनेक घरगुती गेटवेमध्ये काम करणारा IPv6 अपलिंकच नाही. निकाल सार्वजनिक IPv6 साठी ब्लॅक होल आहे: पूर्वी IPv4 वर पडणारी नावे आता लटकतात, आणि खाजगी पान फक्त यामुळे चांगले दिसू शकते की तपासणी दुसरे काहीतरी मोजते.

धोरणाची किंमतही आहे. टनेलमध्ये ::/0 असल्यास सर्व IPv6 रहदारी VPN मधून बाहेर पडते, नेटवर्क मालकाने वाहून नेण्यास कधीही संमती न दिलेली रहदारीही. हे नामनिर्देशित मालक असलेला तैनातीचा निर्णय माना, रात्री 1 वाजता घेतला जाणारा डीबग पायरी नव्हे.

हे संपवणारा कामाचा क्रम

AAAA उत्तर झोन असलेल्या रिझोल्व्हरकडून येते याची खात्री करा, tun इंटरफेससाठी VpnService आणि netd स्थिती वाचा, Chromium ने उमेदवार वगळला का हे पाहण्यासाठी net-export ट्रेस घ्या, आणि नंतर ip -6 route get ने जाऊन-येऊन तपासा. प्रत्यक्षात अयशस्वी झालेला स्तर दुरुस्त करा आणि स्प्लिट धोरणाला हात लावू नका. खाजगी नावांना सार्वजनिक नावांपेक्षा वेगळी उत्तरे हवी असल्यास split tunneling त्यासाठीच आहे.

फोनचा build, ब्राउझरची आवृत्ती आणि तुम्ही विचारलेला रिझोल्व्हर नोंदवा. या तीन तथ्यांमुळे "IPv6 is broken" पुढच्या व्यक्तीला पुनरुत्पादित करता येणारी गोष्ट बनते.