Android DNS ಸರಿಯಾಗಿ ಓದಿ: ನೆಟ್ವರ್ಕ್ ಪ್ರಕಾರ, resolv.conf-ನಲ್ಲಿ ಅಲ್ಲ

ನೀವು ಸಾಧನದಲ್ಲಿ shell ತೆಗೆದುಕೊಳ್ಳುತ್ತೀರಿ, /etc/resolv.conf ಓದುತ್ತೀರಿ ಅಥವಾ ಹಳೆಯ net.dns1 ಮೌಲ್ಯವನ್ನು ಅಗೆದು ತೆಗೆಯುತ್ತೀರಿ, ಒಂದು ವಿಳಾಸ ಸಿಗುತ್ತದೆ. ನಿಮ್ಮ ಮುಂದಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪೂರ್ಣ ಬೇರೆ ಯಾವುದೋ ಮೂಲಕ ಪರಿಹರಿಸುತ್ತದೆ. ಪ್ರಸ್ತುತ Android ಆವೃತ್ತಿಯಲ್ಲಿ resolver ನೆಟ್ವರ್ಕ್ ಪ್ರಕಾರ ಇರುತ್ತದೆ: ಸಿಸ್ಟಂ ಪ್ರತಿ Network ಗೆ ನೀತಿ ಇಟ್ಟುಕೊಂಡು, ವಿನಂತಿ ಕಳುಹಿಸಿದ socketಗೆ ಅದನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ಫೈಲ್ ಮತ್ತು ಹಳೆಯ ಗುಣಲಕ್ಷಣ ಉಳಿಕೆಗಳು, ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ನಿಮ್ಮ ಪ್ರಶ್ನೆ ನಿಜವಾಗಿ ತೆಗೆದುಕೊಂಡ ಮಾರ್ಗವನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ.

ಈ ಅಂತರ split-tunnel ಮತ್ತು Private DNS ರೋಲ್ಔಟ್ನಲ್ಲಿ ಕಾಣುತ್ತದೆ, ಅಲ್ಲಿ ಒಂದೇ ಫೋನ್ನಲ್ಲಿನ ಎರಡು ಅಪ್ಲಿಕೇಶನ್ಗಳು ಕಾನೂನುಬದ್ಧವಾಗಿ ಬೇರೆ ಬೇರೆ ಉತ್ತರಗಳನ್ನು ನೋಡಬಹುದು. ಈ ಮಾರ್ಗದರ್ಶಿ ತಪ್ಪು ಅಥವಾ ಇಲ್ಲದ ಪರಿಹಾರದಿಂದ ಆರಂಭವಾಗಿ ಅದು ಒಡೆತನ ಹೊಂದಿರುವ ಸಂರಚನೆಯತ್ತ ಹಿಂತಿರುಗುತ್ತದೆ.

resolver ಒಂದು ನೆಟ್ವರ್ಕ್ಗೆ ಸೇರಿದ್ದು, ಸಾಧನಕ್ಕಲ್ಲ

Android 9 ಮತ್ತು ನಂತರ ಹೆಸರುಗಳ ಪರಿಹಾರ socket ಸಂಪರ್ಕಗೊಂಡಿರುವ Network ಆಧರಿಸಿದ ಸಿಸ್ಟಂ resolver ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಪ್ರತಿ ನೆಟ್ವರ್ಕ್ ತನ್ನದೇ LinkProperties ಹೊಂದಿದೆ, ಆ ಗುಣಲಕ್ಷಣಗಳು ಆ ನೆಟ್ವರ್ಕ್ಗೆ ಮಾತ್ರ DNS ಸರ್ವರ್ ಪಟ್ಟಿ, ಹುಡುಕಾಟ ಡೊಮೇನ್ಗಳು ಮತ್ತು Private DNS ಸ್ಥಿತಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತವೆ. ಆ ಮಾದರಿಯಲ್ಲಿ ಫೈಲ್ನಿಂದ ಓದಬಹುದಾದ ಒಂದೇ ಸಾಧನ-ವ್ಯಾಪಿ ಪಟ್ಟಿಗೆ ಹೊಂದುವಂಥದ್ದು ಯಾವುದೂ ಇಲ್ಲ.

VPN ಈ ವಿಭಜನೆಯನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ. ಟನೆಲ್ ಮೇಲೆ ಬಂದಾಗ VPN ಅಪ್ಲಿಕೇಶನ್ VPNನ ಸ್ವಂತ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ನೋಂದಾಯಿಸಿದ DNS ಸರ್ವರ್ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ಅದರ ಮೂಲಕ ಮಾರ್ಗವಾಗುವ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಆ ಸರ್ವರ್ಗಳಲ್ಲಿ ಪರಿಹರಿಸುತ್ತವೆ, ಹೊರಗಿಟ್ಟ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಕೆಳಗಿನ ನೆಟ್ವರ್ಕ್ ಬಳಸುತ್ತಲೇ ಇರುತ್ತವೆ. ಒಂದು ಸಾಧನ, ಎರಡು ಉತ್ತರ ಮಾರ್ಗಗಳು, ವಿರೋಧಾಭಾಸವಿಲ್ಲ.

ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಅನ್ನು ಬಾಧಿತ ಅಪ್ಲಿಕೇಶನ್ ಒಳಗಿನಿಂದ ಓದಿ

ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನೇ ಕೇಳಿ. Context ಮತ್ತು ಸಾಮಾನ್ಯ android.permission.ACCESS_NETWORK_STATE ಅನುಮತಿ ಇರುವ ವಿಧಾನ ಸಿಸ್ಟಂ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಮುಟ್ಟದೆ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಓದಬಹುದು:

val cm = getSystemService(ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val links = network?.let { cm.getLinkProperties(it) }

val dnsServers = links?.dnsServers
val privateDnsActive = links?.isPrivateDnsActive
val privateDnsName = links?.privateDnsServerName

activeNetwork ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಯ ಡಿಫಾಲ್ಟ್ ನೆಟ್ವರ್ಕ್, ಸಾಧನದ ಏಕೈಕ ನೆಟ್ವರ್ಕ್ ಅಲ್ಲ, ಕರೆ ಮಾಡುವವರಿಗೆ ಬಳಸಬಹುದಾದ ಡಿಫಾಲ್ಟ್ ಇಲ್ಲದಿದ್ದಾಗ null ಆಗಿರಬಹುದು. ತಡೆಹಿಡಿದ ಡಿಫಾಲ್ಟ್ VPN ಸಾಮಾನ್ಯ ಕಾರಣ. isPrivateDnsActive ಆ ನೆಟ್ವರ್ಕ್ನ ಪ್ರಶ್ನೆಗಳು TLS ಮೂಲಕ ಹೆಸರಿಸಿದ resolverಗೆ ಹೋಗುತ್ತವೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ, ಇದು ಸರಳ UDP 53 ಪರೀಕ್ಷೆ ಏನು ತೋರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. API ಮೇಲ್ಮೈ LinkProperties ಅಡಿಯಲ್ಲಿ ದಾಖಲಾಗಿದೆ, ಅದರಲ್ಲಿ ಪ್ರತಿ ಮೌಲ್ಯವೂ ಸಂರಚನೆಯ ಸ್ನ್ಯಾಪ್ಶಾಟ್, ನಿರ್ದಿಷ್ಟ ಪ್ರಶ್ನೆ ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್ ತಲುಪಿತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ.

ಡಿಫಾಲ್ಟ್ ನೆಟ್ವರ್ಕ್ ಕೆಲಸ ಮಾಡುವ ನೆಟ್ವರ್ಕ್ ಅಲ್ಲದಿದ್ದಾಗ

ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಡಿಫಾಲ್ಟ್ಗೆ ಮಾತ್ರ ಉತ್ತರಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಪ್ರಕ್ರಿಯೆ ಅಥವಾ ಒಂದು socket ಅನ್ನು ಬೇರೆ ನೆಟ್ವರ್ಕ್ಗೆ ಬಿಗಿಯಬಹುದು, ಆಗ ಪರಿಹಾರ ಆ ಆಯ್ಕೆಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ನಿಮ್ಮ ರೋಗನಿರ್ಣಯ ಇನ್ನೂ ಡಿಫಾಲ್ಟ್ ವರದಿ ಮಾಡುತ್ತದೆ. ತನ್ನದೇ DNS-over-HTTPS resolver ತರುವ ಬ್ರೌಸರ್ ಸಿಸ್ಟಂ ಪಟ್ಟಿಯನ್ನು ಕೇಳುವುದೇ ಇಲ್ಲ, ಹಾಗಾಗಿ ಅದರ ಉತ್ತರಗಳು ಉಳಿದ ಸಾಧನದ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ. ಕೆಲಸದ ಪ್ರೊಫೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ನೀತಿಯೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಬಳಕೆದಾರರ ಅಡಿಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಸರ್ವರ್ಗಳನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಬೈಂಡಿಂಗ್ ಪರಿಶೀಲಿಸಿ.

VPN ಏಕೀಕರಣ ಇನ್ನೊಂದು ಅರ್ಧ. dhcp-option DNS ಸಾಲನ್ನು OpenVPN ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಸ್ವೀಕರಿಸುವುದು ಮತ್ತು ಆ ವಿಳಾಸವನ್ನು Android VPN ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ನೋಂದಾಯಿಸುವುದು ಎರಡು ಪ್ರತ್ಯೇಕ ಹಂತಗಳು, ಸರ್ವರ್ಗೆ ಕಾಣೆಯಾದ ಮಾರ್ಗ ತಪ್ಪು ವಿಳಾಸದಷ್ಟೇ ಮೌನವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ. ಅಭಿವೃದ್ಧಿ ಯಂತ್ರದಿಂದ adb shell dumpsys connectivity build ಅನುಮತಿಸಿದಾಗ ಅದೇ ಲಿಂಕ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ನೆಟ್ವರ್ಕ್ ಪ್ರಕಾರ ಮುದ್ರಿಸುತ್ತದೆ, ಇದು ಕೋಡ್ ಬರೆಯದೆಯೇ ಪಟ್ಟಿಯನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ.

ಸಂರಚನೆಯನ್ನು ನಿಮಗೆ ಅನುಮತಿ ಇರುವ ಒಂದು ಪರಿಹಾರದೊಂದಿಗೆ ಹೋಲಿಸಿ

ಖಾಸಗಿ ಹೆಸರಿನ ಸ್ಥಳದಲ್ಲಿ ಪರಿಹರಿಸಬೇಕಾದ ಹೆಸರು ಮತ್ತು ಒಂದು ಸಾರ್ವಜನಿಕ ಹೆಸರು ಆಯ್ಕೆಮಾಡಿ, ಎರಡೂ ಫಲಿತಾಂಶಗಳನ್ನು ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ: ನೆಟ್ವರ್ಕ್, ಸಂರಚಿಸಿದ ಸರ್ವರ್ಗಳು, Private DNS ಸ್ಥಿತಿ ಮತ್ತು ದೋಷದ ನಿಖರ ಪಠ್ಯ. ಹೆಸರಿಸಿದ ಸರ್ವರ್ಗೆ ನೇರ ಪ್ರಶ್ನೆ ಆ ಸರ್ವರ್ ನಿಮಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಸಾಮಾನ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಪರಿಹಾರ ಅದನ್ನು ಆಯ್ಕೆ ಮಾಡಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಕ್ಯಾಶ್ನಲ್ಲಿರುವ ಉತ್ತರ ತಾಜಾ ಪರೀಕ್ಷೆ ಅಲ್ಲ, ಹಾಗಾಗಿ ಕ್ಯಾಶ್ ಖಾಲಿ ಮಾಡಿ ಅಥವಾ ಇಂದು ಯಾರೂ ಕೇಳದ ಹೆಸರು ಬಳಸಿ.

resolver ನಿರ್ದಿಷ್ಟ ಪ್ರವೇಶ ನೆಟ್ವರ್ಕ್ನ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಮಾತ್ರ ಸೇವೆ ಸಲ್ಲಿಸಿದರೆ, VPN ನಿರ್ಗಮನದ ನಂತರ ಅದು ನೋಡುವುದು ಫಲಿತಾಂಶವನ್ನು ನಿರ್ಧರಿಸಬಹುದು, ಇದು ಅದನ್ನು ನಡೆಸುವವರಿಗೆ ನೀತಿ ಪ್ರಶ್ನೆ, ಆಪರೇಟರ್ಗಳು UDP 53 ಬ್ಲಾಕ್ ಮಾಡುತ್ತಾರೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ. Private DNS ಸಕ್ರಿಯವಿರುವಲ್ಲಿ ಅಪೂರ್ಣ ಹೋಸ್ಟ್ ಹೆಸರು ವಿನ್ಯಾಸದ ಪ್ರಕಾರ ತಿರಸ್ಕೃತವಾಗಬಹುದು, ಅದೇ ಸರ್ವರ್ ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ. ಗುಣಲಕ್ಷಣಗಳನ್ನು ಓದುವುದು ಯಾವ ಕ್ರಮ ಜಾರಿಯಲ್ಲಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಹಾಗಾಗಿ ನೀವು ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರ್ಗಳನ್ನು ಊಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೀರಿ.

ಈ ಅಸಂಗತಿ ಯಾವ ಪದರದ್ದೋ ಅದನ್ನು ಸರಿಪಡಿಸಿ

ಜಾಗತಿಕ ಸ್ಥಿತಿಯನ್ನು ಸಂಪಾದಿಸುವ ಬದಲು ಮೇಲಕ್ಕೆ ಕೆಲಸ ಮಾಡಿ. ಅಪ್ಲಿಕೇಶನ್ ತಪ್ಪು ನೆಟ್ವರ್ಕ್ಗೆ ಬಿಗಿದಿದ್ದರೆ ಬೈಂಡಿಂಗ್ ಸರಿಪಡಿಸಿ. ಪ್ರೊಫೈಲ್ ತಪ್ಪು DNS ಆಯ್ಕೆ ನೀಡಿದರೆ ಪ್ರೊಫೈಲ್ ಸರಿಪಡಿಸಿ. ಯಾವ ನೆಟ್ವರ್ಕ್ನ resolver ನಿಮ್ಮ ಖಾಸಗಿ ವಲಯಕ್ಕೆ ಸೇವೆ ಸಲ್ಲಿಸಲಾರದೋ ಅಲ್ಲಿ Private DNS ಕಟ್ಟುನಿಟ್ಟಾಗಿದ್ದರೆ, ಅದು ಸಾಧನ ನಿರ್ವಹಣೆಯ ನಿರ್ಧಾರ, ಎಲ್ಲೆಡೆ ವೈಶಿಷ್ಟ್ಯ ಆಫ್ ಮಾಡಲು ಕಾರಣವಲ್ಲ.

ಸಾರ್ವಜನಿಕ resolverಗಳನ್ನು DHCP ಹುಕ್ ಅಥವಾ ಸಿಸ್ಟಂ ಗುಣಲಕ್ಷಣಕ್ಕೆ ತಳ್ಳುವುದು ನಿರಂತರವಾಗಿ ಘಟನೆಗಳನ್ನು ಉಂಟುಮಾಡುವ ಸರಿಪಡಿಸುವಿಕೆ: ಖಾಸಗಿ ಹೆಸರುಗಳು ಪರಿಹಾರವಾಗುವುದು ನಿಲ್ಲುತ್ತದೆ, ಬದಲಾವಣೆ VPN ಅವಧಿಯನ್ನು ಮೀರಿ ಉಳಿಯುತ್ತದೆ, ಸಾಧನದಲ್ಲಿ ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಮಾಲೀಕರಿಲ್ಲದ ಹಳೆಯ ವಿಳಾಸ ಸಿಗುತ್ತದೆ. ಬದಲಾವಣೆಯನ್ನು VPN, ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ ಈ ಅಸಂಗತಿಯ ಒಡೆತನ ಇರುವ ನಿರ್ವಹಣಾ ಪದರದ ಒಳಗೆ ಇರಿಸಿ, ನಂತರ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಮತ್ತೆ ಓದಿ ಸರ್ವರ್ ಪಟ್ಟಿ ನಿಜವಾಗಿ ಬದಲಾಗಿದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.

ಕೊನೆಗೆ ನಿಮಗೆ ಒಂದು ನೆಟ್ವರ್ಕ್, resolver ಪಟ್ಟಿ ಮತ್ತು Private DNS ಸ್ಥಿತಿಗೆ ಬಿಗಿದ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿ ಬೇಕು. ಈ ಸರಪಣಿಯನ್ನು ತೋರಿಸಲು ಸಾಧ್ಯವಾದಾಗ, ಫೈಲ್ನಲ್ಲಿನ ಪರಿಚಿತ ವಿಳಾಸ ಯಾವುದಕ್ಕೂ ಸಾಕ್ಷ್ಯವಲ್ಲ.