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 એ માટે જ છે.

ફોનનું બિલ્ડ, બ્રાઉઝરની આવૃત્તિ અને તમે પૂછેલા રિઝોલ્વર નોંધો. એ ત્રણ હકીકતો "IPv6 is broken" ને એવી વસ્તુમાં ફેરવે છે જે આગલી વ્યક્તિ પુનઃઉત્પાદિત કરી શકે.