Android ನಲ್ಲಿ VPN ಪತ್ತೆಹಚ್ಚುವುದು: tun0 ಮತ್ತು ping ಏಕೆ ದಾರಿ ತಪ್ಪಿಸುತ್ತವೆ

ಇಂಟರ್ಫೇಸ್ ಹೆಸರು ಒಂದು ಸಂಪ್ರದಾಯ; ping ಒಂದು ಹೋಸ್ಟ್ ತಲುಪಬಹುದಾಗಿತ್ತು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ ಏನು ಘೋಷಿಸುತ್ತದೆ ಎಂದು NetworkCapabilities ಗೆ ಕೇಳಿ, ನಂತರ ಕಾಲ್ಬ್ಯಾಕ್‌ಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿ.

ಹೆಚ್ಚಿನ Android ಅಪ್ಲಿಕೇಶನ್‌ಗಳು VPN ಪತ್ತೆಹಚ್ಚಲು ಬಳಸುವ ಪರಿಶೀಲನೆ ಒಂದು ಇಂಟರ್ಫೇಸ್ ಹೆಸರು, ಮತ್ತು ಅದು ಎಂದಿಗೂ VPN ಪರಿಶೀಲನೆಯಾಗಿರಲಿಲ್ಲ. ಡೆವಲಪರ್ ನಿರೀಕ್ಷಿಸಿದ ಸ್ಟ್ರಿಂಗ್‌ನೊಂದಿಗೆ ಯಾವುದೋ ಇಂಟರ್ಫೇಸ್ ಇದೆ ಎಂದು ಅದು ವರದಿ ಮಾಡುತ್ತದೆ, ಅದು ಒಂದು ಸಾಧನದಲ್ಲಿ OpenVPN ಎಂದರ್ಥ ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ ಸಂಪೂರ್ಣ ಅಸಂಬದ್ಧವಾದುದನ್ನು ಅರ್ಥೈಸುತ್ತದೆ. ping ಅದೇ ರೀತಿಯ ಸಾಕ್ಷ್ಯ: ಒಂದು ಗಮ್ಯಸ್ಥಾನ ಪ್ರತಿಕ್ರಿಯಿಸಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಟನೆಲ್ ಪ್ಯಾಕೆಟ್ ಸಾಗಿಸಿತು ಎಂದಲ್ಲ. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಿಜವಾಗಿ ಒದಗಿಸುವುದು ನೆಟ್‌ವರ್ಕ್‌ಗಳ ಗುಂಪು ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಘೋಷಿಸುವ ಸಾರಿಗೆಗಳು, ಮತ್ತು ಇದು ಬೇರೆ ಉತ್ತರವಿರುವ ಬೇರೆ ಪ್ರಶ್ನೆ.

ಪುರಾಣ: tun0 ಇದ್ದರೆ VPN ಚಾಲನೆಯಲ್ಲಿದೆ

Android VPN ಅಪ್ಲಿಕೇಶನ್‌ಗಳು VpnService ಅನುಷ್ಠಾನಗಳು, ಅವು ಸಿಸ್ಟಮ್‌ಗೆ tun ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ನೀಡುತ್ತವೆ. ಇಂಟರ್ಫೇಸ್ ಹೆಸರು ಅದನ್ನು ರಚಿಸಿದವರಿಂದ ಬರುತ್ತದೆ: OpenVPN ಸಾಮಾನ್ಯವಾಗಿ tun0 ರಚಿಸುತ್ತದೆ, PPTP ಮತ್ತು L2TP ppp0 ರಚಿಸುತ್ತವೆ, WireGuard ತನ್ನ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಟನೆಲ್‌ನ ಹೆಸರಿಡುತ್ತದೆ, ಮತ್ತು IPsec ಟನೆಲ್ ಸಾಂಪ್ರದಾಯಿಕ ಹೆಸರನ್ನೇ ತೋರಿಸದಿರಬಹುದು. ಆದ್ದರಿಂದ /proc/net/dev ಓದುವುದು ಅಥವಾ NetworkInterface ವಸ್ತುಗಳನ್ನು ಎಣಿಸುವುದು ಸಂಪ್ರದಾಯವನ್ನು ಹುಡುಕುತ್ತದೆ, ಸತ್ಯವನ್ನಲ್ಲ.

ದೋಷದ ಎರಡೂ ದಿಕ್ಕುಗಳು ಜೀವಂತವಾಗಿವೆ. ಸಾಧನದಲ್ಲಿ ಬಳಕೆದಾರರ VPN ಗೆ ಸಂಬಂಧವಿಲ್ಲದ ಸ್ಥಳೀಯ ಟನೆಲ್‌ಗೆ tun0 ಇರಬಹುದು, ಮತ್ತು ಸಂಪೂರ್ಣ ಆರೋಗ್ಯಕರ WireGuard ಟನೆಲ್ tun0 ಸ್ಟ್ರಿಂಗ್ ಮಾತ್ರ ತಿಳಿದ ಪರಿಶೀಲನೆಗೆ ಅಗೋಚರವಾಗಿರಬಹುದು. ಒಂದೇ ಕಾರ್ಯದಲ್ಲಿ ತಪ್ಪು ಧನಾತ್ಮಕ ಮತ್ತು ತಪ್ಪು ಋಣಾತ್ಮಕ ಫಲಿತಾಂಶಗಳು ಅದನ್ನು ರೋಗನಿರ್ಣಯವಾಗಿ ನಿರುಪಯುಕ್ತಗೊಳಿಸುತ್ತವೆ, ಏಕೆಂದರೆ «VPN ಪತ್ತೆಯಾಗಿಲ್ಲ» ಎನ್ನುವ ಬೆಂಬಲ ಟಿಕೆಟ್ ಅನ್ನು ಯಾವ ದಿಕ್ಕಿನಲ್ಲೂ ನಂಬಲಾಗದು.

ಪ್ರವೇಶವೂ ಕಿರಿದಾಗಿದೆ. ಹೊಸ Android ಬಿಡುಗಡೆಗಳು ಸಾಮಾನ್ಯ ಅಪ್ಲಿಕೇಶನ್ /proc ನಿಂದ ಏನನ್ನು ಓದಬಹುದು ಎಂಬುದನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ Android 8 ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ ಹೆಸರು ಆಧಾರಿತ ಪರಿಶೀಲನೆ ಯಾವುದೇ ಕೋಡ್ ಬದಲಾವಣೆ ಇಲ್ಲದೆ ನಂತರದ ಸಾಧನದಲ್ಲಿ ಖಾಲಿ ಪಟ್ಟಿ ಹಿಂತಿರುಗಿಸಬಹುದು. ಪರಿಶೀಲನೆ ಮೌನವಾಗಿ ತೆರೆದ ದಿಕ್ಕಿಗೆ ವಿಫಲವಾದಾಗ, ಟನೆಲ್ ಸರಿಯಾಗಿರುವ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ VPN ಇಲ್ಲ ಎಂದು ಅಪ್ಲಿಕೇಶನ್ ತೀರ್ಮಾನಿಸುತ್ತದೆ.

ಪುರಾಣ: ಯಶಸ್ವಿ ping ಎಂದರೆ ಟನೆಲ್ ಸಂಚಾರ ಸಾಗಿಸುತ್ತಿದೆ

ಆಂತರಿಕ ಹೋಸ್ಟ್‌ಗೆ ping ಆ ಹೋಸ್ಟ್‌ಗೆ ಮಾರ್ಗವಿದ್ದಾಗಲೆಲ್ಲಾ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ. ವಿಭಜಿತ ಟನೆಲಿಂಗ್‌ನಲ್ಲಿ ಟನೆಲ್ ಚಾಲನೆಯಲ್ಲಿದ್ದು ಸಂಪೂರ್ಣ ಬೇರೆ ಏನೋ ಮಾಡುತ್ತಿರುವಾಗ ಹೋಸ್ಟ್ Wi-Fi ಮೂಲಕ ತಲುಪಬಹುದಾಗಿರಬಹುದು. ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ VPN ನಲ್ಲಿ ping ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್ ಟನೆಲ್‌ನಿಂದ ಹೊರಗಿರಿಸಲ್ಪಡಬಹುದು, ಆದ್ದರಿಂದ ICMP ಪ್ರತಿಧ್ವನಿ ಅದರ ಹೊರಗೆ ಹೋಗಿ ಮರಳಿ ಬರುತ್ತದೆ, ಇದು ಪರಿಶೀಲನೆ ಊಹಿಸುವುದಕ್ಕೆ ವಿರುದ್ಧವಾದುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

ICMP ಮತ್ತು TCP ಸಹ ಪ್ರತ್ಯೇಕವಾಗಿ ಫಿಲ್ಟರ್ ಆಗುತ್ತವೆ. ಪ್ರತಿಧ್ವನಿ ವಿನಂತಿಗಳನ್ನು ಅನುಮತಿಸಿ ಸೇವೆಗೆ ಬೇಕಾದ TCP ಪೋರ್ಟ್ ಅನ್ನು ಬಿಡುವ ಟನೆಲ್ ping ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಅದು ಸಾಧನದ ಗುಣವಲ್ಲ, ಆಚೆಗಿನ ಫೈರ್‌ವಾಲ್ ನಿಯಮ. ಯಶಸ್ವಿ ping ನ ಏಕೈಕ ಪ್ರಾಮಾಣಿಕ ಓದುವಿಕೆ ಎಂದರೆ ಈ ಗಮ್ಯಸ್ಥಾನ ಈ ಕ್ಷಣದಲ್ಲಿ ಈ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿತು.

ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಿಜವಾಗಿ ಏನನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ

API 21 ರಿಂದ ConnectivityManager.getAllNetworks() ಸಿಸ್ಟಮ್‌ಗೆ ತಿಳಿದಿರುವ ಪ್ರತಿಯೊಂದು ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು getNetworkCapabilities(network) ಆ ನೆಟ್‌ವರ್ಕ್ ಏನು ಘೋಷಿಸುತ್ತದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. VPN ನೆಟ್‌ವರ್ಕ್ TRANSPORT_VPN ಹೊಂದಿರುತ್ತದೆ. ಎಲ್ಲಾ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ಮೇಲೆ ಲೂಪ್ ಮಾಡುವುದು ಒಂದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಈ ಸಾಧನದಲ್ಲಿ ಈಗ ಯಾವುದಾದರೂ VPN ಚಾಲನೆಯಲ್ಲಿದೆಯೇ?

ಎರಡನೇ, ಹೆಚ್ಚು ಸಂಕುಚಿತ ಪ್ರಶ್ನೆಗೆ ಬೇರೆ ಕರೆ ಬೇಕು. getActiveNetwork() ಅಪ್ಲಿಕೇಶನ್ ಸಂಚಾರ ಈಗ ಬಳಸುವ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಮೇಲೆ ಅದೇ ಸಾಮರ್ಥ್ಯವನ್ನು ಪರಿಶೀಲಿಸುವುದು ಉತ್ತರಿಸುತ್ತದೆ: ನನ್ನ ಸಂಚಾರ VPN ಮೂಲಕ ಹೋಗುತ್ತದೆಯೇ? ಎರಡೂ ಒಪ್ಪದಿರಬಹುದು, ಮತ್ತು ಆ ಭಿನ್ನಾಭಿಪ್ರಾಯ ಮಾಹಿತಿಪೂರ್ಣವಾಗಿದೆ. ಚಾಲನೆಯಲ್ಲಿದ್ದರೂ ಪ್ರಸ್ತುತವಲ್ಲದ VPN ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ರೂಟಿಂಗ್ ಅಥವಾ ವಿಭಜಿತ-ಟನೆಲ್ ಸಂರಚನೆಯತ್ತ ಸೂಚಿಸುತ್ತದೆ, ಕಾಣೆಯಾದ ಟನೆಲ್‌ನತ್ತ ಅಲ್ಲ.

Network active = cm.getActiveNetwork();
NetworkCapabilities caps = cm.getNetworkCapabilities(active);
boolean viaVpn = caps != null
    && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

ಎರಡೂ ಕರೆಗಳನ್ನು ರಕ್ಷಿಸಿ. ಪಟ್ಟಿ ಮತ್ತು ಪ್ರಶ್ನೆಯ ನಡುವೆ ಕಣ್ಮರೆಯಾದ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸಾಮರ್ಥ್ಯಗಳು null ಆಗಿರಬಹುದು, ಮತ್ತು ಹಸ್ತಾಂತರದ ಸಮಯದಲ್ಲಿ ಸಕ್ರಿಯ ನೆಟ್‌ವರ್ಕ್ null ಆಗಿರಬಹುದು. NET_CAPABILITY_NOT_VPN ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ಉಪಯುಕ್ತ: ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ VPN ಸಾರಿಗೆ ಧ್ವಜ ಕಾಣೆಯಾಗಿದೆ ಎಂಬುದಲ್ಲ, ಅದು ಖಂಡಿತವಾಗಿ ಟನೆಲ್ ಅಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಲು.

NetworkInfo API ಯೊಂದಿಗೆ ಅದೇ ಪುರಾಣವಾಗಿತ್ತು

NetworkInfo ಜೊತೆಗಿನ ConnectivityManager.TYPE_VPN ಈ ಪರಿಶೀಲನೆಯ ಎರಡನೇ ಪೀಳಿಗೆ, ಮತ್ತು ಅದು ಕಾರಣಕ್ಕಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಆಧುನಿಕ ಬಿಡುಗಡೆಗಳಲ್ಲಿ ಟನೆಲ್ ಸಂಪರ್ಕಗೊಂಡಿದ್ದರೂ VPN ಗೆ ಹಿಂತಿರುಗಿಸಿದ ವಸ್ತು null ಆಗಿರಬಹುದು, ಆದ್ದರಿಂದ null ಅನ್ನು «VPN ಇಲ್ಲ» ಎಂದು ಪರಿಗಣಿಸುವ ಕೋಡ್ ಉತ್ತರ ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ಸಾಧನಗಳಲ್ಲಿ ಮೌನವಾಗಿ ತಪ್ಪು ಋಣಾತ್ಮಕ ವರದಿ ಮಾಡುತ್ತದೆ.

ಸಾಮಾನ್ಯವಾಗಿ ಜೊತೆಗೂಡುವ ಪ್ರಸಾರವೂ ಉತ್ತಮವಲ್ಲ. CONNECTIVITY_CHANGE ಗೆ VPN ಪರಿವರ್ತನೆಗಳನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುವ ದಾಖಲಿತ ಇತಿಹಾಸವಿದೆ, ಪ್ರತಿ ನೆಟ್‌ವರ್ಕ್ ಬದಲಾವಣೆಯಲ್ಲದೆ VPN ಸಂಪರ್ಕಗೊಂಡಾಗ ಅಥವಾ ಕಡಿತಗೊಂಡಾಗ ಮಾತ್ರ ಪ್ರಚೋದಿಸಿದ ನಿರ್ಮಾಣಗಳೂ ಸೇರಿವೆ. ಅದರ ಮೇಲೆ ನಿರ್ಮಿಸಿದ ಆಲಿಸುವವರು ಮುಂದಿನ ಪೂರ್ಣ ಮರುಸಂಪರ್ಕದವರೆಗೆ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ದೃಷ್ಟಿಯಿಂದ ದೂರ ಸರಿಯುವ ಸ್ಥಿತಿ ಚರಾಕ್ಷರವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ.

ಪೋಲಿಂಗ್ ಬದಲು ಕಾಲ್ಬ್ಯಾಕ್‌ಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿ

TRANSPORT_VPN ಅಗತ್ಯವಿರುವ ಮತ್ತು NET_CAPABILITY_NOT_VPN ತೆಗೆಯುವ NetworkRequest ನೋಂದಿಸಿ, ನಂತರ ಆ ವಿನಂತಿಯೊಂದಿಗೆ registerNetworkCallback ಕರೆಯಿರಿ. ಆಗ onAvailable ಮತ್ತು onLost ಘೋಷಣೆ ಯಾವಾಗ ಬದಲಾಗುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತವೆ, ಮತ್ತು ಅದೇ ನಿಮಗೆ ನಿಜವಾಗಿ ಮುಖ್ಯವಾದ ಘಟನೆ. ಘಟಕ ನಿಲ್ಲಿಸಿದಾಗ ಕಾಲ್ಬ್ಯಾಕ್ ನೋಂದಣಿ ರದ್ದುಮಾಡಿ, ಇಲ್ಲದಿದ್ದರೆ ಅಪ್ಲಿಕೇಶನ್ ಸತ್ತ ಪರದೆಗೆ ಉಲ್ಲೇಖ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಕಾಲ್ಬ್ಯಾಕ್ ಮುಂದುವರಿಯುತ್ತದೆ.

NetworkRequest req = new NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .removeCapability(NetworkCapabilities.NET_CAPABILITY_NOT_VPN)
    .build();
cm.registerNetworkCallback(req, callback);

ಇದಕ್ಕೆ ACCESS_NETWORK_STATE ಬೇಕು, ಅದು ಸಾಮಾನ್ಯ ಅನುಮತಿ: root ಇಲ್ಲ, ಬಳಕೆದಾರ ಸಮ್ಮತಿ ಸಂವಾದ ಇಲ್ಲ, VPN ಅನುಮತಿ ಇಲ್ಲ. ಟೈಮರ್‌ನಲ್ಲಿ ಪೋಲಿಂಗ್ ಜನರು ಆಶ್ರಯಿಸುವ ಪರ್ಯಾಯ, ಮತ್ತು ಅದು ಬ್ಯಾಟರಿ ಬರಿದುಮಾಡುತ್ತದೆ ಮತ್ತು ಮಧ್ಯಂತರಕ್ಕಿಂತ ಚಿಕ್ಕ ಪರಿವರ್ತನೆಯನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಅದೇ ಬಳಕೆದಾರ ವರದಿ ಮಾಡುವ ಪರಿವರ್ತನೆ.

ಉತ್ತರ ಇನ್ನೂ ನಿಮಗೆ ಏನು ಹೇಳಲಾರದು

ಈ API ಗಳಲ್ಲಿ ಯಾವುದೂ ಟನೆಲ್ ಆರೋಗ್ಯಕರವೇ, ಯಾವ ಸರ್ವರ್‌ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಅಥವಾ ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್ ಸಂಚಾರ ಅದರೊಳಗಿದೆಯೇ ಎಂದು ವರದಿ ಮಾಡುವುದಿಲ್ಲ. VPN ನೆಟ್‌ವರ್ಕ್ ಬಳಸಬಹುದಾದ ಮಾರ್ಗಗಳಿಲ್ಲದೆ ಇರಬಹುದು, ಮತ್ತು ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಟನೆಲ್ ಪ್ರಶ್ನೆ ಕೇಳುವ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೊರಗಿಡಬಹುದು.

ಆದ್ದರಿಂದ ಪರಿಶೀಲನೆ ನೋಡಿದ್ದನ್ನು ದಾಖಲಿಸಿ, ಬೂಲಿಯನ್ ಮಾತ್ರವಲ್ಲ. ನೆಟ್‌ವರ್ಕ್ ಗುರುತಿಸುವಿಕೆ, ಘೋಷಿತ ಸಾರಿಗೆಗಳು ಮತ್ತು ಆ ನೆಟ್‌ವರ್ಕ್ ಸಕ್ರಿಯವಾಗಿತ್ತೇ ಎಂಬುದನ್ನು ಲಾಗ್ ಮಾಡಿ. «VPN ಪತ್ತೆಯಾಗಿಲ್ಲ» ಎನ್ನುವ ವರದಿ ನಿರುಪಯುಕ್ತ, ಆದರೆ ನೆಟ್‌ವರ್ಕ್ TRANSPORT_VPN ಘೋಷಿಸಿತು ಆದರೆ getActiveNetwork() Wi-Fi ಹಿಂತಿರುಗಿಸಿತು ಎನ್ನುವ ವರದಿ ನೇರವಾಗಿ ರೂಟಿಂಗ್ ಅಥವಾ ಹೊರಗಿಡುವ ಪಟ್ಟಿಯತ್ತ ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಯಾರಾದರೂ ಕೆಲಸ ಮಾಡಬಹುದಾದ ಸರಿಪಡಿಸುವಿಕೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು