മറ്റൊരു 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 ആപ്പ് ഇൻസ്റ്റാൾ ചെയ്യാത്ത ഒരു ഉപകരണത്തിൽ നിന്ന് അതേ ക്രെഡൻഷ്യലുകൾ പരീക്ഷിക്കുക.