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-കൾ ഉപയോഗിക്കുന്നു, ഒന്ന് ശരിയായിരിക്കുമ്പോൾ മറ്റുള്ളവ തെറ്റായിരിക്കാം.

QuestionHow you answer itWhat a yes means
Did the user grant VPN consent to my app?VpnService.prepare() returns nullConsent exists; the tunnel may still be down
Is the device sending default traffic through a VPN?TRANSPORT_VPN on the active networkSomething is tunneling, not necessarily your app
Did this request arrive through the VPN?Source address seen by the serverProof for that connection, nothing wider

മൂന്നാം വരിയാണ് ആളുകൾ ക്ലയന്റിൽ ഉത്തരം നൽകാൻ ശ്രമിക്കുന്നത്, അവിടെ ഉത്തരം നൽകാൻ കഴിയില്ല. VPN ക്ലയന്റുകൾക്ക് സ്വന്തം വിലാസ പൂൾ നൽകി സർവറിൽ ഉറവിട വിലാസം വായിക്കുക; സെഷന് നടുവിൽ ഉപയോക്താവ് ടണൽ മാറ്റിയാലും അതിജീവിക്കുന്ന ഏക തെളിവാണത്.

തെറ്റായ പോസിറ്റീവുകൾ ഒഴിവാക്കുന്ന പരിശോധനാ ക്രമം

ഇപ്പോഴും പ്രചാരത്തിലുള്ള പഴയ മാതൃകാ കോഡ് getNetworkInfo(ConnectivityManager.TYPE_VPN) വിളിക്കുന്നു. ആ വിളി കാലഹരണപ്പെട്ടതാണ്, കൂടാതെ പല റിലീസുകളിൽ VPN കണക്ട് ആയിരുന്നിട്ടും null തിരികെ നൽകി, അതുകൊണ്ടാണ് പകർത്തിയ സ്നിപ്പറ്റുകൾ പ്രവർത്തിക്കുന്ന ഉപകരണത്തിൽ തകർന്നതായി തോന്നുന്നത്. കഴിവ് പരിശോധനകൾ ആ കെണി ഒഴിവാക്കി Android 5.0 മുതൽ ഒരേപോലെ പ്രവർത്തിക്കുന്നു. ഇപ്പോഴും അത് വിളിക്കുന്ന കോഡ്ബേസ് പരിപാലിക്കുന്നുണ്ടെങ്കിൽ, ഫാൾബാക്കിൽ പൊതിഞ്ഞ് വയ്ക്കാതെ വിളി തന്നെ മാറ്റുക, കാരണം തെറ്റായ ഉത്തരം ആദ്യം ഉണ്ടാക്കിയത് ആ ഫാൾബാക്കാണ്.

ഒരു ഷോർട്ട്കട്ട് ഒരു മുന്നറിയിപ്പ് അർഹിക്കുന്നു. ബാഹ്യ സേവനം റിപ്പോർട്ട് ചെയ്യുന്ന പൊതു വിലാസം VPN എക്സിറ്റ് വിലാസവുമായി താരതമ്യം ചെയ്യുന്നത് പാതയെക്കുറിച്ച് എന്തോ തെളിയിക്കുന്നു, പക്ഷേ അത് ഓരോ പരിശോധനയ്ക്കും മൂന്നാം കക്ഷി അഭ്യർത്ഥന ചേർക്കുന്നു, ആ സേവനം പ്രവർത്തിക്കുന്നതിനെ ആശ്രയിക്കുന്നു, കൂടാതെ കാഷെ ചെയ്യപ്പെടാം അല്ലെങ്കിൽ തടയപ്പെടാം. അത് കൈകൊണ്ടുള്ള ഡയഗ്നോസ്റ്റിക്സായി സൂക്ഷിക്കുക, ആപ്പിനുള്ളിലെ സ്ഥിതി പരിശോധനയായി ഒരിക്കലും ഉപയോഗിക്കരുത്.

ഈ ക്രമത്തിൽ പരിശോധനകൾ നടത്തി ഉപയോക്താവിന്റെ റിപ്പോർട്ടുമായി യോജിക്കാത്ത ആദ്യത്തേതിൽ നിർത്തുക: ഷെല്ലിലെ ട്രാൻസ്പോർട്ട് പട്ടിക, സജീവ നെറ്റ്‌വർക്ക് കഴിവുകൾ, ടണൽ ഓൺ-ഓഫ് ചെയ്യുമ്പോഴുള്ള കോൾബാക്ക് ഇവന്റുകൾ, തുടർന്ന് സർവർ വശത്തെ ഉറവിട വിലാസം. നാലും യോജിച്ചിട്ടും ആപ്പ് തെറ്റായി പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, പിഴവ് Android-ന്റെ നെറ്റ്‌വർക്ക് കാഴ്ചയിലല്ല, നിങ്ങളുടെ സ്വന്തം സ്റ്റേറ്റ് മെഷീനിലാണ്.

അനുബന്ധ ലേഖനങ്ങൾ