Android chroot VPN: ಸುರಂಗ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದೇಕೆ
chroot ಬದಲಾಯಿಸುವುದು ಪಥದ ಹುಡುಕಾಟವನ್ನು ಮಾತ್ರ, ಕರ್ನಲ್, ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ಅಥವಾ Android ನ VPN ನೋಂದಣಿಯನ್ನು ಅಲ್ಲ. ಇದರಿಂದ ಎರಡು ಪರಿಣಾಮಗಳು ಉಂಟಾಗುತ್ತವೆ, ಮತ್ತು ಎರಡೂ ಜನರನ್ನು ಬೆಚ್ಚಿಬೀಳಿಸುತ್ತವೆ.
ನೀವು ಫೋನ್ನಲ್ಲಿ chroot ಅಡಿಯಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ Linux ವಿತರಣೆಯನ್ನು ಪಡೆದು, ಅದರೊಳಗೆ VPN ಕ್ಲೈಂಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೀರಿ, ಮತ್ತು ಶೆಲ್ ಸುರಂಗ ಪೂರ್ಣಗೊಂಡಿದೆ ಎಂದು ಘೋಷಿಸುತ್ತದೆ. ನಂತರ ನೀವು ಬ್ರೌಸರ್ಗೆ ಬದಲಾಯಿಸುತ್ತೀರಿ ಮತ್ತು ಸಂಚಾರವು ಏನೂ ಆಗದಂತೆ ಮೊಬೈಲ್ ಡೇಟಾದ ಮೂಲಕ ಹೊರಹೋಗುತ್ತದೆ. ಅಥವಾ ವಿರುದ್ಧವಾಗಿ: ಕ್ಲೈಂಟ್ Android ನಿಜವಾಗಿ ಬಳಸುತ್ತಿರುವ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸಿದ ಕಾರಣ ಫೋನ್ನಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್ ಸಂಪರ್ಕವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ಆ ಎರಡು ಲಕ್ಷಣಗಳು ಒಂದೇ ಕಾಣೆಯಾದ ಭಾಗದಿಂದ ಬರುತ್ತವೆ, ಮತ್ತು ಎರಡೂ VPN ಕ್ಲೈಂಟ್ನ ದೋಷವಲ್ಲ.
ಶೆಲ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎನ್ನುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ಗಳು ಒಪ್ಪುವುದಿಲ್ಲ
ಮೊದಲ ಫಲಿತಾಂಶವೇ ಸಾಮಾನ್ಯವಾದದ್ದು. chroot ನಿಂದ ತೆರೆದ userspace ಸುರಂಗವು ತನ್ನ ಹ್ಯಾಂಡ್ಶೇಕ್ ಪೂರ್ಣಗೊಳಿಸಬಹುದು, ತನ್ನ ಅಂಕಿಅಂಶಗಳನ್ನು ಮುದ್ರಿಸಬಹುದು ಮತ್ತು ಅದೇ ಶೆಲ್ ಉತ್ಪಾದಿಸುವ ಸಂಚಾರವನ್ನು ಸಾಗಿಸಬಹುದು, ಆದರೆ Android ನ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಫೋನ್ನ ಡೀಫಾಲ್ಟ್ ನೆಟ್ವರ್ಕ್ ಬಳಸುತ್ತಲೇ ಇರುತ್ತವೆ. ಯಾವುದೂ ಅವನ್ನು ಪ್ರತಿಬಂಧಿಸುತ್ತಿಲ್ಲ, ಏಕೆಂದರೆ VPN ಇದೆ ಎಂದು Android ಗೆ ಯಾವುದೂ ಹೇಳಿಲ್ಲ.
ಎರಡನೇ ಫಲಿತಾಂಶವೇ ಅಪಾಯಕಾರಿ. chroot Android ನ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ಅನ್ನು ಹಂಚಿಕೊಂಡರೆ — ಡೀಫಾಲ್ಟ್ ಆಗಿ ಹಾಗೆ ಮಾಡುತ್ತದೆ — ಸಾಕಷ್ಟು ಸವಲತ್ತು ಇರುವ ಪ್ರಕ್ರಿಯೆಯು ಇಡೀ ಫೋನ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಮಾರ್ಗಗಳನ್ನು ಮತ್ತು TUN ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಸೇರಿಸಬಹುದು. ಆಗ ಸುರಂಗವು ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ಗೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ನೀವು ಸಾಗಿಸಲು ಉದ್ದೇಶಿಸದ ಅಪ್ಲಿಕೇಶನ್ಗಳೂ ಸೇರಿ, ಮತ್ತು ಫೋನ್ನ ಸಂಪರ್ಕವು ಈಗ ಯಾವುದೇ ಜೀವನಚಕ್ರ ನಿರ್ವಹಣೆ, ಸಂಪರ್ಕ ಸೂಚಕ ಮತ್ತು always-on ನೀತಿ ಇಲ್ಲದ ಡೀಮನ್ ಅನ್ನು ಅವಲಂಬಿಸುತ್ತದೆ.
ನೀವು ಯಾವುದನ್ನು ಪಡೆದಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಒಂದೇ ಆಜ್ಞೆಯಲ್ಲಿ ಉತ್ತರಿಸಬಹುದು. chroot ಒಳಗಿನ ip route ಅನ್ನು ಅದರ ಹೊರಗಿನ Android ಶೆಲ್ನಿಂದ ಅದೇ ಆಜ್ಞೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ. ಒಂದೇ ರೀತಿಯ ಔಟ್ಪುಟ್ ಎಂದರೆ chroot ಹೋಸ್ಟ್ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿದೆ: ಅದು ಮಾಡುವ ಯಾವುದೇ ನೆಟ್ವರ್ಕಿಂಗ್ ಬದಲಾವಣೆ ಇಡೀ ಫೋನ್ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಭಿನ್ನ ಔಟ್ಪುಟ್ ಎಂದರೆ ಲಾಂಚರ್ ಅದಕ್ಕೆ ನೇಮ್ಸ್ಪೇಸ್ ರಚಿಸಿದೆ, ಮತ್ತು ಅದರ ಸುರಂಗ Android ಗೆ ರಚನೆಯಿಂದಲೇ ಅದೃಶ್ಯವಾಗಿದೆ.
chroot ಏನನ್ನು ಬದಲಾಯಿಸಿತು ಮತ್ತು ಏನನ್ನು ಬದಲಾಯಿಸಲಿಲ್ಲ
| Object | Effect of a chroot |
|---|---|
| Pathname resolution | Changed: lookups start at the new root |
| Kernel and drivers | Unchanged: the phone's kernel, its TUN driver, its limits |
| Network namespace | Unchanged unless the launcher creates one |
| Android VPN registration | Unchanged: no app consented, no VPN is selected |
chroot ಸಿಸ್ಟಮ್ ಕರೆ ಒಂದೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಪಥದ ಹೆಸರು ಹುಡುಕಾಟಕ್ಕೆ ಬಳಸುವ ಡೈರೆಕ್ಟರಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಅದು ಭದ್ರತಾ ಗಡಿಯಲ್ಲ ಎಂದು ಮ್ಯಾನ್ ಪೇಜ್ ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ, ಮತ್ತು ಇಂಟರ್ಫೇಸ್, ಮಾರ್ಗಗಳು ಅಥವಾ VPN ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. Linux ಕಂಟೇನರ್ ಎಂಬುದರಿಂದ ಜನರು ನಿರೀಕ್ಷಿಸುವ ಎಲ್ಲವೂ — ಖಾಸಗಿ ನೆಟ್ವರ್ಕ್ ಸ್ಟಾಕ್, ಫಿಲ್ಟರ್ ಮಾಡಿದ ಫೈಲ್ಸಿಸ್ಟಮ್, ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳು — ಲಾಂಚರ್ ಬಳಸಿರಬಹುದಾದ ಅಥವಾ ಇಲ್ಲದಿರಬಹುದಾದ ಇತರ ಕಾರ್ಯವಿಧಾನಗಳಿಂದ ಬರುತ್ತದೆ.
ಅದಕ್ಕೇ chroot VPN ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ ಎಂಬ ಹೇಳಿಕೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತವೆ. ಸಂಬಂಧಿತ ಪ್ರಶ್ನೆ ಎಂದರೆ ಪ್ರಕ್ರಿಯೆಯು ಯಾವ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಯಾವ SELinux ಡೊಮೇನ್ಗೆ ಸೀಮಿತವಾಗಿದೆ; ಎರಡೂ ಅದನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಲಾಯಿತು ಎಂಬುದರ ಗುಣಲಕ್ಷಣಗಳು, chroot ಎಂಬ ಪದದ್ದಲ್ಲ.
TUN ಗೆ ಮೂರು ವಸ್ತುಗಳು ಬೇಕು, ಮತ್ತು ಡಿವೈಸ್ ನೋಡ್ ಅವುಗಳಲ್ಲಿ ಒಂದೇ
ಸಾಂಪ್ರದಾಯಿಕ userspace ಸುರಂಗಕ್ಕೆ ತೆರೆಯಬಹುದಾದ TUN ಸಾಧನ, ಆ ಸಾಧನಕ್ಕೆ ಕರ್ನಲ್ ಬೆಂಬಲ, ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಹಾಗೂ ಮಾರ್ಗಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಅನುಮತಿ ಬೇಕು. ಇವು ಪ್ರತ್ಯೇಕ ಅಗತ್ಯಗಳು, ಮತ್ತು /dev ಅಡಿಯಲ್ಲಿ ಪಥದ ಹೆಸರನ್ನು ರಚಿಸುವುದು ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ತಾನಾಗಿ ಪೂರೈಸುವುದಿಲ್ಲ:
ls -l /dev/net/tun
ip tuntap add dev tun0 mode tunAndroid ನಲ್ಲಿ ಕರ್ನಲ್ ಸಾಮಾನ್ಯವಾಗಿ TUN ಬೆಂಬಲವನ್ನು ಸಂಯೋಜಿಸಿರುತ್ತದೆ, ಏಕೆಂದರೆ ವೇದಿಕೆಯದೇ VPN ಸೇವೆ ಅದನ್ನು ಬಳಸುತ್ತದೆ, ಆದರೆ ಅದು ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆ ಅದನ್ನು ಬಳಸಬಹುದು ಎಂದು ಅರ್ಥವಲ್ಲ. ಇಂಟರ್ಫೇಸ್ ಕಾನ್ಫಿಗರೇಶನ್ಗೆ ನೆಟ್ವರ್ಕ್-ಆಡಳಿತ ಸಾಮರ್ಥ್ಯ ಬೇಕು, ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯು ಡಿವೈಸ್ ನೋಡ್ ಅನ್ನು ತಲುಪಬಹುದೇ ಎಂದು SELinux ನಿರ್ಧರಿಸುತ್ತದೆ. ನಿರಾಕರಣೆಯು ಸ್ಪಷ್ಟ ಕಾರಣವಿಲ್ಲದ ಅನುಮತಿ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಉತ್ತರ ಸಿಗುವುದು ಆಡಿಟ್ ಟ್ರೇಲ್ನಲ್ಲಿ:
dmesg | grep avc
logcat -d | grep "avc: denied"Root ಇದನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ. uid 0 ಆಗಿ ಚಲಿಸುವ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು SELinux ಇತರರಂತೆಯೇ ನಿರ್ಬಂಧಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ root ಶೆಲ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿದ chroot ಕೂಡ ತಾನು ನೋಡಬಹುದಾದ ಸಾಧನವನ್ನು ನಿರಾಕರಿಸಬಹುದು. ಹಳೆಯ ಇನ್ಸ್ಟಾಲರ್ ಕೆಲಸ ಮಾಡಿಸಲು ಜಾರಿಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಸುರಂಗದ ಆಚೆಗೂ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿರುವ ಇಡೀ ಫೋನ್ ನಿರ್ಧಾರ, ಮತ್ತು ಅದು ಹಳೆಯ ಬೈನರಿಗೆ ಪರಿಹಾರವಲ್ಲ.
Android ಅಪ್ಲಿಕೇಶನ್ಗಳು ನಿಮ್ಮ ಸುರಂಗವನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದೇಕೆ
Android ನ ಬೆಂಬಲಿತ ಮಾದರಿ ಎಂದರೆ VPN ಅಪ್ಲಿಕೇಶನ್ ವೇದಿಕೆಯ VPN ಸೇವೆಯ ಮೂಲಕ ನೋಂದಾಯಿಸಿ, ಒಮ್ಮೆ ಬಳಕೆದಾರರ ಒಪ್ಪಿಗೆ ಕೇಳಿ, ತನ್ನ ಸುರಂಗಕ್ಕೆ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಪಡೆಯುತ್ತದೆ. ನಂತರ ವೇದಿಕೆ ಸಂಚಾರವನ್ನು ಆ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ಗೆ ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರ ಅಥವಾ ನಿರ್ವಾಹಕ ಆಯ್ಕೆ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್ ವ್ಯಾಪ್ತಿಯನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ; ಅದಕ್ಕೇ ಅದೇ ಕಾರ್ಯವಿಧಾನವು ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್, ಪ್ರತಿ-ಪ್ರೊಫೈಲ್ ಆಗಿರಬಹುದು ಮತ್ತು always-on ಹಾಗೂ block-without-VPN ಸೆಟ್ಟಿಂಗ್ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಬಹುದು. Android VPN ಅಭಿವೃದ್ಧಿ ಮಾರ್ಗದರ್ಶಿ ಆ ಹ್ಯಾಂಡ್ಶೇಕ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಮುಖ್ಯ ಅಂಶ ಎಂದರೆ ಅದು ನೋಂದಣಿ, ಮಾರ್ಗನಿರ್ದೇಶನದ ತಂತ್ರವಲ್ಲ.
chroot ಒಳಗಿನ ಡೀಮನ್ ಎಂದಿಗೂ ನೋಂದಾಯಿಸುವುದಿಲ್ಲ. ಒಪ್ಪಿಗೆ ಸಂವಾದವಿಲ್ಲ, ಸ್ಟೇಟಸ್ ಬಾರ್ನಲ್ಲಿ ಕೀ ಐಕಾನ್ ಇಲ್ಲ, ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಸೇರಿಸು ಅಥವಾ ಹೊರಗಿಡು ಪಟ್ಟಿ ಇಲ್ಲ, ಮತ್ತು always-on ನೀತಿಯಲ್ಲಿ ಭಾಗವಹಿಸುವಿಕೆ ಇಲ್ಲ. ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಡೀಫಾಲ್ಟ್ ನೆಟ್ವರ್ಕ್ ಬಳಸುತ್ತವೆ, ಮತ್ತು ಸುರಂಗವು ಶೆಲ್ ಕಳುಹಿಸುವುದನ್ನು ಮಾತ್ರ ಸಾಗಿಸುತ್ತದೆ.
ಬೇರೆ ದಿಕ್ಕಿನಲ್ಲಿ ಹೋಗುವುದೂ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಹೋಸ್ಟ್ ನೇಮ್ಸ್ಪೇಸ್ಗೆ ಮಾರ್ಗಗಳನ್ನು ತಳ್ಳುವುದು ಎಲ್ಲವನ್ನೂ ಹಿಡಿಯುತ್ತದೆ, ವೇದಿಕೆ ಸ್ಥಳೀಯವಾಗಿ ಇರಿಸಲು ನಿರೀಕ್ಷಿಸಿದ ಸಂಚಾರ ಸೇರಿ, ಮತ್ತು ಅದನ್ನು ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ನಿಯಂತ್ರಣವಿಲ್ಲದೆ, ಬಳಕೆದಾರರು ನೋಡಲು ಅಥವಾ ರದ್ದು ಮಾಡಲು ದಾರಿಯಿಲ್ಲದೆ ಮಾಡುತ್ತದೆ. chroot ಡೀಮನ್ ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಮಾತ್ರ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುವ ಮಧ್ಯಮ ಸೆಟ್ಟಿಂಗ್ ಇಲ್ಲ.
ಬೈನರಿ ಹೊಂದಾಣಿಕೆ ಪ್ರತ್ಯೇಕ ಗೋಡೆ
ನೆಟ್ವರ್ಕ್ ಭಾಗ ಆಸಕ್ತಿಕರವಾಗಿದ್ದರೂ, ಎಕ್ಸಿಕ್ಯೂಟೆಬಲ್ಗೆ ತನ್ನದೇ ಅಗತ್ಯಗಳಿವೆ: CPU ಆರ್ಕಿಟೆಕ್ಚರ್, ಡೈನಾಮಿಕ್ ಲೋಡರ್, C ಗ್ರಂಥಾಲಯ, ಮತ್ತು ಅದು ನಿರೀಕ್ಷಿಸುವ ಕರ್ನಲ್ ಸೌಲಭ್ಯಗಳು. Android glibc ಬದಲು bionic ಬಳಸುತ್ತದೆ, ಮತ್ತು ಡೆಸ್ಕ್ಟಾಪ್ ವಿತರಣೆಗೆ ವಿರುದ್ಧವಾಗಿ ನಿರ್ಮಿಸಿದ ಹಳೆಯ ಬೈನರಿಗೆ ಸಾಧನದಲ್ಲಿ ಇನ್ನಿಲ್ಲದ ಗ್ರಂಥಾಲಯಗಳು ಬೇಕಾಗಬಹುದು.
ಗ್ರಂಥಾಲಯದ ಫೈಲ್ನಾಮವನ್ನು ಹೊಸ ಆವೃತ್ತಿಗೆ ಸಿಂಬಾಲಿಕ್ ಲಿಂಕ್ ಮಾಡುವುದು ABI ಹೊಂದಾಣಿಕೆಯನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ, ಮತ್ತು ದಶಕ ಹಳೆಯ ಪ್ಯಾಕೇಜ್ನಿಂದ ಸಂಗ್ರಹಿಸಿದ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಗ್ರಂಥಾಲಯ ನಿರ್ವಹಿತ ಘಟಕವಲ್ಲ. ಯೋಜನೆ ಅದನ್ನು ಅವಲಂಬಿಸಿದರೆ, ಆ ಯೋಜನೆ ಫೋನ್ನಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಸವಲತ್ತುಗಳೊಂದಿಗೆ ನಿರ್ವಹಿಸದ ಕೋಡ್ ಅನ್ನು ಚಲಾಯಿಸುವುದಾಗಿದೆ.
Android ಸಂದರ್ಭದಲ್ಲಿ ಸಾಬೀತು ಮಾಡಿ ಮತ್ತು ನಂತರ ಸ್ವಚ್ಛಗೊಳಿಸಿ
ನಿಮಗೆ ನಿಜವಾಗಿ ಮುಖ್ಯವಾದದ್ದನ್ನು, ಮುಖ್ಯವಾದ ಕಡೆಯಿಂದ ಪರೀಕ್ಷಿಸಿ: ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್ ತೆರೆಯಿರಿ, ನಿರ್ದಿಷ್ಟ ಖಾಸಗಿ ಗಮ್ಯಸ್ಥಾನವನ್ನು ತಲುಪಿ, ಯಾವ ರಿಸಾಲ್ವರ್ ಉತ್ತರಿಸಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಸುರಂಗವನ್ನು ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಮತ್ತು ದಾಖಲಿತ ವರ್ತನೆಯನ್ನು ಖಚಿತಪಡಿಸಿ. chroot ಒಳಗಿನ ಟರ್ಮಿನಲ್ನಿಂದ ಬಂದ ಫಲಿತಾಂಶ ಆ ಟರ್ಮಿನಲ್ನ ಕಾರ್ಯನಿರ್ವಾಹಣ ಸಂದರ್ಭದ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯ ಮಾತ್ರ, ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಲ್ಲ.
ಪ್ರಯೋಗ ಮಾಡುವಾಗ ಹೋಸ್ಟ್ ಮಾರ್ಗಗಳನ್ನು ಬದಲಾಯಿಸಿದ್ದರೆ, ಅವನ್ನು ಹಿಂತಿರುಗಿಸಿ ಮತ್ತು ಏನನ್ನು ಬದಲಾಯಿಸಿದಿರಿ ಎಂದು ದಾಖಲಿಸಿ. ನಂತರ ಫೋನಲ್ಲಿ always-on VPN ಸಂರಚಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ನಿಯಮವನ್ನು ಬಿಟ್ಟುಹೋದ ಹಳೆಯ ಪ್ರಯೋಗವು ತಿಂಗಳುಗಳ ನಂತರ ವೇದಿಕೆಯ ದೋಷದಂತೆ ಕಾಣಬಹುದು.
ನಿಜವಾದ ರಿಮೋಟ್-ಆಕ್ಸೆಸ್ ಅಗತ್ಯಕ್ಕೆ, ಸೇವೆಯ ಬೆಂಬಲಿತ ಕ್ಲೈಂಟ್ ಅಥವಾ ಅನುಮೋದಿತ ಗೇಟ್ವೇ ವಿನ್ಯಾಸವನ್ನು ಬಳಸಿ. ಕೇಳಬೇಕಾದ ಪ್ರಶ್ನೆ ಎಂದರೆ root ಮಾಡಿದ ಇನ್ಸ್ಟಾಲರ್ ಚಲಾಯಿಸಬಹುದೇ ಎಂದಲ್ಲ, ಬದಲಿಗೆ ಬೆಂಬಲಿತ ಅನುಷ್ಠಾನವು ನೀವು ಉದ್ದೇಶಿಸಿದ ಗಡಿಯ ಮೂಲಕ ನಿಮಗೆ ಬೇಕಾದ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆಯೇ, ಸಾಧನದಲ್ಲಿ ಮಾಲೀಕತ್ವವಿಲ್ಲದ ಸವಲತ್ತು ಬದಲಾವಣೆಗಳನ್ನು ಬಿಡದೆ.