Android 12 ಮತ್ತು IKEv1 VPN: ಲಾಂಚ್ ಆವೃತ್ತಿ, IKEv2 ಮತ್ತು ತೃತೀಯ-ಪಕ್ಷದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು

ಎರಡೂ ಫೋನ್‌ಗಳು ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ Android 12 ತೋರಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ನಿಮ್ಮ ಗೇಟ್‌ವೇ ನೀಡುವ ಹಳೆಯ IPsec XAuth ಪ್ರೊಫೈಲ್ ಅನ್ನು ಇನ್ನೂ ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ವ್ಯತ್ಯಾಸವು ಬಳಕೆದಾರರು ತಲುಪಬಹುದಾದ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ: ನೇಟಿವ್ IKEv1 ಮಾರ್ಗವನ್ನು ನಿಯಂತ್ರಿಸುವ ಗಾರ್ಡ್ ಸಾಧನವನ್ನು ಯಾವ SDK ಮಟ್ಟದೊಂದಿಗೆ ರವಾನಿಸಲಾಯಿತು ಎಂಬುದನ್ನು ನೋಡುತ್ತದೆ, ಈಗ ಚಾಲನೆಯಲ್ಲಿರುವ ಆವೃತ್ತಿಯನ್ನು ಮಾತ್ರವಲ್ಲ. ಆ ಒಂದು ವಿವರವೇ ಫ್ಲೀಟ್ ಹೋಲಿಕೆಗೆ ಅರ್ಥವಿದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಮೂರು ಮೈಗ್ರೇಶನ್ ಮಾರ್ಗಗಳಲ್ಲಿ ಯಾವುದು ನಿಮಗೆ ನಿಜವಾಗಿ ಬೇಕು ಎಂಬುದನ್ನೂ ನಿರ್ಧರಿಸುತ್ತದೆ.

ಎರಡು Android 12 ಫೋನ್‌ಗಳು ಒಂದೇ ಪರೀಕ್ಷಾ ಪ್ರಕರಣವಲ್ಲ

ಹೊಸ ಸಾಧನಗಳು ಹಳೆಯ IKEv1 ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸದಂತೆ ತಡೆದ AOSP ಬದಲಾವಣೆಯು 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), ಅಂದರೆ ಉಳಿದ ಸಾಧನಗಳು ಇನ್ನೂ ಕಡಿಮೆಯಾಗುತ್ತವೆ ಮತ್ತು ವಿನಾಯಿತಿಗಳು ಅವುಗಳೊಂದಿಗೆ ಮುಗಿಯಬೇಕು.