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" ను తదుపరి వ్యక్తి మళ్లీ సృష్టించగలిగే దానిగా మారుస్తాయి.