Android ಆ್ಯಪ್ VPN ಹೊರಗೆ ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ: ಬೈಂಡಿಂಗ್ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

VPN ಸಕ್ರಿಯವಾಗಿದ್ದಾಗಲೂ Android ಡೀಫಾಲ್ಟ್ ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸಬಹುದು. ಪ್ರಕ್ರಿಯೆಯನ್ನು VPN ನೆಟ್ವರ್ಕ್ಗೆ ಬೈಂಡ್ ಮಾಡಿ ಮತ್ತು ಆ್ಯಪ್ ನಿಜವಾಗಿ ಯಾವ resolver ಬಳಸಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ.

VPN ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಬ್ರೌಸರ್ ತಲುಪುತ್ತಿದ್ದರೂ Android ಆ್ಯಪ್ ಒಂದು ಆಂತರಿಕ ಹೆಸರನ್ನು ಪರಿಹರಿಸಲು ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಅದೇ ಬಿಲ್ಡ್ ಇನ್ನೊಂದು ಫೋನ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. URL ವೇರಿಯೇಬಲ್ ಅಲ್ಲ. ವೇರಿಯೇಬಲ್ ಎಂದರೆ ಆ್ಯಪ್ ಪ್ರಕ್ರಿಯೆಗೆ ಪರಿಹಾರಕ್ಕಾಗಿ ಯಾವ ನೆಟ್ವರ್ಕ್ ಬಳಸಲು ಅನುಮತಿ ಇದೆ ಎಂಬುದು, ಮತ್ತು ನಿಮ್ಮ ಸಾಕೆಟ್‌ಗಳು ಬಳಸುವ ನೆಟ್ವರ್ಕ್ ಸಕ್ರಿಯ VPN ಎಂದು Android ಖಾತರಿ ನೀಡುವುದಿಲ್ಲ. ಈ ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು resolver ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ನಿಮ್ಮ ಊಹೆಗೆ ಹೊಂದದಿದ್ದಾಗ ನಿಲ್ಲಿಸಿ.

ಹಂತ 1: ಆ್ಯಪ್ ಯಾವ ನೆಟ್ವರ್ಕ್‌ನಲ್ಲಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ

ಸ್ಟೇಟಸ್ ಬಾರ್ ಬದಲು ಆ್ಯಪ್‌ನ ಸ್ವಂತ ನೋಟವನ್ನು ಓದಿ. ConnectivityManager ನಿಂದ ಸಕ್ರಿಯ ನೆಟ್ವರ್ಕ್, ಅದರ LinkProperties, DNS ಸರ್ವರ್‌ಗಳ ಪಟ್ಟಿ ಮತ್ತು ಖಾಸಗಿ DNS ಸೆಟ್ಟಿಂಗ್ ಪಡೆಯಿರಿ. ಪಟ್ಟಿಯಲ್ಲಿ VPN ನ resolver ಇದ್ದರೆ, ಆ್ಯಪ್‌ಗೆ ಅದರತ್ತ ದಾರಿ ಇದೆ; ಅದರಲ್ಲಿ Wi-Fi ನ resolver ಇದ್ದರೆ, ಆ ಪ್ರಕ್ರಿಯೆಗೆ ಟನಲ್ ಡೀಫಾಲ್ಟ್ ನೆಟ್ವರ್ಕ್ ಅಲ್ಲ.

VPN ಐಕಾನ್ ಟನಲ್ ಇದೆ ಎಂದು ಮಾತ್ರ ಹೇಳುತ್ತದೆ. ಆ್ಯಪ್ ಪ್ರಕ್ರಿಯೆ ಅದಕ್ಕೆ ಬೈಂಡ್ ಆಗಿತ್ತು ಎಂದು ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು Android ಹೆಸರು ಪರಿಹಾರವನ್ನು ಯಾವಾಗಲೂ ಸಕ್ರಿಯವಾಗಿ ಕಾಣುವ ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ರೂಟ್ ಮಾಡುವುದಿಲ್ಲ. ಇನ್ನೊಂದು ಸಾಧನಕ್ಕೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಸ್ಥಳೀಯ VPN ಆ್ಯಪ್‌ಗಳು, ಇಂಟರ್ನೆಟ್ ಇಲ್ಲದ Wi-Fi ನೆಟ್ವರ್ಕ್‌ಗಳು ಮತ್ತು ತಯಾರಕರ ಬಿಲ್ಡ್‌ಗಳು ಆ್ಯಪ್ ಅನ್ನು ಟನಲ್‌ನ ಸರ್ವರ್‌ಗಳ ಬದಲು ಡೀಫಾಲ್ಟ್ resolver ಕೇಳುವಂತೆ ಬಿಡಬಹುದು.

ಹಂತ 2: VPN ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಕೇಳಿ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬೈಂಡ್ ಮಾಡಿ

ಆ್ಯಪ್ ಟನಲ್‌ನ resolver ಅನ್ನು ಕಡ್ಡಾಯವಾಗಿ ಬಳಸಬೇಕಾದಾಗ, VPN ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಇರುವ ನೆಟ್ವರ್ಕ್ ಕೇಳಿ ಮತ್ತು ಕಾಲ್‌ಬ್ಯಾಕ್‌ನಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬೈಂಡ್ ಮಾಡಿ, ಇದರಿಂದ ನೆಟ್ವರ್ಕ್ ಯಾವಾಗ ಬರುತ್ತದೆ ಎಂದು ಕೋಡ್ ಊಹಿಸದಂತೆ:

val request = NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .build()

connectivityManager.requestNetwork(request, object : NetworkCallback() {
    override fun onAvailable(network: Network) {
        val bound = connectivityManager.bindProcessToNetwork(network)
        Log.i(TAG, "bound to VPN network: " + bound)
    }
})

ಈ ಕರೆ ಇಡೀ ಪ್ರಕ್ರಿಯೆಯ ಡೀಫಾಲ್ಟ್ ನೆಟ್ವರ್ಕ್ ಬದಲಾಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಂತರ ರಚಿಸಿದ ಪ್ರತಿ ಸಾಕೆಟ್ ಅದನ್ನು ಬಳಸುತ್ತದೆ. ಈಗಾಗಲೇ ಇರುವ ಸಾಕೆಟ್‌ಗಳು ತಾವು ರಚಿಸಲಾದ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಬೈಂಡ್‌ಗೆ ಮೊದಲು ತೆರೆದ ಸಂಪರ್ಕ ಪೂಲ್ ಹಳೆಯ ದಾರಿಯಲ್ಲಿ ಪರಿಹರಿಸುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು. ಹಿಂತಿರುಗಿಸಿದ ಮೌಲ್ಯ boolean, ಮತ್ತು false ಫಲಿತಾಂಶ ಎಂದರೆ ಬೈಂಡ್ ಆಗಿಲ್ಲ; ಸಣ್ಣ ವಿಳಂಬದೊಂದಿಗೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ಎರಡೂ ಪ್ರಯತ್ನಗಳನ್ನು ಲಾಗ್ ಮಾಡಿ.

ಹಂತ 3: ಬೈಂಡ್ ಅನ್ನು ಅಗತ್ಯವಿರುವಷ್ಟಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಿ

ಇಡೀ ಪ್ರಕ್ರಿಯೆಯ ಬೈಂಡಿಂಗ್ ಒರಟಾದದ್ದು. ಟೆಲಿಮೆಟ್ರಿ, ಅಪ್‌ಡೇಟ್ ಪರಿಶೀಲನೆಗಳು ಮತ್ತು ತೃತೀಯ ಪಕ್ಷದ SDK ಗಳೂ ಟನಲ್‌ಗೆ ಹೋಗುತ್ತವೆ, ಮತ್ತು ಟನಲ್‌ಗೆ ಇಂಟರ್ನೆಟ್ ಇಲ್ಲದಿದ್ದರೆ ಅವು ವಿಫಲವಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಒಂದೇ ವಿನಂತಿಗಾಗಿ ನೆಟ್ವರ್ಕ್‌ನ ಸಾಕೆಟ್ ಫ್ಯಾಕ್ಟರಿ ಬಳಸಿ ಮತ್ತು ಉಳಿದ ಎಲ್ಲವನ್ನೂ ಸಾಧನದ ಡೀಫಾಲ್ಟ್‌ನಲ್ಲಿ ಬಿಡಿ. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಒಂದು ಮಾದರಿ ಆಯ್ಕೆಮಾಡಿ: ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕೂ ಸಣ್ಣ ಬೈಂಡ್, ಅಥವಾ VPN ಮಾಯವಾದಾಗ ಸ್ಪಷ್ಟ ಅನ್‌ಬೈಂಡ್‌ನೊಂದಿಗೆ ಪ್ರಕ್ರಿಯೆ ಬೈಂಡ್.

resolver ನ ಎರಡು ವೈಶಿಷ್ಟ್ಯಗಳು ಯಾವುದೇ ದೋಷವಿಲ್ಲದೆ ಬೈಂಡ್ ಅನ್ನು ಸೋಲಿಸಬಹುದು. ಕಟ್ಟುನಿಟ್ಟಿನ ಮೋಡ್‌ನಲ್ಲಿ ಖಾಸಗಿ DNS ಕ್ವೆರಿಗಳನ್ನು ನೆಟ್ವರ್ಕ್ resolver ಬದಲು ಹೆಸರಿನ DoT ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ತನ್ನದೇ DNS-over-HTTPS ಕ್ಲೈಂಟ್ ಹೊಂದಿರುವ ಆ್ಯಪ್ ಸಿಸ್ಟಮ್ resolver ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ. ಬೈಂಡ್ ವಿಫಲವಾಯಿತು ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ. VPN ನ DNS ಸರ್ವರ್ ಅನ್ನು ಎಂದಿಗೂ ತಲುಪದ ಕ್ವೆರಿ ಯಾವುದೇ ಟನಲ್-ಬದಿಯ ಲಾಗ್‌ನಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ.

ಹಂತ 4: CONNECTED ನಿರ್ಬಂಧವನ್ನು ನಂಬಬೇಡಿ

WorkManager ನಲ್ಲಿ NetworkType.CONNECTED ಎಂದರೆ ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ, ಮತ್ತು ಅಡಿಯಲ್ಲಿನ Wi-Fi ಅಥವಾ ಸೆಲ್ಯುಲರ್ ಲಿಂಕ್ ಹೋದಾಗಲೂ VPN ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಅದನ್ನು ಪೂರೈಸುತ್ತದೆ. ಕೆಲಸ ನಡೆಯುತ್ತದೆ, ಪ್ರತಿ ವಿನಂತಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಮರುಪ್ರಯತ್ನ ನೀತಿ ಅದನ್ನು ಶೆಡ್ಯೂಲಿಂಗ್ ದೋಷದಂತೆ ಕಾಣುವ ಬಿರುಗಾಳಿಯಾಗಿ ಮಾಡುತ್ತದೆ. ಟನಲ್ ಒಂದು ನೆಟ್ವರ್ಕ್; ನಿರ್ಬಂಧ ಎಂದಿಗೂ ಇಂಟರ್ನೆಟ್ ಪರಿಶೀಲನೆ ಆಗಿರಲಿಲ್ಲ.

ಕೆಲಸಕ್ಕೆ ನಿಜವಾಗಿ ಬೇಕಾದ ಸಾಮರ್ಥ್ಯವನ್ನು ಪರಿಶೀಲಿಸಿ, ಉದಾಹರಣೆಗೆ ಮಾನ್ಯಗೊಳಿಸಿದ ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶ, ಮತ್ತು ಬ್ಯಾಕ್‌ಆಫ್‌ನೊಂದಿಗೆ ಸೀಮಿತ ಮರುಪ್ರಯತ್ನ ನೀತಿ ಇಟ್ಟುಕೊಳ್ಳಿ. ಕೆಲಸಕ್ಕೆ ಖಾಸಗಿ ಹೆಸರು ಬೇಕಾದರೆ, ಕೆಲಸ ಮಾಡುವ ಮೊದಲು ಆ ಹೆಸರನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ ನೆಟ್ವರ್ಕ್‌ನಲ್ಲಿ ಪರಿಹರಿಸಿ, ಮತ್ತು ಯಶಸ್ವಿಯಾಗಲು ಸಾಧ್ಯವಿಲ್ಲದ ವಿನಂತಿಯನ್ನು ಮರುಪ್ರಯತ್ನಿಸುವ ಬದಲು ಸ್ಪಷ್ಟ ದೋಷದೊಂದಿಗೆ ಬೇಗ ವಿಫಲವಾಗಿ.

ಹಂತ 5: ಸಾಕ್ಷ್ಯವನ್ನು ದಾಖಲಿಸಿ ಮತ್ತು ಶ್ರೇಣಿಯನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ

ಆಯ್ಕೆ ಮಾಡಿದ ನೆಟ್ವರ್ಕ್‌ನ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಪ್ರಕಾರಗಳು, LinkProperties ನಿಂದ DNS ಸರ್ವರ್‌ಗಳು, ಬೈಂಡ್ true ಹಿಂತಿರುಗಿಸಿತೇ, ಮತ್ತು ಮೊದಲ ವಿನಂತಿಯ ನಿಖರ ವೈಫಲ್ಯವನ್ನು ಲಾಗ್ ಮಾಡಿ. ನಂತರ ಅದೇ ಬೈಂಡಿಂಗ್ ಅಡಿಯಲ್ಲಿ ಖಾಸಗಿ ಹೆಸರು ಮತ್ತು ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಚಲಾಯಿಸಿ. ಆ ಜೋಡಿ ಆ್ಯಪ್ ಟನಲ್ resolver ಬಳಸಿತೇ ಅಥವಾ ಮೌನವಾಗಿ ಸಾಧನದ ಡೀಫಾಲ್ಟ್‌ಗೆ ಬಿದ್ದಿತೇ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ಬಳಕೆದಾರರು ಅನುಭವಿಸುವ ವ್ಯತ್ಯಾಸ.

ನೀವು ಬೆಂಬಲಿಸುವ ಅತ್ಯಂತ ಹಳೆಯ Android ಆವೃತ್ತಿಯಲ್ಲಿ ಮತ್ತು ಒಂದು ಪ್ರಸ್ತುತ ಬಿಡುಗಡೆಯಲ್ಲಿ ಪುನರಾವರ್ತಿಸಿ. ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಸರಿಯಾಗಿ ಕಾಣಿಸುವ resolver ವರ್ತನೆ ಸಾಧನಗಳು ಮತ್ತು ಆವೃತ್ತಿಗಳು ಭಿನ್ನವಾಗುವ ನಿಖರ ಸ್ಥಳ, ಮತ್ತು ಹೊಸ ಪರೀಕ್ಷಾ ಸಾಧನದಲ್ಲಿ ಮಾತ್ರ ಉತ್ತೀರ್ಣವಾಗುವ ಬಿಲ್ಡ್ ನೀವು ರವಾನಿಸುವ ಶ್ರೇಣಿಗೆ ಪರಿಶೀಲಿಸಲ್ಪಟ್ಟಿಲ್ಲ. adb shell dumpsys connectivity ವೈಫಲ್ಯವನ್ನು ಪುನರುತ್ಪಾದಿಸುವಾಗ ಸಾಧನವು ಯಾವ ನೆಟ್ವರ್ಕ್‌ಗಳು ಮತ್ತು ಸಾಮರ್ಥ್ಯಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಲು ವೇಗದ ದಾರಿ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು