ਜਦੋਂ ਹੋਰ VPN ਪਹਿਲਾਂ ਹੀ ਸਰਗਰਮ ਹੋਵੇ ਤਾਂ VpnService ਸੁਰੱਖਿਆ ਫੇਲ ਹੁੰਦੀ ਹੈ

ਤੁਹਾਡੀ ਐਪ VpnService.prepare ਕਾਲ ਕਰਦੀ ਹੈ, null ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ, ਇੱਕ ਟਨਲ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ ਡਿਸਕ੍ਰਿਪਟਰ ਵੈਧ ਦਿਸਦਾ ਹੈ, ਪਰ ਸਰਵਰ ਤੱਕ ਕੁਝ ਵੀ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਜਾਂ prepare ਇੱਕ Intent ਵਾਪਸ ਕਰਦਾ ਹੈ, ਵਰਤੋਂਕਾਰ ਇਸਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਅਤੇ establish ਫਿਰ ਵੀ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਦੋਵੇਂ ਨਤੀਜਿਆਂ ਦਾ ਅਰਥ ਆਮ ਤੌਰ ’ਤੇ ਇੱਕੋ ਹੁੰਦਾ ਹੈ: ਕੋਈ ਹੋਰ ਐਪ ਇਸ ਵਰਤੋਂਕਾਰ ਲਈ VPN ਇੰਟਰਫੇਸ ਪਹਿਲਾਂ ਹੀ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਤੁਹਾਡੀਆਂ protect ਕਾਲਾਂ ਅਜਿਹੇ ਸਾਕਟਾਂ ਨੂੰ ਨਿਸ਼ਾਨਿਤ ਕਰ ਰਹੀਆਂ ਹਨ ਜੋ ਤੁਹਾਡਾ ਟਨਲ ਵਰਤ ਨਹੀਂ ਸਕਦਾ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਪੂਰੀਆਂ ਕਰੋ ਅਤੇ ਫੇਲ ਹੋਣ ਵਾਲੀ ਪਹਿਲੀ ਜਾਂਚ ’ਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਦਾ ਕਦਮ ਪਹਿਲੇ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ।

protect ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ VPN ਸਲਾਟ ਜਾਂਚੋ

Android ਹਰ ਵਰਤੋਂਕਾਰ ਨੂੰ ਠੀਕ ਇੱਕ ਸਰਗਰਮ VPN ਇੰਟਰਫੇਸ ਦਿੰਦਾ ਹੈ। ਇਹ ਪਲੇਟਫਾਰਮ ਦਾ ਨਿਯਮ ਹੈ, ਤੁਹਾਡੀ ਐਪ ਮੰਗ ਸਕਣ ਵਾਲੀ ਆਗਿਆ ਨਹੀਂ, ਇਸ ਲਈ ਦੋਵੇਂ ਟਨਲ ਬਣਨਾ ਚਾਹੁਣ ਵਾਲੇ ਦੋ ਕਲਾਇੰਟ ਇਕੱਠੇ ਨਹੀਂ ਰਹਿ ਸਕਦੇ।

ਹੋਰ ਐਪ ਲਈ ਸੈੱਟ ਕੀਤਾ ਹਮੇਸ਼ਾ-ਚਾਲੂ VPN ਸਭ ਤੋਂ ਔਖਾ ਮਾਮਲਾ ਹੈ, ਕਿਉਂਕਿ ਸਿਸਟਮ ਉਸ ਐਪ ਨੂੰ ਜੁੜਿਆ ਰੱਖਦਾ ਹੈ ਅਤੇ ਕਬਜ਼ਾ ਲੈਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ। AdGuard ਵਰਗਾ ਟ੍ਰੈਫਿਕ ਫਿਲਟਰ, ਕਾਰਪੋਰੇਟ ਕਲਾਇੰਟ ਜਾਂ ਖਪਤਕਾਰ VPN ਸਲਾਟ ਰੱਖ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਵਰਤੋਂਕਾਰ ਭੁੱਲ ਚੁੱਕਾ ਹੋਵੇ ਕਿ ਇਹ ਇੰਸਟਾਲ ਹੈ। ਵਰਤੋਂਕਾਰ ਨੂੰ ਸੈਟਿੰਗਾਂ ਖੋਲ੍ਹ ਕੇ VPN ਹੇਠ ਸੂਚੀਬੱਧ ਐਂਟਰੀ ਪੜ੍ਹਨ ਲਈ ਕਹੋ; ਉੱਥੇ ਦਾ ਨਾਮ ਹੀ ਉਹ ਮਾਲਕ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਮੁਕਾਬਲਾ ਕਰ ਰਹੇ ਹੋ। ਜਦ ਤੱਕ ਉਹ ਐਂਟਰੀ ਡਿਸਕਨੈਕਟ ਨਹੀਂ ਹੁੰਦੀ ਜਾਂ ਹਮੇਸ਼ਾ-ਚਾਲੂ ਸੈਟਿੰਗ ਮਿਟਾਈ ਨਹੀਂ ਜਾਂਦੀ, ਤੁਹਾਡਾ VpnService ਇੰਟਰਫੇਸ ਨਹੀਂ ਬਣ ਸਕਦਾ।

ਕਦਮ 1: prepare ਕੀ ਵਾਪਸ ਕਰਦਾ ਹੈ ਪੜ੍ਹੋ

VpnService.prepare ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੀ ਇਹ ਐਪ VPN ਬਣ ਸਕਦੀ ਹੈ? ਜੇ ਸਹਿਮਤੀ ਪਹਿਲਾਂ ਹੀ ਹੈ ਤਾਂ ਇਹ null ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਅਜੇ ਮਨਜ਼ੂਰੀ ਦੇਣੀ ਹੈ ਤਾਂ Intent ਦਿੰਦਾ ਹੈ, ਜਿਸਨੂੰ ਤੁਹਾਨੂੰ startActivityForResult ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। null ਵਾਪਸੀ ਨੂੰ ਅੱਗੇ ਵਧਣ ਦੀ ਆਗਿਆ ਮੰਨੋ, establish ਸਫਲ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ।

Intent intent = VpnService.prepare(context);
if (intent != null) {
    startActivityForResult(intent, REQUEST_VPN);
}

ਜੇ Intent ਮਾਰਗ ਵਾਪਸ ਆਉਂਦਾ ਹੈ ਅਤੇ ਵਰਤੋਂਕਾਰ ਨੇ ਇਨਕਾਰ ਕੀਤਾ, ਤਾਂ ਅਗਲੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ prepare ਫਿਰ Intent ਵਾਪਸ ਕਰਦਾ ਰਹੇਗਾ। ਲੂਪ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ ਨਤੀਜਾ ਕੋਡ ਲੌਗ ਕਰੋ, ਕਿਉਂਕਿ ਇਨਕਾਰ ਕੀਤੀ ਸਹਿਮਤੀ ਵਰਤੋਂਕਾਰ ਦਾ ਫੈਸਲਾ ਹੈ, ਆਰਜ਼ੀ ਗਲਤੀ ਨਹੀਂ।

ਕਦਮ 2: ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇੰਟਰਫੇਸ ਤੁਹਾਡੀ ਐਪ ਦਾ ਹੈ

establish ਤੋਂ ਬਾਅਦ ਮਿਲਣ ਵਾਲਾ ParcelFileDescriptor ਤੁਹਾਡੀ ਮਾਲਕੀ ਦਾ ਸਬੂਤ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਸਾਕਟ ਕੰਮ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਜਾਂਚਣਾ ਚਾਹੀਦਾ ਹੈ। null ਜਾਂ ਪਹਿਲਾਂ ਹੀ ਬੰਦ ਡਿਸਕ੍ਰਿਪਟਰ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੰਟਰਫੇਸ ਕਦੇ ਬਣਿਆ ਹੀ ਨਹੀਂ, ਭਾਵੇਂ ਕੋਈ ਅਪਵਾਦ ਨਾ ਆਇਆ ਹੋਵੇ। builder ਦਾ ਇੰਟਰਫੇਸ ਨਾਮ ਸਿਸਟਮ ਵੱਲੋਂ ਸਰਗਰਮ VPN ਲਈ ਦੱਸੇ ਨਾਮ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਟੈਸਟ ਡਿਵਾਈਸ ’ਤੇ dumpsys ਵਰਤ ਕੇ। ਜੇ ਉਹ ਵੱਖਰੇ ਹਨ, ਤਾਂ ਤੁਹਾਡਾ ਬਣਾਇਆ ਟਨਲ ਟ੍ਰੈਫਿਕ ਢੋਣ ਵਾਲਾ ਟਨਲ ਨਹੀਂ ਹੈ।

adb shell dumpsys connectivity

ਇਹੀ ਅਸੰਗਤੀ ਜੁੜੇ ਆਈਕਨ ਨਾਲ ਮਰੇ ਟ੍ਰੈਫਿਕ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ। ਸਿਸਟਮ ਹੋਰ ਐਪ ਦਾ ਟਨਲ ਦਿਖਾਉਂਦਾ ਹੈ, ਜਦਕਿ ਤੁਹਾਡਾ ਕੋਡ ਆਪਣੀ ਮਾਲਕੀ ਵਾਲੇ ਨਾ ਹੋਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਦਾ ਡਿਸਕ੍ਰਿਪਟਰ ਰੱਖਦਾ ਹੈ।

ਕਦਮ 3: connect ਤੋਂ ਪਹਿਲਾਂ protect ਕਾਲ ਕਰੋ

ਇੰਟਰਫੇਸ ਬਣਨ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਡੀ ਐਪ ਵੱਲੋਂ ਖੋਲ੍ਹੇ ਸਾਕਟ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਟਨਲ ਵਿੱਚ ਰੂਟ ਹੁੰਦੇ ਹਨ। ਬਾਹਰੀ ਟਰਾਂਸਪੋਰਟ ਇਹ ਨਿਯਮ ਨਹੀਂ ਮੰਨ ਸਕਦਾ, ਨਹੀਂ ਤਾਂ ਇਨਕੈਪਸੂਲੇਟਡ ਪੈਕੇਟ ਇੰਟਰਫੇਸ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਵੇਗਾ, ਇਸ ਲਈ VpnService protect ਸਾਕਟ ਨੂੰ VPN ਬਾਈਪਾਸ ਕਰਕੇ ਹੇਠਲਾ ਨੈੱਟਵਰਕ ਵਰਤਣ ਲਈ ਨਿਸ਼ਾਨਿਤ ਕਰਦਾ ਹੈ। ਕਾਲ boolean ਵਾਪਸ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਹੀ ਸਿਹਤਮੰਦ ਦਿਸਦੇ ਪਰ ਕੁਝ ਨਾ ਢੋਣ ਵਾਲੇ ਸਾਕਟ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਰਾਹ ਹੈ।

connect ਜਾਂ bind ਤੋਂ ਪਹਿਲਾਂ protect ਕਾਲ ਕਰੋ, ਕਦੇ ਵੀ ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ। ਸਾਕਟ ਜੁੜਨ ਜਾਂ ਬੱਝਣ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਆ ਥਾਂ ’ਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਜੁੜੇ ਸਾਕਟ ਨੇ ਆਪਣਾ ਰਾਹ ਪਹਿਲਾਂ ਹੀ ਚੁਣ ਲਿਆ ਹੁੰਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਦਾ protect ਇਸਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਨਹੀਂ ਹਿਲਾਉਂਦਾ। ਜੇ protect false ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਮਾਲਕੀ ਦੁਬਾਰਾ ਜਾਂਚੋ: ਇਹ ਉਦੋਂ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੰਟਰਫੇਸ ਤੁਹਾਡੀ ਐਪ ਦਾ ਨਹੀਂ, ਅਤੇ ਇਹੀ ਅਵਸਥਾ ਹੋਰ VPN ਛੱਡ ਜਾਂਦਾ ਹੈ। false ਦੀ ਵਾਪਸੀ ਕਦਮ 1 ’ਤੇ ਵਾਪਸ ਜਾਣ ਦਾ ਸੰਕੇਤ ਹੈ, ਉਹੀ ਸਾਕਟ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਨਹੀਂ।

DatagramSocket socket = new DatagramSocket();
if (!vpnService.protect(socket)) {
    return;
}
socket.connect(serverAddress, serverPort);

ਕਦਮ 4: ਸਾਕਟ ਮੁਸ਼ਕਲ ਹੋਵੇ ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਬੰਨ੍ਹੋ

ਕੁਝ ਟਰਾਂਸਪੋਰਟ ਇੱਕ ਸਾਕਟ ਨਹੀਂ ਹੁੰਦੇ: ਲਾਇਬ੍ਰੇਰੀ ਕਈ ਖੋਲ੍ਹ ਸਕਦੀ ਹੈ, ਜਾਂ ਤੁਸੀਂ ਚਾਹੋ ਕਿ ਸਹਾਇਕ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹਰ ਕਨੈਕਸ਼ਨ ਇੱਕੋ ਨਿਕਾਸ ਵਰਤੇ। ConnectivityManager.bindProcessToNetwork ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਚੁਣੇ ਨੈੱਟਵਰਕ ਨਾਲ ਬੰਨ੍ਹਦਾ ਹੈ, ਅਤੇ ਪੁਰਾਣਾ setProcessDefaultNetwork ਵੀ ਇਹੀ ਕੰਮ ਕਰਦਾ ਸੀ, ਅਪਰਚਿਤ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ। ਹੇਠਲਾ ਕਨੈਕਸ਼ਨ NET_CAPABILITY_NOT_VPN ਨਾਲ ਮੰਗੋ ਤਾਂ ਜੋ ਬੰਧਨ ਤੁਹਾਡੇ ਟਨਲ ਹੇਠਲਾ ਨੈੱਟਵਰਕ ਚੁਣੇ, ਟਨਲ ਖੁਦ ਨਹੀਂ।

NetworkRequest request = new NetworkRequest.Builder()
    .addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    .addCapability(NetworkCapabilities.NET_CAPABILITY_NOT_VPN)
    .build();

ਪ੍ਰਕਿਰਿਆ ਬੰਨ੍ਹਣਾ ਦੂਜਾ VPN ਨਹੀਂ ਹੈ। ਇਹ ਉਸ ਪ੍ਰਕਿਰਿਆ ਲਈ ਨਿਕਾਸ ਚੁਣਦਾ ਹੈ, ਜੋ ਤੁਹਾਡੇ ਟਰਾਂਸਪੋਰਟ ਲਈ ਲਾਭਦਾਇਕ ਹੈ ਅਤੇ ਇੱਕੋ ਸਮੇਂ ਦੋ ਟਨਲ ਚਲਾਉਣ ਲਈ ਬੇਕਾਰ।

ਕੋਡ ਦਾ ਰਾਹ ਨਹੀਂ, ਵਰਤੋਂਕਾਰ ਦਾ ਡਿਵਾਈਸ ਠੀਕ ਕਰੋ

ਅਜਿਹਾ ਕੋਈ API ਨਹੀਂ ਜੋ ਦੋ ਐਪਾਂ ਨੂੰ VPN ਸਲਾਟ ਸਾਂਝਾ ਕਰਨ ਦੇਵੇ, ਇਸ ਲਈ ਸੁਧਾਰ ਡਿਵਾਈਸ ਦੀ ਅਵਸਥਾ ਵਿੱਚ ਹੈ। ਵਰਤੋਂਕਾਰ ਨੂੰ ਦੋ ਠੋਸ ਰਾਹ ਦਿਓ: ਹੋਰ ਐਪ ਦਾ ਕਨੈਕਸ਼ਨ ਕੱਟੋ ਜਾਂ ਉਸਦਾ ਹਮੇਸ਼ਾ-ਚਾਲੂ ਮਿਟਾਓ ਤਾਂ ਜੋ ਤੁਹਾਡਾ prepare ਕਬਜ਼ਾ ਲੈ ਸਕੇ, ਜਾਂ ਉਸ ਐਪ ਦੀਆਂ ਪ੍ਰਤੀ-ਐਪ ਸੈਟਿੰਗਾਂ ਖੋਲ੍ਹ ਕੇ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਉਸਦੇ ਟਨਲ ਤੋਂ ਬਾਹਰ ਰੱਖੋ। ਬਾਹਰ ਕੱਢਣਾ ਬਾਕੀ ਸਭ ਲਈ ਫਿਲਟਰ ਚਾਲੂ ਰੱਖਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਆਮ ਕਨੈਕਸ਼ਨ ਵਰਤਣ ਦਿੰਦਾ ਹੈ, ਜੋ ਅਕਸਰ ਵਰਤੋਂਕਾਰ ਦਾ ਅਸਲੀ ਚਾਹਿਆ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ।

ਦੋਵੇਂ ਰਾਹ ਆਪਣੇ ਸਹਾਇਤਾ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਲਿਖੋ, ਕਿਉਂਕਿ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਘੱਟ ਹੀ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਐਪ VPN ਦੀ ਮਾਲਕ ਹੈ। ਉਨ੍ਹਾਂ ਨੂੰ ਸੈਟਿੰਗਾਂ ਤੋਂ ਸਰਗਰਮ VPN ਨਾਮ ਅਤੇ ਤੁਹਾਡੇ ਲੌਗ ਤੋਂ prepare, establish ਅਤੇ protect ਦੇ ਨਤੀਜੇ ਭੇਜਣ ਲਈ ਕਹੋ, ਅਤੇ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜਾ ਕਦਮ ਫੇਲ ਹੋਇਆ। ਫਿਰ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ: ਨਾਮ ਖੋਜ, TCP ਕਨੈਕਸ਼ਨ ਅਤੇ ਟਨਲ ਰਾਹੀਂ ਇੱਕ ਬੇਨਤੀ, ਸਿਰਫ ਜੁੜਿਆ ਆਈਕਨ ਨਹੀਂ। ਵੈਧ ਡਿਸਕ੍ਰਿਪਟਰ ਅਤੇ ਹਰਾ ਸੰਕੇਤਕ ਵੱਧ ਤੋਂ ਵੱਧ ਮਾਲਕੀ ਸਾਬਤ ਕਰਦੇ ਹਨ, ਟਰਾਂਸਪੋਰਟ ਰੂਟਿੰਗ ਨਿਯਮਾਂ ਤੋਂ ਬਚਿਆ ਇਹ ਕਦੇ ਨਹੀਂ।

ਜੇ ਚਾਰੇ ਜਾਂਚਾਂ ਪਾਸ ਹੋਣ ਅਤੇ ਟ੍ਰੈਫਿਕ ਫਿਰ ਵੀ ਮਰੇ, ਤਾਂ ਮਾਲਕੀ ਹੁਣ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਨਹੀਂ। ਰੂਟਿੰਗ ਅਤੇ ਸਰਵਰ ਪਹੁੰਚ ਵੱਲ ਵਧੋ, ਅਤੇ VPN ਐਪ ਇੰਸਟਾਲ ਨਾ ਹੋਣ ਵਾਲੇ ਡਿਵਾਈਸ ਤੋਂ ਉਹੀ ਪ੍ਰਮਾਣ ਪੱਤਰ ਜਾਂਚੋ।