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" ಅನ್ನು ಮುಂದಿನ ವ್ಯಕ್ತಿ ಮರುಸೃಷ್ಟಿಸಬಹುದಾದ ಯಾವುದೋ ಆಗಿಸುತ್ತವೆ.