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" என்பதை அடுத்த நபர் மீண்டும் உருவாக்கக்கூடிய ஒன்றாக மாற்றுகின்றன.