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" ਨੂੰ ਅਜਿਹੀ ਚੀਜ਼ ਬਣਾ ਦਿੰਦੇ ਹਨ ਜਿਸਨੂੰ ਅਗਲਾ ਵਿਅਕਤੀ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰ ਸਕੇ।