Android ನಲ್ಲಿ VPN ಸಂಪರ್ಕ ಇದೆಯೇ ಎಂದು ಕೋಡ್‌ನಿಂದ ಪರಿಶೀಲಿಸುವುದು ಹೇಗೆ
Android ನಲ್ಲಿ VPN ಸಂಪರ್ಕ ಸ್ಥಿತಿಯನ್ನು ನೀಡುವ getter ಇಲ್ಲ. ನೆಟ್‌ವರ್ಕ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಕೇಳಿ, ಸಾಗಣೆ ಬದಲಾವಣೆಗಳನ್ನು ಗಮನಿಸಿ, ಮತ್ತು ಆ್ಯಪ್ ಒಪ್ಪಿಗೆ, ಸಾಧನ ಸ್ಥಿತಿ ಹಾಗೂ ಸರ್ವರ್ ಸಾಕ್ಷ್ಯವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ.
Android ಗೆ VPN ಸಂಪರ್ಕಗೊಂಡಿದೆಯೇ ಎಂದು ಕೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ. VpnService ಸಂಪರ್ಕ ಸ್ಥಿತಿಯನ್ನು ನೀಡುವ getter ಅನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸ್ಟೇಟಸ್ ಬಾರ್‌ನಲ್ಲಿನ ಕೀ ಐಕಾನ್ ಅನ್ನು ಸಿಸ್ಟಂ ಬರೆಯುತ್ತದೆ, ನಿಮ್ಮ ಆ್ಯಪ್ ಓದಬಲ್ಲ ಯಾವುದೂ ಅಲ್ಲ. ನೀವು ಮಾಡಬಹುದಾದ್ದು ಸಂಪರ್ಕ ಸ್ಟಾಕ್‌ಗೆ ಇನ್ನೂ ಸಣ್ಣ ಪ್ರಶ್ನೆ ಹಾಕುವುದು: ಈ ಆ್ಯಪ್‌ನ ಟ್ರಾಫಿಕ್ ಯಾವ ನೆಟ್‌ವರ್ಕ್ ಬಳಸುತ್ತಿದೆ, ಮತ್ತು ಆ ನೆಟ್‌ವರ್ಕ್ VPN ಸಾಗಣೆಯನ್ನು ಹೊತ್ತಿದೆಯೇ. ಈ ಕೈಪಿಡಿಯು ತಪ್ಪು ಫಲಿತಾಂಶಗಳನ್ನು ತಪ್ಪಿಸುವ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲನೆಗಳನ್ನು ನಡೆಸುತ್ತದೆ, ಸಾಧನದಲ್ಲಿನ ಶೆಲ್ ಆಜ್ಞೆಯಿಂದ ಆ್ಯಪ್‌ನಲ್ಲಿ ಬಿಡುವ ಕಾಲ್‌ಬ್ಯಾಕ್ ವರೆಗೆ.
ಆ್ಯಪ್ ಕೋಡ್ ಮುಟ್ಟುವ ಮೊದಲು ಶೆಲ್‌ನಿಂದ ಸಾಧನವನ್ನು ಪರಿಶೀಲಿಸಿ
ಮೊದಲು ಮೂಲ ಸ್ಥಿತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ. adb shell dumpsys connectivity ಸಿಸ್ಟಂಗೆ ತಿಳಿದಿರುವ ಪ್ರತಿಯೊಂದು ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಬ್ಲಾಕ್ ತನ್ನ ಸಾಗಣೆಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ VPN ನೆಟ್‌ವರ್ಕ್ ಆ ಪಟ್ಟಿಯಲ್ಲಿ VPN ಜೊತೆ ಕಾಣುತ್ತದೆ. ಎಲ್ಲಕ್ಕಿಂತ ಮೊದಲು ಡೀಫಾಲ್ಟ್ ನೆಟ್‌ವರ್ಕ್ ಬ್ಲಾಕ್ ಓದಿ, ನಂತರ ಅದೇ ಸಾಗಣೆಯನ್ನು ಹೊತ್ತ ಇತರ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಹುಡುಕಿ.
ಎರಡು ಔಟ್‌ಪುಟ್‌ಗಳು ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ. VPN ನೆಟ್‌ವರ್ಕ್ ಇದೆಯೇ ಎಂಬುದು ನಿಮ್ಮ ಆ್ಯಪ್ ಅದನ್ನು ಬಳಸುತ್ತಿದೆಯೇ ಎಂಬುದಕ್ಕೆ ಸಮವಲ್ಲ, ಮತ್ತು ಕೆಲಸದ ಪ್ರೊಫೈಲ್ ಅಥವಾ ಎರಡನೇ ಬಳಕೆದಾರರಿರುವ ಸಾಧನದಲ್ಲಿ ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆ ನೇರವಾಗಿ ಇಂಟರ್ನೆಟ್‌ನೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೂ ಎರಡೂ ಒಟ್ಟಿಗೆ ನಿಜವಾಗಬಹುದು. ನಿಮ್ಮ ಸಾಕೆಟ್‌ಗಳು ಏನು ಮಾಡುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು ಸಕ್ರಿಯ ನೆಟ್‌ವರ್ಕ್ ಸಾಲು.
ಆ್ಯಪ್ ಬಳಸುತ್ತಿರುವ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಕೇಳಿ
ಕೋಡ್‌ನಲ್ಲಿ ಸಾಮರ್ಥ್ಯ ಪರೀಕ್ಷೆ ನಾಲ್ಕು ಸಾಲುಗಳು. ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನಲ್ಲಿ ACCESS_NETWORK_STATE ಕೇಳಿ, ನಂತರ ಸಕ್ರಿಯ ನೆಟ್‌ವರ್ಕ್‌ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು VPN ಸಾಗಣೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ:
ConnectivityManager cm = (ConnectivityManager)
context.getSystemService(Context.CONNECTIVITY_SERVICE);
Network active = cm.getActiveNetwork();
NetworkCapabilities caps = cm.getNetworkCapabilities(active);
boolean vpnInUse = caps != null
&& caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);
ಉತ್ತರ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಣ್ಣದು: ಆ್ಯಪ್‌ನ ಡೀಫಾಲ್ಟ್ ನೆಟ್‌ವರ್ಕ್ ಈಗ VPN ಆಗಿದೆಯೇ. ಯಾವ VPN, ಅದು ನಿಮ್ಮದೇ ಆಗಿದೆಯೇ, ಅಥವಾ ಸುರಂಗವು ಅದರ ಆಚೆಯ ತುದಿಯನ್ನು ತಲುಪುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಅದು ಹೇಳುವುದಿಲ್ಲ. true ಅನ್ನು “ಟ್ರಾಫಿಕ್ ಯಾವುದೋ ಸುರಂಗದ ಮೂಲಕ ಹೊರಹೋಗುತ್ತದೆ” ಎಂದು ಪರಿಗಣಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಲೆಕ್ಕವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಮೂರು ವಿಷಯಗಳನ್ನು ಮೌನವಾಗಿ ಒಟ್ಟಿಗೆ ಸೂಚಿಸುವ ಬೂಲಿಯನ್, ಬಳಕೆದಾರರು VPN ಮೂಲಕ ಬ್ರೌಸ್ ಮಾಡುತ್ತಿರುವಾಗ ಸೆಟ್ಟಿಂಗ್ಸ್ ಪರದೆ VPN ಆಫ್ ಎಂದು ವರದಿ ಮಾಡಲು ಕಾರಣವಾಗುತ್ತದೆ.
ಬದಲಾಗಿ ಯಾವುದೇ VPN ನೆಟ್‌ವರ್ಕ್ ಇದೆಯೇ ಎಂದು ತಿಳಿಯಬೇಕಾದರೆ, cm.getAllNetworks() ಅನ್ನು ಪುನರಾವರ್ತಿಸಿ ಪ್ರತಿ ಸಾಮರ್ಥ್ಯ ಗುಂಪನ್ನು ಪರೀಕ್ಷಿಸಿ. ಇತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಆವರಿಸುವ ಆದರೆ ನಿಮ್ಮದನ್ನು ಆವರಿಸದ ಆ್ಯಪ್-ವಿಶಿಷ್ಟ VPN ಚಾಲನೆಯಲ್ಲಿರುವ ಸಾಧನದಲ್ಲಿ ಎರಡು ಉತ್ತರಗಳು ಬೇರೆಯಾಗುತ್ತವೆ, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸವೇ ಸ್ಪಷ್ಟವಾಗಿ ಆನ್ ಆಗಿರುವ VPN ಆ್ಯಪ್‌ಗೆ ಕಾಣುತ್ತಿಲ್ಲ ಎಂಬ ದೋಷ ವರದಿಗಳ ಹೆಚ್ಚಿನ ಮೂಲ.
ಪೋಲಿಂಗ್ ಬದಲು ಬದಲಾವಣೆಗಳನ್ನು ಗಮನಿಸಿ
ಟೈಮರ್ ಪೋಲಿಂಗ್ ಈ ಪ್ರಶ್ನೆಗೆ ಸರಿಯಾದ ರೂಪವಲ್ಲ, ಏಕೆಂದರೆ ಸ್ಥಿತಿ ಬದಲಾವಣೆಗಳು ಈವೆಂಟ್‌ಗಳಾಗಿ ಬರುತ್ತವೆ. VPN ಸಾಗಣೆಗೆ ಹೊಂದಿಕೆಯಾಗುವ ವಿನಂತಿಯನ್ನು ನೋಂದಾಯಿಸಿ ಮತ್ತು ಹೊಂದಿಕೆಯಾಗುವ ನೆಟ್‌ವರ್ಕ್ ಕಾಣಿಸಿಕೊಂಡಾಗ, ಮಾಯವಾದಾಗ ಅಥವಾ ಬದಲಾದಾಗ ಫ್ರೇಮ್‌ವರ್ಕ್ ನಿಮಗೆ ತಿಳಿಸಲಿ:
NetworkRequest request = new NetworkRequest.Builder()
.addTransportType(NetworkCapabilities.TRANSPORT_VPN)
.removeCapability(NetworkCapabilities.NET_CAPABILITY_NOT_VPN)
.build();
cm.registerNetworkCallback(request, callback);
VPN ನೆಟ್‌ವರ್ಕ್ ಎಂದಿಗೂ NET_CAPABILITY_NOT_VPN ಅನ್ನು ಹೊತ್ತಿರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸ್ಪಷ್ಟ ತೆಗೆದುಹಾಕುವಿಕೆ ಉದ್ದೇಶವನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಅದಿಲ್ಲದಿದ್ದರೂ ವಿನಂತಿ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ, ಆದರೆ ಮುಂದೆ ಕೋಡ್ ಓದುವವರು ಅದನ್ನು ತಾವೇ ಕಂಡುಕೊಳ್ಳಬೇಕು.
ನೋಂದಣಿ ವೀಕ್ಷಣೆ ಬೇಕಾದ ವ್ಯಾಪ್ತಿಗೆ ಸೇರಿದ್ದು, ಸಾಮಾನ್ಯವಾಗಿ ಪರದೆ ಅಥವಾ ಮುಂಚೂಣಿ ಸೇವೆ. onStop ಅಥವಾ onDestroy ನಲ್ಲಿ ನೋಂದಣಿ ತೆಗೆಯಿರಿ, ಮತ್ತು ಈಗಾಗಲೇ ಹೋದ ಆಕ್ಟಿವಿಟಿಗೆ ಕಾಲ್‌ಬ್ಯಾಕ್ ಲಗತ್ತಿಸಿ ಬಿಡಬೇಡಿ. ಗೋಚರ ಘಟಕವಿಲ್ಲದ ಆ್ಯಪ್ ಶಾಶ್ವತ ವೀಕ್ಷಕನಿಗೆ ಕೆಟ್ಟ ಆತಿಥೇಯ, ಮತ್ತು ನೀವು ಮರೆತ ಕಾಲ್‌ಬ್ಯಾಕ್‌ಗಳೇ ಸಂರಚನೆ ಬದಲಾವಣೆಯ ನಂತರ ಕ್ರ್ಯಾಶ್ ಆಗುವಂಥವು.
ಮೂರು ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ
ಈ ಕ್ಷೇತ್ರದ ಗೊಂದಲದ ಹೆಚ್ಚಿನ ಭಾಗ ಮೂರು ವಿಭಿನ್ನ ಪರಿಶೀಲನೆಗಳನ್ನು ಒಂದೆಂದು ಪರಿಗಣಿಸುವುದರಿಂದ ಬರುತ್ತದೆ. ಅವು ಬೇರೆ ಬೇರೆ API ಬಳಸುತ್ತವೆ, ಮತ್ತು ಒಂದು ನಿಜವಾಗಿರುವಾಗ ಉಳಿದವು ಸುಳ್ಳಾಗಿರಬಹುದು.
| Question | How you answer it | What a yes means |
|---|---|---|
| Did the user grant VPN consent to my app? | VpnService.prepare() returns null | Consent exists; the tunnel may still be down |
| Is the device sending default traffic through a VPN? | TRANSPORT_VPN on the active network | Something is tunneling, not necessarily your app |
| Did this request arrive through the VPN? | Source address seen by the server | Proof for that connection, nothing wider |
ಮೂರನೇ ಸಾಲು ಜನರು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಉತ್ತರಿಸಲು ಪ್ರಯತ್ನಿಸುವಂಥದ್ದು, ಮತ್ತು ಅಲ್ಲಿ ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. VPN ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ವಿಳಾಸ ಪೂಲ್ ಕೊಡಿ ಮತ್ತು ಸರ್ವರ್‌ನಲ್ಲಿ ಮೂಲ ವಿಳಾಸವನ್ನು ಓದಿ; ಸೆಷನ್ ಮಧ್ಯದಲ್ಲಿ ಬಳಕೆದಾರರು ಸುರಂಗ ಬದಲಿಸಿದರೂ ಉಳಿಯುವ ಏಕೈಕ ಸಾಕ್ಷ್ಯ ಅದು.
ತಪ್ಪು ಫಲಿತಾಂಶಗಳನ್ನು ತಳ್ಳಿಹಾಕುವ ಪರಿಶೀಲನಾ ಕ್ರಮ
ಇನ್ನೂ ಚಲಾವಣೆಯಲ್ಲಿರುವ ಹಳೆಯ ಮಾದರಿ ಕೋಡ್ getNetworkInfo(ConnectivityManager.TYPE_VPN) ಅನ್ನು ಕರೆಯುತ್ತದೆ. ಆ ಕರೆ ನಿರುಪಯುಕ್ತವಾಗಿದೆ, ಮತ್ತು ಹಲವು ಬಿಡುಗಡೆಗಳಲ್ಲಿ VPN ಸಂಪರ್ಕಗೊಂಡಿದ್ದರೂ null ಹಿಂತಿರುಗಿಸಿತು, ಆದ್ದರಿಂದ ನಕಲಿಸಿದ ತುಣುಕುಗಳು ಕೆಲಸ ಮಾಡುವ ಸಾಧನದಲ್ಲಿ ಮುರಿದಂತೆ ಕಾಣುತ್ತವೆ. ಸಾಮರ್ಥ್ಯ ಪರಿಶೀಲನೆಗಳು ಆ ಬಲೆ ತಪ್ಪಿಸಿ Android 5.0 ರಿಂದ ಮುಂದೆ ಒಂದೇ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ. ಇನ್ನೂ ಅದನ್ನು ಕರೆಯುವ ಕೋಡ್‌ಬೇಸ್ ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಫಾಲ್‌ಬ್ಯಾಕ್‌ನಲ್ಲಿ ಸುತ್ತುವ ಬದಲು ಕರೆಯನ್ನೇ ಬದಲಾಯಿಸಿ, ಏಕೆಂದರೆ ತಪ್ಪು ಉತ್ತರವನ್ನು ಮೊದಲು ಉಂಟುಮಾಡಿದ್ದೇ ಆ ಫಾಲ್‌ಬ್ಯಾಕ್.
ಒಂದು ಸುಳಿವಿಗೆ ಎಚ್ಚರಿಕೆ ಬೇಕು. ಬಾಹ್ಯ ಸೇವೆ ವರದಿ ಮಾಡುವ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು VPN ನಿರ್ಗಮನ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸುವುದು ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೋ ಸಾಬೀತು ಮಾಡುತ್ತದೆ, ಆದರೆ ಪ್ರತಿ ಪರಿಶೀಲನೆಗೂ ಮೂರನೇ ಪಕ್ಷದ ವಿನಂತಿ ಸೇರಿಸುತ್ತದೆ, ಆ ಸೇವೆ ಚಾಲನೆಯಲ್ಲಿರುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ, ಮತ್ತು ಕ್ಯಾಶ್ ಆಗಬಹುದು ಅಥವಾ ನಿರ್ಬಂಧಿಸಲ್ಪಡಬಹುದು. ಅದನ್ನು ಕೈಯಿಂದ ಮಾಡುವ ರೋಗನಿರ್ಣಯವಾಗಿ ಇರಿಸಿ, ಆ್ಯಪ್ ಒಳಗಿನ ಸ್ಥಿತಿ ಪರಿಶೀಲನೆಯಾಗಿ ಎಂದಿಗೂ ಬಳಸಬೇಡಿ.
ಈ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲನೆಗಳನ್ನು ನಡೆಸಿ ಮತ್ತು ಬಳಕೆದಾರರ ವರದಿಗೆ ವಿರುದ್ಧವಾಗುವ ಮೊದಲನೆಯದರಲ್ಲಿ ನಿಲ್ಲಿಸಿ: ಶೆಲ್ ಸಾಗಣೆ ಪಟ್ಟಿ, ಸಕ್ರಿಯ ನೆಟ್‌ವರ್ಕ್ ಸಾಮರ್ಥ್ಯಗಳು, ಸುರಂಗ ಆನ್-ಆಫ್ ಮಾಡುವಾಗಿನ ಕಾಲ್‌ಬ್ಯಾಕ್ ಈವೆಂಟ್‌ಗಳು, ನಂತರ ಸರ್ವರ್-ಬದಿಯ ಮೂಲ ವಿಳಾಸ. ನಾಲ್ಕೂ ಹೊಂದಿಕೆಯಾದರೂ ಆ್ಯಪ್ ಇನ್ನೂ ತಪ್ಪಾಗಿ ವರ್ತಿಸಿದರೆ, ದೋಷ Android ನ ನೆಟ್‌ವರ್ಕ್ ನೋಟದಲ್ಲಲ್ಲ, ನಿಮ್ಮ ಸ್ವಂತ ಸ್ಥಿತಿ ಯಂತ್ರದಲ್ಲಿದೆ.