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" लाई अर्को व्यक्तिले पुनःउत्पादन गर्न सक्ने कुरामा बदल्छन्।