Android 12 IKEv1 VPN: ਲਾਂਚ ਸੰਸਕਰਣ, IKEv2, ਤੀਜੀ-ਧਿਰ ਐਪਾਂ

ਦੋਵੇਂ ਫ਼ੋਨ ਸੈਟਿੰਗਾਂ ਵਿੱਚ Android 12 ਦਿਖਾਉਂਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਤੁਹਾਡੇ ਗੇਟਵੇ ਵੱਲੋਂ ਦਿੱਤਾ ਪੁਰਾਣਾ IPsec XAuth ਪਰੋਫ਼ਾਈਲ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਫ਼ਰਕ ਕੋਈ ਅਜਿਹੀ ਸੈਟਿੰਗ ਨਹੀਂ ਜਿਸ ਤੱਕ ਵਰਤੋਂਕਾਰ ਪਹੁੰਚ ਸਕੇ: ਨੇਟਿਵ ਲੈਗੇਸੀ IKEv1 ਮਾਰਗ ਨੂੰ ਰੋਕਣ ਵਾਲਾ ਗਾਰਡ ਉਸ SDK ਪੱਧਰ ਨੂੰ ਵੇਖਦਾ ਹੈ ਜਿਸ ਨਾਲ ਡਿਵਾਈਸ ਭੇਜੀ ਗਈ ਸੀ, ਸਿਰਫ਼ ਉਸ ਰੀਲੀਜ਼ ਨੂੰ ਨਹੀਂ ਜੋ ਇਹ ਹੁਣ ਚਲਾ ਰਹੀ ਹੈ। ਇਹ ਇੱਕੋ ਵੇਰਵਾ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਫਲੀਟ ਤੁਲਨਾ ਅਰਥਪੂਰਨ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਇਹ ਵੀ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮਾਰਗ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਚਾਹੀਦਾ ਹੈ।

ਦੋ Android 12 ਫ਼ੋਨ ਇੱਕੋ ਟੈਸਟ ਕੇਸ ਨਹੀਂ ਹਨ

AOSP ਦੀ ਉਹ ਤਬਦੀਲੀ ਜਿਸ ਨੇ ਨਵੀਆਂ ਡਿਵਾਈਸਾਂ ਨੂੰ ਲੈਗੇਸੀ IKEv1 ਪਰੋਫ਼ਾਈਲ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਰੋਕਿਆ, DEVICE_INITIAL_SDK_INT ਦੀ Android S ਨਾਲ ਤੁਲਨਾ ਕਰਦੀ ਹੈ, ਜੋ API 31 ਹੈ। ਨੇਟਿਵ ਲੈਗੇਸੀ ਸਟਾਰਟਅੱਪ ਮਾਰਗ ਵਿੱਚ, ਯੋਗ ਪਰੋਫ਼ਾਈਲ ਕੋਈ ਵੀ ਲਾਭਦਾਇਕ ਕਨੈਕਸ਼ਨ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਅਣਸਮਰਥਿਤ-ਕਾਰਵਾਈ ਦੀ ਨਾਕਾਮੀ ਪੈਦਾ ਕਰਦਾ ਹੈ। Android 11 ਨਾਲ ਆਇਆ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਅੱਪਡੇਟ ਹੋਇਆ ਫ਼ੋਨ ਉਸ ਗਾਰਡ ਨੂੰ ਅਜੇ ਵੀ ਪਾਰ ਕਰਦਾ ਹੈ; Android 12 ਉੱਤੇ ਲਾਂਚ ਹੋਇਆ ਮਾਡਲ ਨਹੀਂ ਕਰਦਾ।

ਤੁਸੀਂ ਡੀਬੱਗਿੰਗ ਚਾਲੂ ਵਾਲੀ ਡਿਵਾਈਸ ਉੱਤੇ ਦੋਵੇਂ ਅੰਕ ਪੜ੍ਹ ਸਕਦੇ ਹੋ:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

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

ਇੱਕ ਹੋਰ ਫ਼ਰਕ ਇੱਕ ਘੰਟੇ ਦਾ ਬਰਬਾਦ ਸਹਾਇਤਾ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ: VPN ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਅਜੇ ਵੀ ਸੂਚੀਬੱਧ ਸੰਭਾਲਿਆ ਪਰੋਫ਼ਾਈਲ ਇਸ ਗੱਲ ਦਾ ਕੋਈ ਸਬੂਤ ਨਹੀਂ ਕਿ ਪਲੇਟਫਾਰਮ ਇਸ ਨੂੰ ਸ਼ੁਰੂ ਕਰੇਗਾ। PSK ਦੁਬਾਰਾ ਭਰਨਾ ਜਾਂ ਰੂਟ ਸੋਧਣਾ ਪਹਿਲਾਂ ਚੱਲਣ ਵਾਲੀ ਪ੍ਰੋਟੋਕੋਲ-ਸਹਾਇਤਾ ਜਾਂਚ ਨੂੰ ਹਟਾ ਨਹੀਂ ਸਕਦਾ, ਅਤੇ ਉਹ ਨਾਕਾਮੀ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਦੀ ਸਮੱਸਿਆ ਨਾ ਹੁੰਦਿਆਂ ਵੀ ਉਸ ਵਰਗੀ ਦਿਸਦੀ ਹੈ।

ਮਾਰਗ ਇੱਕ: ਨੇਟਿਵ ਲੈਗੇਸੀ ਸਟੈਕ ਨੂੰ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਇਹ ਅਜੇ ਚੱਲਦਾ ਹੈ

ਲੈਗੇਸੀ ਸਟੈਕ ਉਹ ਹੈ ਜੋ ਸਿਸਟਮ VPN ਸਕ੍ਰੀਨ ਤੋਂ IPsec XAuth PSK, IPsec Hybrid RSA ਅਤੇ L2TP/IPsec PSK ਪਰੋਫ਼ਾਈਲ ਪੜ੍ਹਦਾ ਹੈ। API 31 ਤੋਂ ਹੇਠਾਂ ਆਈ ਡਿਵਾਈਸ ਉੱਤੇ ਅੱਪਗ੍ਰੇਡ ਤੋਂ ਬਾਅਦ ਵੀ ਇਹ ਵਿਵਹਾਰਕ ਮਾਰਗ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਪੁਰਾਣੇ ਹੈਂਡਸੈੱਟ ਉੱਤੇ ਪਾਇਲਟ ਸਫਲ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਨਵਾਂ ਹੈਂਡਸੈੱਟ ਉਹੀ ਪਰੋਫ਼ਾਈਲ ਰੱਦ ਕਰਦਾ ਹੈ।

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

ਮਾਰਗ ਦੋ: ਪਲੇਟਫਾਰਮ IKEv2 ਪਰੋਫ਼ਾਈਲ

IKEv2 ਲਈ Android ਦਾ ਜਨਤਕ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਮਾਡਲ ਇੱਕ ਵੱਖਰੀ ਚੀਜ਼ ਹੈ, ਨਾਮ ਬਦਲਿਆ IKEv1 ਪਰੋਫ਼ਾਈਲ ਨਹੀਂ। IKEv2 ਪਰੋਫ਼ਾਈਲਾਂ ਲਈ ਪਲੇਟਫਾਰਮ API API 30 ਨਾਲ ਆਇਆ ਅਤੇ ਗੇਟਵੇ ਵੱਲੋਂ ਦਿੱਤੀ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿਧੀ ਨਾਲ IKEv2 ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਆਮ ਤੌਰ ਉੱਤੇ ਸਰਟੀਫ਼ਿਕੇਟ-ਆਧਾਰਿਤ ਜਾਂ EAP। IKEv1 XAuth ਜਾਂ Hybrid ਤੋਂ IKEv2 ਤੱਕ ਕੋਈ ਤਾਰ-ਅਨੁਕੂਲ ਅੱਪਗ੍ਰੇਡ ਨਹੀਂ: ਗੇਟਵੇ ਨੂੰ ਨਵੇਂ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਸੰਰਚਿਤ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਪਰੋਫ਼ਾਈਲ ਨੂੰ ਮੇਲ ਖਾਂਦੀ ਪਛਾਣ ਲੈ ਕੇ ਚੱਲਣਾ ਪੈਂਦਾ ਹੈ।

ਇਹ ਸਭ ਤੋਂ ਲੰਮੀ ਉਮਰ ਵਾਲਾ ਮਾਰਗ ਹੈ, ਅਤੇ ਅਸਲ ਕੰਮ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਣ ਵਾਲਾ ਵੀ ਇਹੀ ਹੈ। ਪਛਾਣ ਦੀ ਪੜਤਾਲ, ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣਿਕਤਾ, DNS, ਸਪਲਿਟ-ਟਨਲ ਰੂਟ ਅਤੇ ਸਰੋਤ ਅਧਿਕਾਰ ਸਾਰਿਆਂ ਨੂੰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਝੱਲਣੀ ਪੈਂਦੀ ਹੈ; ਸਿਰਫ਼ ਹੈਂਡਸ਼ੇਕ ਸਫਲ ਹੋਇਆ ਤਾਂ ਵਰਤੋਂਕਾਰ ਅਜਿਹੀ ਟਨਲ ਨਾਲ ਜੁੜੇ ਰਹਿ ਜਾਂਦੇ ਹਨ ਜੋ ਕਿਤੇ ਨਹੀਂ ਪਹੁੰਚਦੀ।

ਤੈਨਾਤੀ ਆਮ ਤੌਰ ਉੱਤੇ MDM ਜਾਂ ਪ੍ਰਬੰਧਿਤ ਸੰਰਚਨਾ ਰਾਹੀਂ ਹੁੰਦੀ ਹੈ, ਵਰਤੋਂਕਾਰ ਵੱਲੋਂ ਖ਼ਾਨੇ ਭਰਨ ਨਾਲ ਨਹੀਂ। ਜੇ ਉਹ ਢਾਂਚਾ ਅਜੇ ਨਹੀਂ ਹੈ, ਤਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾ ਵਿੱਚ ਉਹ ਸ਼ਾਮਲ ਕਰਨਾ ਪਵੇਗਾ, ਕਿਉਂਕਿ ਹਰ ਡਿਵਾਈਸ ਉੱਤੇ IKEv2 ਪਰੋਫ਼ਾਈਲ ਹੱਥੀਂ ਦੁਬਾਰਾ ਭਰਨਾ ਅਜਿਹਾ ਕੰਮ ਨਹੀਂ ਜੋ ਹੈਲਪ ਡੈਸਕ ਝੱਲ ਸਕੇ।

ਮਾਰਗ ਤਿੰਨ: ਤੀਜੀ-ਧਿਰ ਕਲਾਇੰਟ ਐਪ

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

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

ਗੇਟਵੇ ਕੀ ਦੇ ਸਕਦਾ ਹੈ ਦੇ ਆਧਾਰ ਉੱਤੇ ਚੁਣੋ

ਫ਼ੈਸਲਾ ਤਦ ਸੁਕੜ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਦੋ ਗੱਲਾਂ ਜਾਣਦੇ ਹੋ: ਕਿਹੜੀਆਂ ਡਿਵਾਈਸਾਂ API 31 ਜਾਂ ਉਸ ਤੋਂ ਬਾਅਦ ਲਾਂਚ ਹੋਈਆਂ, ਅਤੇ ਕੀ ਗੇਟਵੇ ਉਸੇ ਦਾਖਲਾ ਮਾਡਲ ਨਾਲ IKEv2 ਸੇਵਾ ਦੇ ਸਕਦਾ ਹੈ। ਜੇ ਹਾਂ, ਤਾਂ ਮਾਈਗ੍ਰੇਟ ਕਰੋ ਅਤੇ ਲੈਗੇਸੀ ਪਰੋਫ਼ਾਈਲ ਵਿੱਚ ਨਿਵੇਸ਼ ਬੰਦ ਕਰੋ। ਜੇ ਅਜੇ ਨਹੀਂ, ਤਾਂ ਉਨ੍ਹਾਂ ਡਿਵਾਈਸਾਂ ਲਈ IKEv1 ਰੱਖੋ ਜੋ ਇਸ ਨੂੰ ਅਜੇ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਨਵੀਆਂ ਡਿਵਾਈਸਾਂ ਨੂੰ ਤੀਜੀ-ਧਿਰ ਕਲਾਇੰਟ ਦਸਤਾਵੇਜ਼ੀ ਅਤੇ ਸਮਾਂ-ਸੀਮਤ ਛੋਟ ਵਜੋਂ ਦਿਓ, ਨਾ ਕਿ ਅਣਕਹੀ ਉਪਾਅ ਵਜੋਂ।

ਦੋ ਗੱਲਾਂ ਯੋਜਨਾ ਨੂੰ ਬਚਾਉਣਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਪਹਿਲੀ, ਹਰ ਛੋਟ ਦਾ ਕਾਰਨ ਮਾਡਲ ਅਤੇ ਲਾਂਚ ਪੱਧਰ ਸਮੇਤ ਦਰਜ ਕਰੋ, ਤਾਂ ਜੋ ਲੇਖਾ-ਪਰੀਖਿਅਕ ਵੇਖ ਸਕੇ ਕਿ ਸੀਮਾ ਕੋਈ ਅਣਸਮਝਾਈ ਤਰਜੀਹ ਨਹੀਂ ਸਗੋਂ ਪਲੇਟਫਾਰਮ ਗਾਰਡ ਹੈ। ਦੂਜੀ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਯੋਜਨਾਬੱਧ ਕੰਮ ਮੰਨੋ: IKEv1 ਮਿਆਰੀ ਰਾਹ ਰਾਹੀਂ ਬਾਸ਼ੁਦਾ ਹੋ ਚੁੱਕਿਆ ਹੈ (RFC 9395), ਜਿਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬਾਕੀ ਡਿਵਾਈਸਾਂ ਲਗਾਤਾਰ ਘਟਦੀਆਂ ਰਹਿਣਗੀਆਂ ਅਤੇ ਛੋਟਾਂ ਉਨ੍ਹਾਂ ਦੇ ਨਾਲ ਹੀ ਖ਼ਤਮ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।