ಇನ್ನೊಂದು VPN ಈಗಾಗಲೇ ಸಕ್ರಿಯವಾಗಿದ್ದಾಗ VpnService ರಕ್ಷಣೆ ವಿಫಲವಾಗುತ್ತದೆ

ನಿಮ್ಮ ಆ್ಯಪ್ VpnService.prepare ಅನ್ನು ಕರೆಯುತ್ತದೆ, null ಪಡೆಯುತ್ತದೆ, ಸುರಂಗ ನಿರ್ಮಿಸುತ್ತದೆ, ಮತ್ತು ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮಾನ್ಯವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೂ ಸರ್ವರ್‌ಗೆ ಏನೂ ತಲುಪುವುದಿಲ್ಲ. ಅಥವಾ prepare Intent ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಬಳಕೆದಾರರು ಅದನ್ನು ಅನುಮೋದಿಸುತ್ತಾರೆ, ಮತ್ತು establish ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ. ಎರಡೂ ಫಲಿತಾಂಶಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಅರ್ಥ ನೀಡುತ್ತವೆ: ಇನ್ನೊಂದು ಆ್ಯಪ್ ಈ ಬಳಕೆದಾರರ VPN ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಈಗಾಗಲೇ ಹೊಂದಿದೆ, ಮತ್ತು ನಿಮ್ಮ protect ಕರೆಗಳು ನಿಮ್ಮ ಸುರಂಗ ಬಳಸಲಾಗದ ಸಾಕೆಟ್‌ಗಳನ್ನು ಗುರುತಿಸುತ್ತಿವೆ. ಕೆಳಗಿನ ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪೂರ್ಣಗೊಳಿಸಿ ಮತ್ತು ವಿಫಲವಾಗುವ ಮೊದಲನೆಯದರಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ನಂತರದ ಹಂತವು ಹಿಂದಿನದನ್ನು ಸರಿಪಡಿಸಲಾಗದು.

protect ಮುಟ್ಟುವ ಮೊದಲು VPN ಸ್ಲಾಟ್ ಪರಿಶೀಲಿಸಿ

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

ಇನ್ನೊಂದು ಆ್ಯಪ್‌ಗೆ ಹೊಂದಿಸಿದ ಯಾವಾಗಲೂ-ಚಾಲು VPN ಅತ್ಯಂತ ಕಠಿಣ ಪ್ರಕರಣ, ಏಕೆಂದರೆ ಸಿಸ್ಟಮ್ ಆ ಆ್ಯಪ್ ಅನ್ನು ಸಂಪರ್ಕದಲ್ಲಿಡುತ್ತದೆ ಮತ್ತು ವಶಪಡಿಸಿಕೊಳ್ಳುವಿಕೆಯನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ. AdGuard ನಂತಹ ಟ್ರಾಫಿಕ್ ಫಿಲ್ಟರ್, ಕಾರ್ಪೊರೇಟ್ ಕ್ಲೈಂಟ್ ಅಥವಾ ಗ್ರಾಹಕ VPN ಸ್ಲಾಟ್ ಅನ್ನು ಹಿಡಿದಿಡಬಹುದು, ಬಳಕೆದಾರರು ಅದು ಸ್ಥಾಪಿತವಾಗಿದೆ ಎಂಬುದನ್ನು ಮರೆತಿರುವಾಗ. ಬಳಕೆದಾರರಿಗೆ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ತೆರೆದು VPN ಅಡಿಯಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡಲಾದ ನಮೂದನ್ನು ಓದಲು ಹೇಳಿ; ಅಲ್ಲಿರುವ ಹೆಸರೇ ನೀವು ಸ್ಪರ್ಧಿಸುತ್ತಿರುವ ಮಾಲೀಕ. ಆ ನಮೂದು ಸಂಪರ್ಕ ಕಡಿತಗೊಳ್ಳುವವರೆಗೆ ಅಥವಾ ಯಾವಾಗಲೂ-ಚಾಲು ಸೆಟ್ಟಿಂಗ್ ಅಳಿಸುವವರೆಗೆ, ನಿಮ್ಮ VpnService ಇಂಟರ್ಫೇಸ್ ಆಗಲಾರದು.

ಹಂತ 1: prepare ಏನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂದು ಓದಿ

VpnService.prepare ಒಂದೇ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಈ ಆ್ಯಪ್ VPN ಆಗಬಹುದೇ? ಒಪ್ಪಿಗೆ ಈಗಾಗಲೇ ಇದ್ದರೆ ಅದು null ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರರು ಇನ್ನೂ ಅನುಮೋದಿಸಬೇಕಿದ್ದರೆ Intent ನೀಡುತ್ತದೆ, ಅದನ್ನು ನೀವು startActivityForResult ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಬೇಕು. null ಹಿಂತಿರುಗುವಿಕೆಯನ್ನು ಮುಂದುವರಿಯುವ ಅನುಮತಿ ಎಂದು ಪರಿಗಣಿಸಿ, establish ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಎಂಬ ಸಾಕ್ಷ್ಯವಲ್ಲ.

Intent intent = VpnService.prepare(context);
if (intent != null) {
    startActivityForResult(intent, REQUEST_VPN);
}

Intent ಮಾರ್ಗ ಹಿಂತಿರುಗಿ ಬಳಕೆದಾರರು ನಿರಾಕರಿಸಿದರೆ, ಮುಂದಿನ ಪ್ರಯತ್ನದಲ್ಲಿ prepare ಮತ್ತೆ Intent ಹಿಂತಿರುಗಿಸುತ್ತಲೇ ಇರುತ್ತದೆ. ಲೂಪ್‌ನಲ್ಲಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವ ಬದಲು ಫಲಿತಾಂಶ ಕೋಡ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಿ, ಏಕೆಂದರೆ ನಿರಾಕರಿಸಿದ ಒಪ್ಪಿಗೆ ಬಳಕೆದಾರರ ನಿರ್ಧಾರ, ತಾತ್ಕಾಲಿಕ ದೋಷವಲ್ಲ.

ಹಂತ 2: ಇಂಟರ್ಫೇಸ್ ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಸೇರಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ

establish ನಂತರ ಸಿಗುವ ParcelFileDescriptor ನಿಮ್ಮ ಮಾಲೀಕತ್ವದ ಸಾಕ್ಷ್ಯ, ಮತ್ತು ಯಾವುದೇ ಸಾಕೆಟ್ ಕೆಲಸಕ್ಕೆ ಮೊದಲು ಅದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಯೋಗ್ಯ. null ಅಥವಾ ಈಗಾಗಲೇ ಮುಚ್ಚಿದ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಎಂದರೆ ಇಂಟರ್ಫೇಸ್ ಎಂದೂ ರಚಿಸಲಿಲ್ಲ, ಯಾವುದೇ ಅಪವಾದ ಕಾಣದಿದ್ದರೂ. builder ನ ಇಂಟರ್ಫೇಸ್ ಹೆಸರನ್ನು ಸಿಸ್ಟಮ್ ಸಕ್ರಿಯ VPN ಗಾಗಿ ವರದಿ ಮಾಡುವ ಹೆಸರಿನೊಂದಿಗೆ ಹೋಲಿಸಿ, ಪರೀಕ್ಷಾ ಸಾಧನದಲ್ಲಿ dumpsys ಬಳಸಿ. ಅವು ಭಿನ್ನವಾಗಿದ್ದರೆ, ನೀವು ನಿರ್ಮಿಸಿದ ಸುರಂಗ ಟ್ರಾಫಿಕ್ ಸಾಗಿಸುತ್ತಿರುವ ಸುರಂಗವಲ್ಲ.

adb shell dumpsys connectivity

ಅದೇ ಅಸಂಗತಿ ಸಂಪರ್ಕಿತ ಐಕಾನ್ ಜೊತೆ ಸತ್ತ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಇನ್ನೊಂದು ಆ್ಯಪ್‌ನ ಸುರಂಗ ತೋರಿಸುತ್ತದೆ, ಆದರೆ ನಿಮ್ಮ ಕೋಡ್ ತನಗೆ ಸೇರದ ಇಂಟರ್ಫೇಸ್‌ನ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಹಿಡಿದಿದೆ.

ಹಂತ 3: connect ಗಿಂತ ಮೊದಲು protect ಕರೆಯಿರಿ

ಇಂಟರ್ಫೇಸ್ ಇದ್ದ ಕೂಡಲೇ, ನಿಮ್ಮ ಆ್ಯಪ್ ತೆರೆಯುವ ಸಾಕೆಟ್‌ಗಳು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಸುರಂಗಕ್ಕೆ ಮಾರ್ಗೀಕರಿಸಲ್ಪಡುತ್ತವೆ. ಹೊರಗಿನ ಸಾಗಣೆ ಆ ನಿಯಮವನ್ನು ಅನುಸರಿಸಲಾರದು, ಇಲ್ಲದಿದ್ದರೆ ಸುತ್ತಿಕೊಂಡ ಪ್ಯಾಕೆಟ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಮರಳುತ್ತದೆ, ಆದ್ದರಿಂದ VpnService protect ಒಂದು ಸಾಕೆಟ್ ಅನ್ನು VPN ಬೈಪಾಸ್ ಮಾಡಿ ಕೆಳಗಿನ ನೆಟ್‌ವರ್ಕ್ ಬಳಸಲು ಗುರುತಿಸುತ್ತದೆ. ಕರೆ boolean ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದೇ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ ಆದರೆ ಏನನ್ನೂ ಸಾಗಿಸದ ಸಾಕೆಟ್‌ಗೆ ತಲುಪುವ ದಾರಿ.

connect ಅಥವಾ bind ಗಿಂತ ಮೊದಲು protect ಕರೆಯಿರಿ, ಎಂದಿಗೂ ನಂತರವಲ್ಲ. ಸಾಕೆಟ್ ಸಂಪರ್ಕಗೊಳ್ಳುವ ಅಥವಾ ಬಂಧಿಸಲ್ಪಡುವ ಮೊದಲೇ ರಕ್ಷಣೆ ಇರಬೇಕು, ಏಕೆಂದರೆ ಸಂಪರ್ಕಿತ ಸಾಕೆಟ್ ತನ್ನ ಮಾರ್ಗವನ್ನು ಈಗಾಗಲೇ ಆಯ್ಕೆ ಮಾಡಿದೆ ಮತ್ತು ನಂತರದ protect ಅದನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಸರಿಸುವುದಿಲ್ಲ. protect false ಹಿಂತಿರುಗಿಸಿದರೆ, ನಿಲ್ಲಿಸಿ ಮತ್ತು ಮಾಲೀಕತ್ವವನ್ನು ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ: ಇಂಟರ್ಫೇಸ್ ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಸೇರದಿದ್ದಾಗ ಅದು ವಿಫಲವಾಗುತ್ತದೆ, ಇದು ಇನ್ನೊಂದು VPN ಬಿಟ್ಟುಹೋಗುವ ಸ್ಥಿತಿಯೇ. false ಹಿಂತಿರುಗುವಿಕೆ ಹಂತ 1 ಗೆ ಮರಳುವ ಸಂಕೇತ, ಅದೇ ಸಾಕೆಟ್ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದಲ್ಲ.

DatagramSocket socket = new DatagramSocket();
if (!vpnService.protect(socket)) {
    return;
}
socket.connect(serverAddress, serverPort);

ಹಂತ 4: ಸಾಕೆಟ್ ಅನಾನುಕೂಲವಾದಾಗ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬಂಧಿಸಿ

ಕೆಲವು ಸಾಗಣೆಗಳು ಒಂದೇ ಸಾಕೆಟ್ ಅಲ್ಲ: ಲೈಬ್ರರಿ ಹಲವನ್ನು ತೆರೆಯಬಹುದು, ಅಥವಾ ಸಹಾಯಕ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿನ ಪ್ರತಿ ಸಂಪರ್ಕವೂ ಅದೇ ನಿರ್ಗಮನ ಬಳಸಬೇಕೆಂದು ನೀವು ಬಯಸಬಹುದು. ConnectivityManager.bindProcessToNetwork ಪ್ರಕ್ರಿಯೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿದ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಬಂಧಿಸುತ್ತದೆ, ಮತ್ತು ಹಳೆಯ setProcessDefaultNetwork ಬಳಕೆಯಿಂದ ಹೊರಬರುವ ಮೊದಲು ಅದೇ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು. ಕೆಳಗಿನ ಸಂಪರ್ಕವನ್ನು NET_CAPABILITY_NOT_VPN ನೊಂದಿಗೆ ಕೇಳಿ, ಬಂಧನವು ನಿಮ್ಮ ಸುರಂಗದ ಕೆಳಗಿನ ನೆಟ್‌ವರ್ಕ್ ಆಯ್ಕೆಮಾಡಲಿ, ಸುರಂಗವನ್ನೇ ಅಲ್ಲ.

NetworkRequest request = new NetworkRequest.Builder()
    .addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    .addCapability(NetworkCapabilities.NET_CAPABILITY_NOT_VPN)
    .build();

ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬಂಧಿಸುವುದು ಎರಡನೇ VPN ಅಲ್ಲ. ಅದು ಆ ಪ್ರಕ್ರಿಯೆಗೆ ನಿರ್ಗಮನ ಆಯ್ಕೆಮಾಡುತ್ತದೆ, ಇದು ನಿಮ್ಮ ಸಾಗಣೆಗೆ ಉಪಯುಕ್ತ ಮತ್ತು ಒಟ್ಟಿಗೆ ಎರಡು ಸುರಂಗ ಚಲಾಯಿಸಲು ನಿಷ್ಪ್ರಯೋಜಕ.

ಬಳಕೆದಾರರ ಸಾಧನವನ್ನು ಸರಿಪಡಿಸಿ, ಕೋಡ್ ಮಾರ್ಗವನ್ನಲ್ಲ

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

ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ನಿಮ್ಮ ಬೆಂಬಲ ದಾಖಲೆಗಳಲ್ಲಿ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಬಳಕೆದಾರರು ಯಾವ ಆ್ಯಪ್ VPN ಹೊಂದಿದೆ ಎಂದು ಅಪರೂಪವಾಗಿ ತಿಳಿಯುತ್ತಾರೆ. ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಂದ ಸಕ್ರಿಯ VPN ಹೆಸರು ಮತ್ತು ನಿಮ್ಮ ಲಾಗ್‌ಗಳಿಂದ prepare, establish ಮತ್ತು protect ಫಲಿತಾಂಶಗಳನ್ನು ಕಳುಹಿಸಲು ಹೇಳಿ, ಮತ್ತು ಒಂದು ನಿಮಿಷದಲ್ಲಿ ಯಾವ ಹಂತ ವಿಫಲವಾಯಿತು ಎಂದು ಹೇಳಬಹುದು. ನಂತರ ನಿಜವಾದ ಟ್ರಾಫಿಕ್‌ನಿಂದ ಪರಿಶೀಲಿಸಿ: ಹೆಸರಿನ ಹುಡುಕಾಟ, TCP ಸಂಪರ್ಕ ಮತ್ತು ಸುರಂಗದ ಮೂಲಕ ಒಂದು ವಿನಂತಿ, ಕೇವಲ ಸಂಪರ್ಕಿತ ಐಕಾನ್ ಅಲ್ಲ. ಮಾನ್ಯ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮತ್ತು ಹಸಿರು ಸೂಚಕ ಬಹುವಾಗಿ ಮಾಲೀಕತ್ವವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ಸಾಗಣೆ ಮಾರ್ಗೀಕರಣ ನಿಯಮಗಳಿಂದ ಪಾರಾದುದನ್ನು ಎಂದಿಗೂ ಅಲ್ಲ.

ನಾಲ್ಕೂ ಪರಿಶೀಲನೆಗಳು ಉತ್ತೀರ್ಣವಾಗಿ ಟ್ರಾಫಿಕ್ ಇನ್ನೂ ಸಾಯುತ್ತಿದ್ದರೆ, ಮಾಲೀಕತ್ವ ಇನ್ನು ನಿಮ್ಮ ಸಮಸ್ಯೆಯಲ್ಲ. ಮಾರ್ಗೀಕರಣ ಮತ್ತು ಸರ್ವರ್ ತಲುಪುವಿಕೆಯತ್ತ ಸಾಗಿ, VPN ಆ್ಯಪ್ ಸ್ಥಾಪಿತವಿಲ್ಲದ ಸಾಧನದಿಂದ ಅದೇ ರುಜುವಾತುಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ.