ರೂಟ್ ಇಲ್ಲದ Android VPN: ಸಮ್ಮತಿ, ಮಾರ್ಗಗಳು ಮತ್ತು ನಿರ್ಬಂಧ ಯಾರದ್ದು
ಸಮ್ಮತಿ, TUN ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಸಿಸ್ಟಂ ನಿರ್ಬಂಧ ನೀತಿ ಮೂರು ವಿಭಿನ್ನ ಅನುಮತಿಗಳು. Android VPN ಅಪ್ಲಿಕೇಶನ್ ಪರಿಶೀಲಿಸುವ ಮೊದಲು ಪ್ರತಿಯೊಂದು ಯಾವ ಘಟಕದ್ದು ಎಂಬುದನ್ನು ಗುರುತಿಸಿ.
Android VPN ಅಪ್ಲಿಕೇಶನ್ ಟ್ರಾಫಿಕ್ ಸಾಗಿಸಲು, ಸೋರಿಕೆ ತಡೆಯಲು ಅಥವಾ ಮರುಬೂಟ್ ನಂತರ ಉಳಿಯಲು ಅನುವು ಮಾಡುವುದು ರೂಟ್ ಅಲ್ಲ. ಜನರು ಇದನ್ನೆಲ್ಲ „ಅಪ್ಲಿಕೇಶನ್‌ಗೆ VPN ಅನುಮತಿ ಇದೆ“ ಎಂದು ಸಂಕ್ಷೇಪಿಸುತ್ತಾರೆ, ಇದು ಮೂರು ಪ್ರತ್ಯೇಕ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಮರೆಮಾಡುತ್ತದೆ: ಬಳಕೆದಾರರ ಸಮ್ಮತಿ, ಸಿಸ್ಟಂ ರಚಿಸುವ ಪ್ಯಾಕೆಟ್ ಇಂಟರ್ಫೇಸ್, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ಧರಿಸಬೇಕಾದದ್ದಲ್ಲದ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಿರ್ಬಂಧ ನೀತಿ. Android VPN ವಿನ್ಯಾಸವನ್ನು ಪರಿಶೀಲಿಸುವುದು ಎಂದರೆ ಒಂದು ಹೇಳಿಕೆ ನಿಜವಾಗಿ ಈ ಮೂರರಲ್ಲಿ ಯಾವುದನ್ನು ಆಧರಿಸಿದೆ ಎಂದು ಕೇಳುವುದು, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಮಾಲೀಕ ಮತ್ತು ಬೇರೆ ವಿಫಲತೆ ವಿಧಾನ ಇದೆ.
ಸಮ್ಮತಿ ಸಿಸ್ಟಂ ಚಟುವಟಿಕೆಯ ಮೂಲಕ ಬರುತ್ತದೆ
VpnService.prepare() ಏನನ್ನೂ ನೀಡುವುದಿಲ್ಲ. ಸಮ್ಮತಿ ಇಲ್ಲದಿದ್ದಾಗ ಅದು ಸಿಸ್ಟಂ ಸಮ್ಮತಿ ಚಟುವಟಿಕೆಗೆ intent ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರರು ಸೇವೆಯನ್ನು ಅನುಮೋದಿಸಲು ಅಪ್ಲಿಕೇಶನ್ ಆ ಸಂವಾದವನ್ನು ತೆರೆಯುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ಪ್ರಕ್ರಿಯೆ ಪ್ರಾರಂಭಿಸುವುದು, ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗೆ ಅನುಮತಿ ಸೇರಿಸುವುದು, ಅಥವಾ ಕಸ್ಟಮ್ „VPN ಸಕ್ರಿಯಗೊಳಿಸಿ“ ಪರದೆ ತೋರಿಸುವುದು ಅನುಮತಿಯನ್ನು ರಚಿಸುವುದಿಲ್ಲ.
ಅನುಮತಿಯ ವ್ಯಾಪ್ತಿಯೂ ಸೀಮಿತವಾಗಿದೆ. ಅದು ಬಳಕೆದಾರ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿನ ಪ್ಯಾಕೇಜ್‌ಗೆ ಸೇರಿದ್ದು, ಆದ್ದರಿಂದ ವೈಯಕ್ತಿಕ ಪ್ರತಿ ಮತ್ತು ಕೆಲಸದ ಪ್ರತಿ ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರಗಳು, ಮತ್ತು ಸಾಧನ ಮಾಲೀಕರು ನಿರ್ವಹಿತ ಪ್ರೊಫೈಲ್ ಅನ್ನು ವೈಯಕ್ತಿಕದಿಂದ ಭಿನ್ನವಾಗಿ ಸಿದ್ಧಪಡಿಸಬಹುದು. ಸಂವಾದ ಎಂದಿಗೂ ಕಾಣದಿದ್ದರೆ ಮತ್ತು prepare() null ಹಿಂತಿರುಗಿಸಿದರೆ, ಆ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಆ ಪ್ಯಾಕೇಜ್‌ಗೆ ಸಮ್ಮತಿ ಈಗಾಗಲೇ ಇದೆ; ಅದು ಅಪ್ಲಿಕೇಶನ್ ವಿಶ್ವಾಸಾರ್ಹ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ, ಅನುಮತಿ ಇದೆ ಎಂಬುದಷ್ಟೇ.
ಇಂಟರ್ಫೇಸ್ ಸಿಸ್ಟಂ ಪೂರೈಸುವ ವಿನಂತಿ
ಸಮ್ಮತಿಯ ನಂತರ ಅಪ್ಲಿಕೇಶನ್ VpnService.Builder ಬಳಸಿ ಏನು ಬೇಕು ಎಂದು ವಿವರಿಸುತ್ತದೆ: ವಿಳಾಸಗಳು, ಮಾರ್ಗಗಳು, DNS ಸರ್ವರ್‌ಗಳು, MTU ಮತ್ತು ಬೆಂಬಲವಿರುವಲ್ಲಿ ಸೇರಿಸುವ ಅಥವಾ ಹೊರಗಿಡುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು. establish() ಸಿಸ್ಟಂಗೆ ಟನಲ್ ಇಂಟರ್ಫೇಸ್ ರಚಿಸಿ ಹೊಂದಿಕೆಯಾಗುವ ಟ್ರಾಫಿಕ್ ಅದಕ್ಕೆ ಕಳುಹಿಸುವಂತೆ ಕೇಳುತ್ತದೆ. ಮಾರ್ಗನಿರ್ದೇಶನ ನಿರ್ಧಾರ ಸಿಸ್ಟಂನದು; ಅಪ್ಲಿಕೇಶನ್ ಫೈಲ್ ವಿವರಣೆಯನ್ನು ಪಡೆದು ನಂತರ ಪ್ಯಾಕೆಟ್‌ಗಳೊಂದಿಗೆ ಏನಾದರೂ ಉಪಯುಕ್ತ ಮಾಡಬೇಕು.
| What you observe | Who actually owns it |
|---|---|
| VPN consent dialog | The system, triggered by prepare() |
| Routes, DNS and app lists | The app requests them; the system applies them |
| One active VPN per profile | The platform; a new service replaces the old one |
| Always-on and block-without-VPN | Device policy enforced by the platform |
ಆ ಕೋಷ್ಟಕವೇ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ವಾಸ್ತುಶಿಲ್ಪ. ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೆಟ್ ನಿರ್ವಹಣೆಯಲ್ಲಿ ಭಾಗವಹಿಸುತ್ತದೆ; ಇಂಟರ್ಫೇಸ್, ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕ ಅಥವಾ ಚಲಿಸಬಹುದಾದ ಸೇವೆಗಳ ಸಂಖ್ಯೆ ಅದರದ್ದಲ್ಲ.
ಟನಲ್ ಸಾಕೆಟ್ ತನ್ನದೇ ಟನಲ್‌ನಿಂದ ತಪ್ಪಿಸಿಕೊಳ್ಳಬೇಕು
ಗೂಢಲಿಪೀಕೃತ ಟ್ರಾಫಿಕ್ ಸಾಗಿಸುವ ಸಂಪರ್ಕವೇ ಒಂದು ಸಾಕೆಟ್. ಅದನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಈತೀಗ ರಚಿಸಿದ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಮರಳಿ ಕಳುಹಿಸಿದರೆ, ಟನಲ್ ಟನಲ್‌ನ್ನು ಅವಲಂಬಿಸಿ ನಿಲ್ಲುತ್ತದೆ. VpnService.protect() ಆ ಸಾಕೆಟ್ ಅನ್ನು ಕೆಳಗಿನ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಬಿಗಿಯುತ್ತದೆ, ಇದರಿಂದ ಅದು ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸರಿಯಾದ ಕ್ಲೈಂಟ್ ಮೊದಲ ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ಗೆ ಮೊದಲು ತನ್ನ ಹೊರ ಸಾಕೆಟ್ ಅನ್ನು ರಕ್ಷಿಸುತ್ತದೆ.
adb shell dumpsys connectivity | grep -i -A5 vpn
adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdownಈ ಆಜ್ಞೆಗಳು ಸ್ಥಾಪಿತ VPN ನೆಟ್‌ವರ್ಕ್, ಯಾವಾಗಲೂ ಆನ್ ಪ್ಯಾಕೇಜ್ ಮತ್ತು ಲಾಕ್‌ಡೌನ್ ಸೆಟ್ ಆಗಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತವೆ. ಇವು ಓದಲು-ಮಾತ್ರ ವೀಕ್ಷಣೆಗಳು: ಮೌಲ್ಯಗಳು ವಿನ್ಯಾಸದ ಹೇಳಿಕೆಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಹೇಳಿಕೆ ಸಿಸ್ಟಂ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಅಲ್ಲ, ಅಪ್ಲಿಕೇಶನ್ ಇಂಟರ್ಫೇಸ್ ಬಗ್ಗೆ.
ನಿರ್ಬಂಧ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನದ್ದಾಗಿರಬಹುದು
Android VPN ಬಳಸದ ಸಂಪರ್ಕಗಳನ್ನು ನಿರ್ಬಂಧಿಸುವ ನೀತಿಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಆ ಜಾರಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಒಪ್ಪಂದ, ಅಪ್ಲಿಕೇಶನ್ ಲೂಪ್‌ನಲ್ಲಿ ಸಂಪರ್ಕ ಮರುಪ್ರಯತ್ನಿಸುವುದಲ್ಲ. ಸ್ವಿಚ್ ಸಾಧನದ VPN ಸಂಯೋಜನೆಗಳಲ್ಲಿ „VPN ಇಲ್ಲದೆ ಸಂಪರ್ಕಗಳನ್ನು ನಿರ್ಬಂಧಿಸಿ“ ಎಂದಿದೆ, ಮತ್ತು ನಿರ್ವಹಿತ ಸಾಧನದಲ್ಲಿ ಮಾಲೀಕರು ಅದನ್ನು ಇಡೀ ಪ್ರೊಫೈಲ್‌ಗೆ ಆನ್ ಮಾಡಬಹುದು. ಮಾರ್ಕೆಟಿಂಗ್ ಹೇಳಿಕೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವಾಗ ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ: ಕ್ಲೈಂಟ್ ಲಾಕ್ ಐಕಾನ್ ತೋರಿಸಿ ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಮರುಸಂಪರ್ಕಿಸಬಹುದು, ಆದರೆ ನೇರ ಟ್ರಾಫಿಕ್ ಇನ್ನೂ ಸಾಧ್ಯ; ಅಥವಾ ಆವೃತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಿಸ್ಟಂ ಲಾಕ್‌ಡೌನ್ ಜಾರಿಗೊಳಿಸುತ್ತಿರುವುದರಿಂದ ಆಫ್‌ಲೈನ್ ಆಗಿರಬಹುದು.
ಲಾಕ್ ಐಕಾನ್ ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಚಿತ್ರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಅಪ್ಲಿಕೇಶನ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ನಂಬುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಇನ್ನೊಂದು ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ನೆಟ್‌ವರ್ಕ್ ಪ್ರವೇಶ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂದು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಉಪಯುಕ್ತ ಪರಿಶೀಲನೆ ಎಂದರೆ ಟನಲ್ ಆನ್ ಆಗಿರುವಾಗ ಆ ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾಗುವುದನ್ನು ನೋಡುವುದು.
ಅಪ್ಲಿಕೇಶನ್ ಸ್ಟೋರ್‌ನ „ಯಾವಾಗಲೂ ಆನ್“ ಲೇಬಲ್ ಕೂಡ ಆ ಒಪ್ಪಂದವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಯಾವಾಗಲೂ ಆನ್ ಮತ್ತು ಲಾಕ್‌ಡೌನ್ ಸಾಧನ ಸಂಯೋಜನೆಗಳು, ಹೆಚ್ಚಾಗಿ ಸಾಧನ ಮಾಲೀಕರು ಅನ್ವಯಿಸುತ್ತಾರೆ, ಮತ್ತು ಹೊರಗಿಡಲಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಅವುಗಳ ವರ್ತನೆಯನ್ನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಸಂಯೋಜನೆ ಓದಿ, ಬ್ಯಾಜ್ ಅಲ್ಲ.
ವಿನ್ಯಾಸ ಪರಿಶೀಲನೆಗೆ ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳು
ಮೊದಲನೆಯದಾಗಿ, ಯಾರು ಸಮ್ಮತಿಸಿದರು: ಯಾವ ಪ್ಯಾಕೇಜ್, ಯಾವ ಪ್ರೊಫೈಲ್, ಮತ್ತು ಅದು ಬಳಕೆದಾರರೋ ಅಥವಾ ನಿರ್ವಹಿತ ಸಾಧನ ನೀತಿಯೋ? ಎರಡನೆಯದಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಏನು ಕೇಳಿತು: ಯಾವ ಮಾರ್ಗಗಳು, ಯಾವ ವಿಳಾಸ ಕುಟುಂಬಗಳು, ಯಾವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ ಅಥವಾ ಹೊರಗಿಡಲಾಗಿದೆ? ಮೂರನೆಯದಾಗಿ, ಟನಲ್ ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ: ಸಿಸ್ಟಂ ನಿರ್ಬಂಧಿಸುತ್ತದೆಯೋ ಅಥವಾ ಟ್ರಾಫಿಕ್ ಕೆಳಗಿನ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಹಿಂತಿರುಗುತ್ತದೆಯೋ? ನಾಲ್ಕನೆಯದಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಪಡೆಯುವ ಪ್ಯಾಕೆಟ್‌ಗಳೊಂದಿಗೆ ಏನು ಮಾಡುತ್ತದೆ?
ನಾಲ್ಕನೇ ಪ್ರಶ್ನೆಯೇ ಅನುಮತಿ ಮಾದರಿ ಉತ್ತರಿಸಲಾಗದ ಪ್ರಶ್ನೆ. ಸಮ್ಮತಿ ಮತ್ತು TUN ಇಂಟರ್ಫೇಸ್ ಅಪ್ಲಿಕೇಶನ್ ಟ್ರಾಫಿಕ್ ಪಡೆಯಬಹುದು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ಅದನ್ನು ಗೂಢಲಿಪೀಕರಿಸುತ್ತದೆ, ಪಾಲುದಾರನನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಅಥವಾ ಸ್ವಚ್ಛವಾಗಿ ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂದಲ್ಲ. ಇವು ಅನುಷ್ಠಾನ ಗುಣಲಕ್ಷಣಗಳು, ಮತ್ತು ಪ್ರಾಮಾಣಿಕ ಪರಿಶೀಲನೆ ಅಲ್ಲಿಯೇ ಸಮಯ ಕಳೆಯುತ್ತದೆ.
ಅನಗತ್ಯ ರೂಟ್ ವಿನಂತಿ ಫಲಿತಾಂಶವನ್ನು ಕಿಲ್ ಸ್ವಿಚ್ ಎಂದು ಕರೆಯುವುದರಿಂದ ಕಾನೂನುಬದ್ಧವಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಸಮ್ಮತಿ ಸಂವಾದ ಭದ್ರತಾ ಪರಿಶೀಲನೆಯಲ್ಲ. ಮೂರು ಅನುಮತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ, ಪ್ರತಿ ಹೇಳಿಕೆಯೂ ಪರಿಶೀಲನೀಯವಾಗುತ್ತದೆ.