Android VPN: VpnService ਡਿਸਕ੍ਰਿਪਟਰ ਬਨਾਮ root tun ਡਿਵਾਈਸ

ਦੋ ਰਾਹ Android ਐਪ ਦੇ ਸਾਹਮਣੇ IP ਇੰਟਰਫੇਸ ਲਗਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਬਹੁਤ ਵੱਖਰੇ ਮਾਲਕਾਂ ਵਾਲੇ ਇੱਕੋ ਕਿਸਮ ਦੇ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ 'ਤੇ ਖ਼ਤਮ ਹੁੰਦੇ ਹਨ। ਇੱਕ VpnService ਅਤੇ ਉਸ ਦੇ builder ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ, ਦੂਜਾ root ਸ਼ੈੱਲ ਅਤੇ /dev/net/tun ਰਾਹੀਂ। ਉਸ ਡਿਸਕ੍ਰਿਪਟਰ 'ਤੇ ਹਰ ਪੜ੍ਹਤ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਪੈਕੇਟ ਹੈ ਅਤੇ ਹਰ ਲਿਖਤ ਅੰਦਰ ਆਉਣ ਵਾਲਾ। ਰਾਹਾਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ ਕਿ ਨੀਤੀ ਕਿਸ ਕੋਲ ਹੈ, OS ਅੱਪਗ੍ਰੇਡ ਕੌਣ ਝੱਲਦਾ ਹੈ, ਅਤੇ ਰੂਟਿੰਗ ਟੇਬਲ ਵਿੱਚੋਂ ਕਿੰਨਾ ਤੁਸੀਂ ਛੂਹ ਸਕਦੇ ਹੋ।

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

ਪਲੇਟਫਾਰਮ ਦੇ ਰਾਹ 'ਤੇ ਤੁਸੀਂ ਹੁਕਮਾਂ ਦੀ ਥਾਂ ਇਰਾਦਾ ਐਲਾਨਦੇ ਹੋ। ਤੁਸੀਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਪਤਾ, ਲੋੜੀਂਦੇ ਰੂਟ, DNS ਸਰਵਰ ਅਤੇ ਲਾਜ਼ਮੀ ਨਾ ਹੋਣ ਵਾਲੀ ਐਪ ਸੂਚੀ ਦਿੰਦੇ ਹੋ, ਫਿਰ Android ਦੀ ਸਿਸਟਮ ਸੇਵਾ ਆਪਣੀ ਪਛਾਣ ਹੇਠ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲਾ ਸੈੱਟਅੱਪ ਕਰਦੀ ਹੈ। ਤੁਸੀਂ ਇੰਟਰਫੇਸ ਦਾ ਨਾਂ ਪਹਿਲਾਂ ਕਦੇ ਨਹੀਂ ਜਾਣਦੇ, ਅਤੇ ਉਹ ਬਣਾਉਣ ਵਾਲਾ ioctl ਕਦੇ ਨਹੀਂ ਕੱਢਦੇ, ਅਤੇ ਇਹੀ ਗੱਲ ਹੈ।

IP ਇੰਟਰਫੇਸ ਪਾਉਣ ਦੇ ਦੋ ਤਰੀਕੇ

root ਰਾਹ ਪੁਰਾਣਾ ਤਰੀਕਾ ਹੈ। ਤੁਸੀਂ /dev/net/tun ਖੋਲ੍ਹਦੇ ਹੋ, IFF_TUN ਨਾਲ TUNSETIFF ਬੁਲਾਉਂਦੇ ਹੋ, ip link ਨਾਲ ਇੰਟਰਫੇਸ ਉੱਪਰ ਚੁੱਕਦੇ ਹੋ, ਅਤੇ ਪਤੇ ਤੇ ਰੂਟ ਹੱਥੀਂ ਜੋੜਦੇ ਹੋ। ਹਰ ਕਦਮ ਤੁਹਾਨੂੰ ਸਹੀ ਕਰਨਾ ਹੈ, ਉਹ ਵੀ ਜੋ ਫਰੇਮਵਰਕ ਚੁੱਪਚਾਪ ਨਿਭਾ ਦਿੰਦਾ। ਇੱਕ ਰੂਟ ਖੁੰਝਿਆ ਤਾਂ ਵਰਤੋਂਕਾਰ ਨੂੰ ਮਰੇ ਸਰਵਰ ਵਰਗੀ ਹੀ ਰਿਪੋਰਟ ਮਿਲਦੀ ਹੈ।

ਡੀਬੱਗਿੰਗ ਸੈੱਟਅੱਪ ਜਿੰਨੀ ਹੀ ਵੱਖਰੀ ਹੈ। root ਰਾਹ 'ਤੇ ਇੰਟਰਫੇਸ ਜਾਂ ਤਾਂ ਹੈ ਜਾਂ ਤੁਹਾਡੇ ioctl ਨੇ ਸਿੱਧੀ ਪੜ੍ਹੀ ਜਾ ਸਕਣ ਵਾਲੀ ਗਲਤੀ ਦਿੱਤੀ ਹੈ। ਪਲੇਟਫਾਰਮ ਦੇ ਰਾਹ 'ਤੇ ਇੰਟਰਫੇਸ establish() ਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਅਸਫਲਤਾ ਡਿਵਾਈਸ ਨੋਡ ਦੀ ਥਾਂ ਐਕਸੈਪਸ਼ਨ ਜਾਂ null ਡਿਸਕ੍ਰਿਪਟਰ ਵਜੋਂ ਆਉਂਦੀ ਹੈ, ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਟੋਹ ਸਕਦੇ ਹੋ।

establish() ਅਸਲ ਵਿੱਚ ਕੀ ਦਿੰਦਾ ਹੈ

Builder.establish() ਦੇ ਤਿੰਨ ਨਤੀਜੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਤਿੰਨ ਵੱਖਰੇ ਜਵਾਬ ਚਾਹੀਦੇ ਹਨ। ਡਿਸਕ੍ਰਿਪਟਰ ਦਾ ਮਤਲਬ ਹੈ ਇੰਟਰਫੇਸ ਤਿਆਰ ਹੈ ਅਤੇ ਵਰਤੋਂ ਲਈ ਤੁਹਾਡਾ ਹੈ, null ਦਾ ਮਤਲਬ ਬੇਨਤੀ ਪਾਰ ਨਹੀਂ ਹੋਈ, ਅਤੇ ਸੁੱਟਿਆ ਐਕਸੈਪਸ਼ਨ ਦਾ ਮਤਲਬ ਸਿਸਟਮ ਸੇਵਾ ਨੇ ਇਨਕਾਰ ਕੀਤਾ। null ਅਤੇ ਸਫਲਤਾ ਨੂੰ ਇੱਕ boolean ਵਿੱਚ ਮਿਲਾ ਦੇਣਾ ਉਹ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਐਪ ਕਦੇ ਪੈਕੇਟ ਨਾ ਢੋਣ ਵਾਲੀ ਚੱਲਦੀ ਟਨਲ ਦੀ ਰਿਪੋਰਟ ਦਿੰਦੀ ਹੈ। Builder ਹਵਾਲਾ ਪਤੇ ਦੀ ਸ਼ਰਤ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਨੂੰ ਪੜ੍ਹਨਾ ਚੰਗਾ ਹੈ।

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

Binder ਇੱਕ ਕਦਮ ਹੈ, JNI ਦੂਜਾ ਧੁਰਾ

builder ਬੇਨਤੀ Binder ਰਾਹੀਂ ਸਿਸਟਮ ਵਿੱਚ ਵੜਦੀ ਹੈ, ਅਤੇ ਉਸ ਦੇ ਹੇਠਾਂ ਕਿਤੇ ਪਲੇਟਫਾਰਮ ਡਿਵਾਈਸ ਤਿਆਰ ਕਰਨ ਲਈ ਨੇਟਿਵ ਕੋਡ ਬੁਲਾਉਂਦਾ ਹੈ। ਇਹ ਇੱਕੋ ਕਾਲ ਵਿੱਚ ਤਹਿ ਕੀਤੇ ਦੋ ਵੱਖਰੇ ਕਾਰਜ ਹਨ। Binder ਤੁਹਾਡੇ ਐਪ ਅਤੇ ਸਿਸਟਮ ਸੇਵਾ ਵਿਚਕਾਰ ਅੰਤਰ-ਪ੍ਰਕਿਰਿਆ ਸੰਚਾਰ ਹੈ, ਜਦੋਂ ਕਿ JNI ਪ੍ਰਕਿਰਿਆ ਦੇ ਅੰਦਰ Java ਤੋਂ ਨੇਟਿਵ ਤੱਕ ਦਾ ਪੁਲ ਹੈ। Android 9 AOSP ਰੁੱਖ ਪੜ੍ਹਨ ਨਾਲ ਸਟੈਕ ਸ਼ਬਦੀ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਯਾਦ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅੰਦਰੂਨੀ ਕਲਾਸ ਨਾਂ ਅਤੇ ਫਾਈਲ ਰਾਹ ਰਿਲੀਜ਼ਾਂ ਵਿਚਕਾਰ ਬਦਲਦੇ ਹਨ।

ਜੋ ਨਹੀਂ ਬਦਲਦਾ ਉਹ ਸਮਝੌਤਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ: builder, ਉਹ ਡਿਸਕ੍ਰਿਪਟਰ ਜੋ ਇਹ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਉਸ ਦੁਆਲੇ ਦੀ ਸੇਵਾ ਜੀਵਨ-ਚੱਕਰ। ਕੋਈ ਵੀ ਐਪ ਇੰਟਰਫੇਸ ਪਾਉਣ ਲਈ ਅੰਦਰੂਨੀ ਸੇਵਾ ਲੈਣ-ਦੇਣ ਨਹੀਂ ਬੁਲਾਉਣੀ ਚਾਹੀਦੀ ਜਾਂ ਡਿਵਾਈਸ ਨੋਡ ਮੁੜ ਨਹੀਂ ਬਣਾਉਣੀ ਚਾਹੀਦੀ। ਜੇ ਤੁਹਾਡਾ ਕੋਡ AOSP ਕਲਾਸ ਨਾਂ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਇਹ ਉਸ ਰਿਲੀਜ਼ 'ਤੇ ਟੁੱਟੇਗਾ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਪਰਖਿਆ।

TUN IP ਢੋਂਦਾ ਹੈ, TAP Ethernet

TUN ਇੱਕ IP ਇੰਟਰਫੇਸ ਹੈ। TAP ਇੱਕ Ethernet ਇੰਟਰਫੇਸ ਹੈ, ਅਤੇ ਇਹੀ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਬ੍ਰਿਜਿੰਗ ਸੰਭਵ ਹੈ ਵੀ ਜਾਂ ਨਹੀਂ। TUN ਡਿਵਾਈਸ ਕੋਲ MAC ਪਤਾ ਨਹੀਂ ਹੈ ਅਤੇ ਅੱਗੇ ਭੇਜਣ ਲਈ Ethernet ਹੈਡਰ ਨਹੀਂ, ਇਸ ਲਈ TUN ਕਲਾਇੰਟ ਰੂਟ ਜਿਵੇਂ ਵੀ ਲਿਖੇ ਹੋਣ, layer-2 ਬ੍ਰਿਜ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋ ਸਕਦਾ।

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

root ਰਾਹ ਅਜੇ ਕਿੱਥੇ ਜਿੱਤਦਾ ਹੈ

ਤਿੰਨ ਕੰਮ ਲੋਕਾਂ ਨੂੰ ਪਲੇਟਫਾਰਮ ਦੇ ਰਾਹ ਤੋਂ ਦੂਰ ਧੱਕਦੇ ਹਨ। layer-2 ਬ੍ਰਿਜਿੰਗ ਨੂੰ TAP ਚਾਹੀਦਾ ਹੈ। ਆਪਣੇ VPN ਘੇਰੇ ਤੋਂ ਬਾਹਰ ਦੇ ਐਪਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਫੜਨ ਲਈ ਫਰੇਮਵਰਕ ਨਾ ਦੇਣ ਵਾਲੀ ਦਿੱਖ ਚਾਹੀਦੀ ਹੈ। builder ਕਦੇ ਬੇਨਕਾਬ ਨਾ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਰੂਟਿੰਗ, ਜਿਵੇਂ ਇੱਕ ਮੰਜ਼ਿਲ ਲਈ ਵੱਖਰੀ ਟੇਬਲ, ਤੁਸੀਂ ਆਪ ਲਗਾਉਣ ਵਾਲੇ ਨਿਯਮ ਮੰਗਦੀ ਹੈ।

ਖਰਚੇ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦੇ ਹਨ: ਖੋਲ੍ਹਿਆ bootloader ਜਾਂ root ਕੀਤੀ ਇਮੇਜ, ਤੁਹਾਡੇ ਪੈਰਾਂ ਹੇਠ ਸਰਕਦੀ SELinux ਨੀਤੀ, ਅਤੇ OTA ਤੋਂ ਬਾਅਦ ਠੀਕ ਵਿਵਹਾਰ ਛੱਡ ਦੇਣ ਵਾਲਾ ਡਿਵਾਈਸ। root ਕੀਤਾ ਤਰੀਕਾ ਆਮ ਐਪ ਵੰਡ ਰਾਹੀਂ ਭੇਜਿਆ ਵੀ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਇਸ ਲਈ ਬਹੁਤੀਆਂ ਟੀਮਾਂ ਇਸ ਨੂੰ ਉਤਪਾਦ ਦੀ ਥਾਂ ਅੰਦਰੂਨੀ ਨਿਦਾਨ ਰਾਹ ਰੱਖਦੀਆਂ ਹਨ।

ਦੋਵਾਂ ਵਿੱਚੋਂ ਚੋਣ

ਤੁਹਾਡੇ ਕੋਲ ਮੌਜੂਦ ਕੋਡ ਤੋਂ ਨਹੀਂ, ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੇ ਇੰਟਰਫੇਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਜਵਾਬ ਐਪ-ਸੀਮਤ ਰੂਟ ਵਾਲਾ TUN ਡਿਵਾਈਸ ਹੈ, ਤਾਂ ਪਲੇਟਫਾਰਮ ਦਾ ਰਾਹ ਛੋਟਾ ਹੈ ਅਤੇ ਅੱਪਗ੍ਰੇਡ ਝੱਲਦਾ ਹੈ। ਜਵਾਬ ਵਿੱਚ Ethernet ਫਰੇਮ, ਹੋਰ ਐਪਾਂ ਦਾ ਕੈਪਚਰ, ਜਾਂ builder ਵੱਲੋਂ ਨਾਮਨਜ਼ੂਰ ਰੂਟਿੰਗ ਨਿਯਮ ਸ਼ਾਮਲ ਹਨ, ਤਾਂ ਤੁਸੀਂ root ਇਲਾਕੇ ਵਿੱਚ ਹੋ ਅਤੇ ਇਸ ਨੂੰ ਕਾਰਜ-ਖਰਚੇ ਵਜੋਂ ਬਜਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

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