Android ਐਪ VPN ਤੋਂ ਬਾਹਰ ਨਾਮ ਹੱਲ ਕਰਦੀ ਹੈ: ਬਾਈਂਡਿੰਗ ਜਾਂਚ ਸੂਚੀ

ਇੱਕ Android ਐਪ ਅੰਦਰੂਨੀ ਨਾਮ ਹੱਲ ਨਹੀਂ ਕਰ ਪਾਉਂਦੀ, ਜਦੋਂ ਕਿ VPN ਕਲਾਇੰਟ ਦਾ ਆਪਣਾ ਬ੍ਰਾਊਜ਼ਰ ਉਸ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਬਿਲਡ ਕਿਸੇ ਹੋਰ ਫ਼ੋਨ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ। URL ਪਰਿਵਰਤਨਸ਼ੀਲ ਨਹੀਂ ਹੈ। ਪਰਿਵਰਤਨਸ਼ੀਲ ਇਹ ਹੈ ਕਿ ਐਪ ਦੀ ਪ੍ਰੋਸੈਸ ਨੂੰ ਹੱਲ ਲਈ ਕਿਹੜਾ ਨੈੱਟਵਰਕ ਵਰਤਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਅਤੇ Android ਇਸ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਕਿ ਸਰਗਰਮ VPN ਉਹੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਾਕਟ ਵਰਤਦੇ ਹਨ। ਇਹ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਜਦੋਂ 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 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਜੁੜਿਆ ਹੈ, ਅਤੇ VPN ਟ੍ਰਾਂਸਪੋਰਟ ਇਸ ਨੂੰ ਤਦ ਵੀ ਪੂਰਾ ਕਰਦਾ ਹੈ ਜਦੋਂ ਹੇਠਲੀ Wi-Fi ਜਾਂ ਸੈਲੂਲਰ ਲਿੰਕ ਚਲੀ ਗਈ ਹੋਵੇ। ਜੌਬ ਚੱਲਦੀ ਹੈ, ਹਰ ਬੇਨਤੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਰੀਟ੍ਰਾਈ ਨੀਤੀ ਇਸ ਨੂੰ ਸ਼ੈਡਿਊਲਿੰਗ ਬੱਗ ਵਰਗਾ ਤੂਫ਼ਾਨ ਬਣਾ ਦਿੰਦੀ ਹੈ। ਟਨਲ ਇੱਕ ਨੈੱਟਵਰਕ ਹੈ; ਇਹ ਰੁਕਾਵਟ ਕਦੇ ਇੰਟਰਨੈੱਟ ਜਾਂਚ ਨਹੀਂ ਸੀ।

ਉਹ ਸਮਰੱਥਾ ਜਾਂਚੋ ਜੋ ਕੰਮ ਨੂੰ ਅਸਲ ਵਿੱਚ ਚਾਹੀਦੀ ਹੈ, ਜਿਵੇਂ ਪ੍ਰਮਾਣਿਤ ਇੰਟਰਨੈੱਟ ਪਹੁੰਚ, ਅਤੇ ਬੈਕਆਫ਼ ਨਾਲ ਸੀਮਤ ਰੀਟ੍ਰਾਈ ਨੀਤੀ ਰੱਖੋ। ਜੇ ਜੌਬ ਨੂੰ ਨਿੱਜੀ ਨਾਮ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਕੰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਨਾਮ ਚੁਣੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਹੱਲ ਕਰੋ, ਅਤੇ ਜੋ ਬੇਨਤੀ ਸਫਲ ਨਹੀਂ ਹੋ ਸਕਦੀ ਉਸ ਨੂੰ ਦੁਹਰਾਉਣ ਦੀ ਬਜਾਏ ਸਪਸ਼ਟ ਗਲਤੀ ਨਾਲ ਜਲਦੀ ਫੇਲ੍ਹ ਹੋਵੋ।

ਕਦਮ 5: ਸਬੂਤ ਦਰਜ ਕਰੋ ਅਤੇ ਰੇਂਜ ਦੁਬਾਰਾ ਜਾਂਚੋ

ਚੁਣੇ ਨੈੱਟਵਰਕ ਦੇ ਟ੍ਰਾਂਸਪੋਰਟ ਕਿਸਮ, LinkProperties ਤੋਂ DNS ਸਰਵਰ, ਬਾਈਂਡ ਨੇ true ਵਾਪਸ ਕੀਤਾ ਕਿ ਨਹੀਂ, ਅਤੇ ਪਹਿਲੀ ਬੇਨਤੀ ਦੀ ਸਹੀ ਫੇਲ੍ਹਤਾ ਲੌਗ ਕਰੋ। ਫਿਰ ਉਸੇ ਬਾਈਂਡਿੰਗ ਹੇਠ ਨਿੱਜੀ ਨਾਮ ਅਤੇ ਜਨਤਕ ਨਾਮ ਚਲਾਓ। ਇਹ ਜੋੜੀ ਦੱਸਦੀ ਹੈ ਕਿ ਐਪ ਨੇ ਟਨਲ resolver ਵਰਤਿਆ ਜਾਂ ਚੁੱਪਚਾਪ ਡਿਵਾਈਸ ਦੇ ਡਿਫ਼ਾਲਟ 'ਤੇ ਵਾਪਸ ਚਲੀ ਗਈ, ਅਤੇ ਇਹੀ ਉਹ ਫ਼ਰਕ ਹੈ ਜੋ ਵਰਤੋਂਕਾਰ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ।

ਇਸ ਨੂੰ ਉਸ ਸਭ ਤੋਂ ਪੁਰਾਣੇ Android ਸੰਸਕਰਣ 'ਤੇ ਦੁਹਰਾਓ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਸਹਿਯੋਗ ਦਿੰਦੇ ਹੋ ਅਤੇ ਇੱਕ ਮੌਜੂਦਾ ਰਿਲੀਜ਼ 'ਤੇ। ਜੋ resolver ਵਿਵਹਾਰ ਡਿਫ਼ਾਲਟ ਰਾਹ ਨੂੰ ਸਹੀ ਦਿਸਦਾ ਹੈ, ਉਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਡਿਵਾਈਸ ਅਤੇ ਸੰਸਕਰਣ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਜੋ ਬਿਲਡ ਸਿਰਫ਼ ਨਵੇਂ ਟੈਸਟ ਡਿਵਾਈਸ 'ਤੇ ਪਾਸ ਹੁੰਦੀ ਹੈ, ਉਹ ਤੁਹਾਡੇ ਭੇਜੇ ਜਾਣ ਵਾਲੇ ਰੇਂਜ ਲਈ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ। adb shell dumpsys connectivity ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਕਿ ਫੇਲ੍ਹਤਾ ਦੁਹਰਾਉਂਦਿਆਂ ਡਿਵਾਈਸ ਕਿਹੜੇ ਨੈੱਟਵਰਕ ਅਤੇ ਸਮਰੱਥਾਵਾਂ ਦੱਸਦਾ ਹੈ।