ਤੁਹਾਡਾ Android VpnService ਟਨਲ ਟ੍ਰੈਫਿਕ ਰਾਊਟਿੰਗ ਕਿਉਂ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ

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

ਮਿੱਥ 1: ਟਨਲ ਤਦ ਤੱਕ ਖੜ੍ਹੀ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਬੰਦ ਨਹੀਂ ਕਰਦੇ

Android ਇੱਕ ਸਮੇਂ ਇੱਕ VPN ਇੰਟਰਫੇਸ ਰੱਖਦਾ ਹੈ। ਦੂਜਾ ਸਥਾਪਿਤ ਕਰੋ ਅਤੇ ਪਲੇਟਫਾਰਮ ਇਸਨੂੰ ਕਤਾਰ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦਾ, ਸਗੋਂ ਤੁਹਾਡਾ ਅਕਿਰਿਆਸ਼ੀਲ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਸੇਵਾ ਉੱਤੇ onRevoke() ਬੁਲਾਉਂਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਕੋਡ ਸਿਰਫ਼ ਬਟਨ ਦਬਾਉਣ ਉੱਤੇ ਸਭ ਕੁਝ ਢਾਹੁੰਦਾ ਹੈ, ਤਾਂ ਕਬਜ਼ਾ ਪਿੱਛੇ ਇੱਕ ਡਿਸਕ੍ਰਿਪਟਰ ਅਤੇ ਇੱਕ ਰੀਡਰ ਥ੍ਰੈਡ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਅਗਲੀ ਸ਼ੁਰੂਆਤ ਦੋਵੇਂ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈ ਲੈਂਦੀ ਹੈ।

VpnService ਹਵਾਲਾ ਸਪਸ਼ਟ ਕਹਿੰਦਾ ਹੈ ਕਿ ਜੇ ਐਪ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸਹਿਮਤੀ ਹੈ ਤਾਂ prepare() null ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੇ ਵਰਤੋਂਕਾਰ ਨੇ ਅਜੇ ਮਨਜ਼ੂਰੀ ਦੇਣੀ ਹੈ ਤਾਂ Intent ਵਾਪਸ ਕਰਦਾ ਹੈ। ਉਹ ਸਹਿਮਤੀ ਤਦ ਹੀ ਪਹੁੰਚਦੀ ਹੈ ਜੇ ਤੁਸੀਂ ਇਰਾਦਾ startActivityForResult() ਰਾਹੀਂ ਪਹੁੰਚਾਓ। ਇਹ ਹਸਤਾਂਤਰਣ ਛੱਡੋ ਅਤੇ establish() null ਵਾਪਸ ਕਰਦਾ ਹੈ, ਜਿਸਨੂੰ ਇਜਾਜ਼ਤ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਸਗੋਂ ਚੁੱਪ ਅਸਫਲਤਾ ਵਜੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ।

Always-on VPN ਇੱਕ ਮਾਲਕ ਜੋੜਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰਦੇ। ਸਿਸਟਮ ਬੂਟ ਤੋਂ ਬਾਅਦ ਜਾਂ ਕ੍ਰੈਸ਼ ਤੋਂ ਬਾਅਦ ਟਨਲ ਵਾਪਸ ਲਿਆ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਵਰਤੋਂਕਾਰ ਦੁਆਰਾ ਹੱਥੋਂ ਸ਼ੁਰੂ ਕੀਤੀ VPN ਐਪ ਨੂੰ ਪਿੱਛੇ ਕਰ ਦਿੰਦਾ ਹੈ। onRevoke() ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਓ ਕਿ ਇਹ ਤੁਹਾਡੇ ਆਮ ਬੰਦ ਵਾਂਗ ਹੀ ਸਰੋਤ ਬੰਦ ਕਰੇ, ਅਤੇ ਇਸਨੂੰ ਕੋਨੇ ਦਾ ਕੇਸ ਨਹੀਂ ਸਗੋਂ ਮੁੱਖ ਰੋਕਣ ਵਾਲਾ ਰਾਹ ਮੰਨੋ। ਵਰਤੋਂਕਾਰ VPN ਐਪਾਂ ਬਦਲਦੇ ਹਨ; ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਇਹ ਸਹਿਣਾ ਪਵੇਗਾ।

ਮਿੱਥ 2: addRoute ਬਿਲਕੁਲ ਉਹੀ ਫੜਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸੂਚੀਬੱਧ ਕੀਤਾ

ਰਾਊਟ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜੇ ਪੈਕਟ ਤੁਹਾਡੇ ਡਿਸਕ੍ਰਿਪਟਰ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ, ਅਤੇ ਦਾਇਰੇ ਦੀ ਗਲਤੀ ਉਹ ਖਿੱਝ ਭਰੀ ਸਥਿਤੀ ਬਣਾਉਂਦੀ ਹੈ ਜਿੱਥੇ ਕੁਝ ਟ੍ਰੈਫਿਕ ਟਨਲ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ ਅਤੇ ਕੁਝ ਨਹੀਂ। addRoute("0.0.0.0", 0) ਸਾਰਾ IPv4 ਲੈ ਲੈਂਦਾ ਹੈ, ਭਾਵ ਹੁਣ ਹਰ ਪੈਕਟ ਤੁਹਾਡੇ ਕੋਲ ਆਉਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਅੱਗੇ ਭੇਜਣਾ ਜਾਂ ਸੁੱਟਣਾ ਪੈਂਦਾ ਹੈ। ਇੱਕ ਹੋਸਟ ਲਈ /32 ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਲੈਂਦਾ, ਅਤੇ ਬਾਕੀ ਸਭ ਇੰਝ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਤੁਹਾਡਾ VPN ਕਦੇ ਸਥਾਪਿਤ ਹੀ ਨਹੀਂ ਹੋਇਆ।

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

DNS ਵੀ ਉਹੀ ਤਰਕ ਅਪਣਾਉਂਦਾ ਹੈ। addDnsServer() ਨਾਲ ਜੋੜੇ ਸਰਵਰ ਉਨ੍ਹਾਂ ਐਪਾਂ ਕੋਲ ਜਾਂਦੇ ਹਨ ਜੋ ਟਨਲ ਦਾ ਰਿਜ਼ੋਲਵਰ ਵਰਤਦੀਆਂ ਹਨ, ਜਦੋਂ ਕਿ ਆਪਣਾ ਇਨਕ੍ਰਿਪਟਿਡ DNS ਐਂਡਪੌਇੰਟ ਜਾਂ ਹੋਸਟਨਾਮ ਉੱਤੇ ਸੈੱਟ Private DNS ਵਾਲੀ ਐਪ ਉਨ੍ਹਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਗੌਲਿਆ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਨਾਮ ਇੱਕ ਐਪ ਲਈ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ ਅਤੇ ਦੂਜੀ ਲਈ ਕੰਮ ਕਰਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਵੀ ਰਾਊਟ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਰਿਜ਼ੋਲਵਰ ਦਾ ਰਾਹ ਜਾਂਚੋ।

ਮਿੱਥ 3: ਪ੍ਰਤੀ-ਐਪ ਨਿਯਮ ਇੱਕ ਸਵਿੱਚ ਹਨ ਜਿਸਨੂੰ ਤੁਸੀਂ ਦੋਵੇਂ ਪਾਸੇ ਘੁੰਮਾ ਸਕਦੇ ਹੋ

addDisallowedApplication() ਅਤੇ addAllowedApplication() ਦੋ ਫਿਲਟਰ ਨਹੀਂ, ਦੋ ਮੋਡ ਹਨ। ਬਿਲਡਰ ਪ੍ਰਤੀ ਟਨਲ ਇੱਕ ਮਾਡਲ ਸਵੀਕਾਰਦਾ ਹੈ, ਇਸ ਲਈ ਤਿੰਨ ਪੈਕੇਜਾਂ ਤੋਂ ਬਿਨਾਂ ਸਭ ਕੁਝ ਚਾਹੁਣ ਵਾਲੀ ਐਪ ਪਾਬੰਦੀਸ਼ੁਦਾ ਸੂਚੀ ਵਰਤਦੀ ਹੈ ਅਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸੂਚੀ ਖਾਲੀ ਛੱਡਦੀ ਹੈ। ਦੋਵੇਂ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਰੱਦ ਕਰਦੇ ਹਨ, ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਇਹ ਰਨਟਾਈਮ ਵਿੱਚ ਤਦ ਪਤਾ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਸੈਟਿੰਗਾਂ ਸਕ੍ਰੀਨ ਪਹਿਲਾਂ ਹੀ ਦੋਵੇਂ ਟੌਗਲ ਦਿਖਾ ਚੁੱਕੀ ਹੁੰਦੀ ਹੈ।

ਪੈਕੇਜ ਦਿੱਖ ਵੀ ਡੰਗਦੀ ਹੈ। Android 11 ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ ਸਿਰਫ਼ ਉਹੀ ਪੈਕੇਜ ਨਾਮ ਦੇ ਸਕਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਇਸ ਲਈ ਜਿਸ ਕਵੈਰੀ ਨੂੰ ਚਲਾਉਣ ਦੀ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਇਜਾਜ਼ਤ ਨਹੀਂ ਉਸ ਤੋਂ ਬਣੀ ਬਾਹਰ ਕੱਢਣ ਵਾਲੀ ਸੂਚੀ ਚੁੱਪਚਾਪ ਐਂਟਰੀਆਂ ਖੁੰਝਾ ਦੇਵੇਗੀ। ਸੂਚੀ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੀ ਤੁਲਨਾ ਕਰੋ ਕਿ ਪੈਕੇਜ ਮੈਨੇਜਰ ਅਸਲ ਵਿੱਚ ਕੀ ਵਾਪਸ ਕਰਦਾ ਹੈ।

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

ਮਿੱਥ 4: stopSelf ਟਨਲ ਖ਼ਤਮ ਕਰਦਾ ਹੈ

ਨਹੀਂ ਕਰਦਾ। ਇੰਟਰਫੇਸ ਉਸ ਡਿਸਕ੍ਰਿਪਟਰ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ ਜੋ establish() ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਡਿਸਕ੍ਰਿਪਟਰ ਖੁੱਲ੍ਹਾ ਰਹਿੰਦਿਆਂ ਸੇਵਾ ਆਬਜੈਕਟ ਮਰ ਸਕਦਾ ਹੈ। ਪਹਿਲਾਂ ParcelFileDescriptor ਬੰਦ ਕਰੋ, ਹਵਾਲਾ ਛੱਡੋ, ਰੀਡਰ ਅਤੇ ਰਾਈਟਰ ਥ੍ਰੈਡ ਜੋੜੋ ਜਾਂ ਰੋਕੋ, ਫਿਰ stopForeground(true) ਅਤੇ stopSelf() ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਬੁਲਾਓ।

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

ਉਲਟੀ ਗਲਤੀ ਵੀ ਓਨੀ ਹੀ ਆਮ ਹੈ: ਰੀਡਰ ਥ੍ਰੈਡ ਪੜ੍ਹਨ ਦੇ ਵਿਚਕਾਰ ਹੋਵੇ ਤਾਂ ਡਿਸਕ੍ਰਿਪਟਰ ਬੰਦ ਕਰਨਾ, ਅਤੇ ਫਿਰ ਉਸ ਥ੍ਰੈਡ ਨੂੰ ਉਹ ਅਪਵਾਦ ਸੰਭਾਲਣ ਦੇਣਾ ਜਿਸਦਾ ਕਿਸੇ ਨੇ ਕੋਡ ਨਹੀਂ ਲਿਖਿਆ। ਸ਼ਟਡਾਊਨ ਕ੍ਰਮ ਇੱਕ ਥਾਂ ਰੱਖੋ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦੀ ਕਿਰਿਆ ਤੇ onRevoke() ਦੋਵੇਂ ਉਸ ਵਿੱਚ ਬੁਲਾਉਣ।

ਟਨਲ ਮਰੀ ਹੋਈ ਦਿਸੇ ਤਾਂ ਕੀ ਜਾਂਚਣਾ ਹੈ

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

establish() ਦਾ ਨਤੀਜਾ, ਰਾਊਟ, ਬਾਹਰ ਕੱਢੇ ਪੈਕੇਜ ਅਤੇ ਬੰਦ ਕਰਨ ਦਾ ਕਾਰਨ ਲੌਗ ਕਰੋ। ਉਹ ਚਾਰ ਲਾਈਨਾਂ ਪੈਕਟ ਕੈਪਚਰ ਤੋਂ ਬਿਨਾਂ ਸਹਿਮਤੀ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਦਾਇਰੇ ਦੀ ਸਮੱਸਿਆ ਅਤੇ ਜੀਵਨ-ਚੱਕਰ ਦੀ ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਦੀਆਂ ਹਨ।