ಇಲ್ಲ, VpnService ಆ್ಯಪ್ ಫೋನ್‌ನ VPN ಅನ್ನು ಆನ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ

ತಪ್ಪು ಊಹೆ ಎಂದರೆ VpnService ಆ್ಯಪ್ ಸಿಸ್ಟಮ್ ಸ್ವಿಚ್ ಅನ್ನು ತಿರುಗಿಸುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿಂದ ಫೋನ್ ರಕ್ಷಿತವಾಗಿರುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ ನಡೆಯುವುದು ಹೆಚ್ಚು ಸಂಕುಚಿತ: ಆ್ಯಪ್ ಸಮ್ಮತಿ ಕೇಳುತ್ತದೆ, ಇಂಟರ್‌ಫೇಸ್ ನಿರ್ಮಿಸುತ್ತದೆ, ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮೂಲಕ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಓದಿ ಬರೆಯುತ್ತದೆ, ಮತ್ತು ನಿಲ್ಲಿಸಿದಾಗ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಒಂದೇ ಸಮಯಕ್ಕೆ ಅಂತಹ ಒಂದೇ ಸುರಂಗ ಜೀವಂತವಾಗಿರಬಹುದು, ಮತ್ತು ಸಿಸ್ಟಮ್ ಕೇಳದೆ ಅದನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಜನರು ಪ್ರೋಟೋಕಾಲ್ ಮೇಲೆ ಹೊರಿಸುವ ಗೊಂದಲದ ವರ್ತನೆಯ ಬಹುಭಾಗ ಆ ಮಾಲೀಕತ್ವ ಮಾದರಿಯಿಂದ ಬರುತ್ತದೆ.

ಪ್ರತಿ ಜೀವನಚಕ್ರ ಪರಿವರ್ತನೆಯನ್ನು ಅಂಚಿನ ಪ್ರಕರಣವಲ್ಲ, ವಿನ್ಯಾಸದ ಭಾಗವಾಗಿ ಪರಿಗಣಿಸಿ.

ಕಲ್ಪನೆ: ಆ್ಯಪ್ ಫೋನ್‌ನ VPN ಅನ್ನು ಆನ್ ಮಾಡುತ್ತದೆ

ಹರಿವು VpnService.prepare() ನಿಂದ ಆರಂಭವಾಗುತ್ತದೆ, ಅದು ಬಳಕೆದಾರರು ಸ್ವೀಕರಿಸಬೇಕಾದ Intent ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು establish() ನೊಂದಿಗೆ ಮುಂದುವರಿಯುತ್ತದೆ, ಅದು ನಂತರವೂ ಆ್ಯಪ್ ನಿಯಂತ್ರಿಸದ ಕಾರಣಗಳಿಗಾಗಿ ವಿಫಲವಾಗಬಹುದು. ಎರಡನೇ ಸುರಂಗ ಸ್ಥಾಪಿಸಿದರೆ ಮೊದಲ ಇಂಟರ್‌ಫೇಸ್ ನಿಷ್ಕ್ರಿಯವಾಗುತ್ತದೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಅಧಿಸೂಚನೆ ಬದಲಾಗುತ್ತದೆ. ಆ ಕ್ರಮದಲ್ಲಿ ಎಲ್ಲೂ ಆ್ಯಪ್ ಇಡೀ ಸಾಧನದ ಸ್ವಿಚ್ ಹೊಂದಿಲ್ಲ; ಅದು ತನಗೆ ನೀಡಿದ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮತ್ತು ಅದರ ಮೇಲೆ ಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ಶಾಶ್ವತ ಅಧಿಸೂಚನೆಯೂ ಆ್ಯಪ್‌ನ ವಿನ್ಯಾಸದ್ದಲ್ಲ, ಸಿಸ್ಟಮ್‌ನದು.

ಇಂಟರ್‌ಫೇಸ್ ಕಿತ್ತುಕೊಳ್ಳುವುದಿಲ್ಲ, ನೀಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್ ಯಾವಾಗ ಬೇಕಾದರೂ ಸ್ಥಳವನ್ನು ಪಡೆಯಬಹುದು. ಆ್ಯಪ್ ಅದನ್ನು ರಿಟರ್ನ್ ಮೌಲ್ಯದಿಂದ ಅಲ್ಲ, ಕಾಲ್‌ಬ್ಯಾಕ್‌ನಿಂದ ತಿಳಿಯುತ್ತದೆ.

ಆ್ಯಪ್ ಅನ್ನು ಬಲವಂತವಾಗಿ ನಿಲ್ಲಿಸಿದ್ದು ಅಧಿಸೂಚನೆ ಪ್ಯಾನೆಲ್‌ನಲ್ಲಿ ಕಾಣುವುದೂ ಅದೇ ಕಾರಣಕ್ಕೆ: ಸಿಸ್ಟಮ್ ತಾನು ಏನು ನೀಡಿತು ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಆ್ಯಪ್ ಏನು ತೋರಿಸಲು ಆಯ್ಕೆ ಮಾಡಿತು ಎಂದಲ್ಲ.

ಕಲ್ಪನೆ: ಸಮ್ಮತಿ ಒಮ್ಮೆ ಮಾತ್ರ ನೀಡಲಾಗುತ್ತದೆ

ಸಿಸ್ಟಮ್ ಸುರಂಗವನ್ನು ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್‌ಗೆ ಒಪ್ಪಿಸಿದಾಗ, ಮೂಲ ವರ್ಗ onBind() ನಿಂದ ಹಿಂತಿರುಗಿಸುವ binder ಮೇಲೆ ರದ್ದತಿ ವ್ಯವಹಾರವನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಆ binder ಅನ್ನು ತನ್ನದರಿಂದ ಬದಲಿಸುವ ಆ್ಯಪ್ ರದ್ದತಿ ವ್ಯವಹಾರವನ್ನು ತಾನೇ ಮುಂದಕ್ಕೆ ರವಾನಿಸಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ VpnService.onRevoke() ಎಂದಿಗೂ ಪ್ರಚೋದನೆಗೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಸೇವೆ ಇನ್ನಿಲ್ಲದ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗೆ ಬರೆಯುತ್ತಲೇ ಇರುತ್ತದೆ. ಬಳಕೆದಾರರೂ ಅನುಮೋದನೆಯನ್ನು ಹಿಂಪಡೆಯಬಹುದು, ಮತ್ತು ಸಿಸ್ಟಮ್ ಮರುಪ್ರಾರಂಭ ಅಥವಾ ಯಾವಾಗಲೂ ಆನ್ ಮರುಸಂಪರ್ಕದ ವೇಳೆ ಸೇವೆಯನ್ನು ನಿಲ್ಲಿಸಬಹುದು.

ಇದನ್ನು ನಿಭಾಯಿಸುವುದು ಲಾಗ್ ಸಾಲಲ್ಲ, ನಿರ್ದಿಷ್ಟ ಕೆಲಸ: ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಓದುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಅದನ್ನು ಮುಚ್ಚಿ, ಸಂಪರ್ಕಿತ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಅಳಿಸಿ ಮತ್ತು ಬಳಕೆದಾರರು ಯಾವ ಸ್ಥಿತಿಯಲ್ಲಿದ್ದಾರೆಂದು ಹೇಳಿ. ನಂತರ ಆ್ಯಪ್ ಮತ್ತೆ ಸ್ಥಾಪಿಸಬೇಕೇ, ಮತ್ತೆ ಕೇಳಬೇಕೇ ಅಥವಾ ಕಾಯಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಯಾವಾಗಲೂ ಆನ್ ಸಂರಚನೆಯಲ್ಲಿ ಸಿಸ್ಟಮ್ ಸೇವೆಯನ್ನು ತಾನೇ ಮರಳಿ ತರಬಹುದು.

ರದ್ದತಿಯನ್ನು ಸ್ಥಿತಿಯಲ್ಲ, ವಿನಾಯಿತಿ ಎಂದು ಪರಿಗಣಿಸುವ ಆ್ಯಪ್ ತಾನು ಬರೆಯುವ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಬಿಸಾಡಲ್ಪಡುತ್ತಿದ್ದರೂ ಸಂಪರ್ಕಿತ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಗೋಪ್ಯತಾ ಸಾಧನಕ್ಕೆ ಇದು ಸಾಧ್ಯವಾದ ಅತ್ಯಂತ ಕೆಟ್ಟ ವೈಫಲ್ಯ ಮೋಡ್.

ಕಲ್ಪನೆ: ಇಂಟರ್‌ಫೇಸ್ ನಿಮಗಾಗಿ ಟ್ರಾಫಿಕ್ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ

ಬರುವುದು ಕಚ್ಚಾ IP. ಹಿಡಿಯುವುದು ಅಥವಾ ಫಿಲ್ಟರ್ ಮಾಡುವುದು ಎಂದರೆ IP, TCP, UDP ಮತ್ತು IPv6 ಹೆಡರ್‌ಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡುವುದು, ಹರಿವುಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಮತ್ತು ಉತ್ತರಗಳನ್ನು ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗೆ ಹಿಂತಿರುಗಿ ಬರೆಯುವುದು, ಇದು ಕ್ಯಾಪ್ಚರ್ ಆ್ಯಪ್ ಅನ್ನು ಸಿಸ್ಟಮ್ ಸೌಲಭ್ಯವಲ್ಲದೆ ಸಣ್ಣ ನೆಟ್‌ವರ್ಕ್ ಸ್ಟ್ಯಾಕ್ ಆಗಿ ಮಾಡುತ್ತದೆ. protect() ಇರುವುದು ಆ್ಯಪ್‌ನ ಸ್ವಂತ ಸಾಗಣೆ ಸಾಕೆಟ್ ತನ್ನನ್ನು ಹಿಡಿಯುವ ಬದಲು ತನ್ನ ಸುರಂಗವನ್ನು ಬಳಸಿಕೊಳ್ಳದಂತೆ, ಮತ್ತು ಅದು ಸುರಂಗ ಏರಿದ ನಂತರ ರಚಿಸಿದ ಪ್ರತಿ ಸಾಕೆಟ್‌ನಲ್ಲೂ ಪರಿಶೀಲಿಸಲು ಯೋಗ್ಯವಾದ ಬೂಲಿಯನ್ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ನಿರ್ಮಾಣಕಾರನ ಅನುಮತಿಸಿದ ಮತ್ತು ನಿಷೇಧಿಸಿದ ಆ್ಯಪ್ ಪಟ್ಟಿಗಳು ಯಾರ ಟ್ರಾಫಿಕ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಪ್ರವೇಶಿಸುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. ಅವು ಇಂಟರ್‌ಫೇಸ್ ಒಯ್ಯುವ IP ಪ್ಯಾಕೆಟ್‌ಗಳ ಆಚೆಗಿನ ಪೇಲೋಡ್‌ಗೆ ಪ್ರವೇಶ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ API ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್‌ನ ಸುರಂಗವನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ ಅಥವಾ ಸಿಸ್ಟಮ್‌ನ VPN ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ನೆಟ್‌ವರ್ಕ್ ಸಾಮರ್ಥ್ಯಗಳು ಒಂದು ನೆಟ್‌ವರ್ಕ್ VPN ಸಾಗಣೆ ಎಂದು ಹೇಳಬಹುದು, ಆದರೆ ಸುರಂಗ ಯಾರದ್ದು ಎಂದಲ್ಲ.

ಅದಕ್ಕೇ ಇತರ ಆ್ಯಪ್‌ಗಳ ಬಗ್ಗೆ ಸ್ಥಿತಿ ಪ್ರಶ್ನೆಗಳಿಗೆ ವಿರೋಧಾಭಾಸದ ಉತ್ತರಗಳು ಸಿಗುತ್ತವೆ: ಮಾಹಿತಿ ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಗೆ ಬಹಿರಂಗವಾಗಿಯೇ ಇಲ್ಲ.

ಜೀವನಚಕ್ರ ನಿಜವಾಗಿ ಏನು ಬೇಡುತ್ತದೆ

ನೀವು ನಿಯಂತ್ರಿಸುವ ಸ್ಥಿತಿಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ: ಸಿದ್ಧ, ಸ್ಥಾಪಿತ, ರದ್ದಾದ, ನಿಂತ. ಮರುಸಂಪರ್ಕವು ಒಡೆಯುವಿಕೆ ನಂತರ ಸ್ಥಾಪನೆ ಆಗಿರಬೇಕು, ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮತ್ತು ಸಾಗಣೆ ಸಾಕೆಟ್‌ಗೆ ಒಬ್ಬನೇ ಮಾಲೀಕನೊಂದಿಗೆ, ಏಕೆಂದರೆ ಸ್ಥಾಪಿಸಲು ಪೈಪೋಟಿ ನಡೆಸುವ ಎರಡು ಘಟಕಗಳು ಒಂದೇ ಲಭ್ಯವಿರುವ ಸ್ಥಳಕ್ಕಾಗಿ ಹೋರಾಡುತ್ತವೆ. ಆಧುನಿಕ Android ನಲ್ಲಿ ಹಿನ್ನೆಲೆ ಆರಂಭಗಳು ಸೀಮಿತವಾಗಿವೆ, ಆದ್ದರಿಂದ ಬೂಟ್ ಪ್ರಸಾರವು ಖಾತರಿಯಲ್ಲ; API ಮಟ್ಟ ಅನುಮತಿಸುವಲ್ಲಿ ಅದರ ಅಧಿಸೂಚನೆಯೊಂದಿಗೆ ಮುಂಭಾಗ ಸೇವೆಯನ್ನು ಬಳಸಿ.

ಕೇವಲ ಅಂತಿಮ ಸ್ಥಿತಿಯಲ್ಲ, ಪರಿವರ್ತನೆಯನ್ನು ಲಾಗ್ ಮಾಡಿ, ಮತ್ತು ಪ್ರತಿ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಲು ಸಾಧ್ಯವಾಗುವಷ್ಟು ಸಣ್ಣದಾಗಿ ಸ್ಥಿತಿ ಯಂತ್ರವನ್ನು ಇರಿಸಿ. ಪರೀಕ್ಷೆಯಲ್ಲಿ ನೀವು ತಲುಪಲಾಗದ ಸ್ಥಿತಿ ಲಾಗ್ ಇಲ್ಲದೆ ಕ್ಷೇತ್ರದಲ್ಲಿ ಎದುರಾಗುವ ಸ್ಥಿತಿ.

ಸಾಧನದಲ್ಲಿ ಜೀವನಚಕ್ರವನ್ನು ಪರೀಕ್ಷಿಸಿ

ಎಮ್ಯುಲೇಟರ್‌ಗಳು ಸಂಪರ್ಕವನ್ನು ನಕಲಿ ಮಾಡಬಹುದು, ಆದರೆ ಸಮ್ಮತಿ ಮತ್ತು ರದ್ದತಿಯ ಮಾರ್ಗವನ್ನು ನಂಬಲರ್ಹವಾಗಿ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಇವನ್ನು ಸ್ಥಳ ಕದಿಯಲು ಎರಡನೇ VPN ಕ್ಲೈಂಟ್ ಸ್ಥಾಪಿಸಿದ ನಿಜವಾದ ಸಾಧನದಲ್ಲಿ ಚಲಾಯಿಸಿ.

adb shell dumpsys connectivity | grep -i -A3 vpn
adb shell dumpsys activity services | grep -i -A2 vpnservice
adb logcat -s VpnService:V AndroidRuntime:E
adb shell am force-stop com.example.vpnapp

ಸುರಂಗ ಆರಂಭಿಸಿ, ಅಧಿಸೂಚನೆ ಮತ್ತು ಇಂಟರ್‌ಫೇಸ್ ದೃಢೀಕರಿಸಿ, ನಂತರ ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ರದ್ದತಿ ಕಾಲ್‌ಬ್ಯಾಕ್ ಚಲಿಸುತ್ತದೆಯೇ ಮತ್ತು ಸ್ಥಿತಿ ಅಳಿಸುತ್ತದೆಯೇ ಎಂದು ನೋಡಿ. ಆ್ಯಪ್ ಅನ್ನು ಬಲವಂತವಾಗಿ ನಿಲ್ಲಿಸಿ ಮತ್ತು ಇನ್ನೂ ಜೀವಂತ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ವರದಿ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ಯಾವಾಗಲೂ ಆನ್ ಮರುಪ್ರಾರಂಭದ ನಂತರ ಕ್ರಮವನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಆ ಮಾರ್ಗ ಬಳಕೆದಾರ-ಪ್ರಾರಂಭಿತ ಸಂಪರ್ಕಕ್ಕಿಂತ ಭಿನ್ನ. ನೀವು ಹುಡುಕುವುದು ಹಸಿರು ಚಿಹ್ನೆಯಲ್ಲ, ಆ್ಯಪ್ ಇನ್ನು ತನ್ನದಲ್ಲದ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಬಳಕೆಯನ್ನು ನಿಲ್ಲಿಸಿದ ಸಾಕ್ಷ್ಯ.