ടണൽ ഉയരുന്ന അതേ നിമിഷം Android ആപ്പ് പ്രവർത്തിക്കുന്നത് നിർത്തുമ്പോൾ, മൂന്ന് വ്യത്യസ്ത കാര്യങ്ങൾക്ക് ഉത്തരവാദികളാകാം, അവ സമാനമായി തോന്നുന്ന പരാജയങ്ങൾ ഉണ്ടാക്കുന്നു. ആപ്പിന് ഫോണിന്റെ സ്വന്തം നെറ്റ്‌വർക്ക് അവസ്ഥ വായിച്ച് പ്രാദേശികമായി നിരസിക്കാം. നിങ്ങൾ വരുന്ന വിലാസം സർവർ വർഗ്ഗീകരിച്ച് അത് നിരസിക്കാം. അല്ലെങ്കിൽ നിരസിക്കലിന് VPN-മായി യാതൊരു ബന്ധവുമില്ലായിരിക്കാം. താഴെയുള്ള ക്രമം എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് തെളിവുകൾ ശേഖരിക്കുന്നു, കാരണം ഔട്ട്ലെറ്റ് മാറ്റുന്നത് ഏറ്റവും ചെലവേറിയ ഘട്ടമാണ്, പരിശോധന പ്രാദേശികമാണെങ്കിൽ സഹായിക്കാൻ സാധ്യത ഏറ്റവും കുറവുള്ളതും അതാണ്.

ഘട്ടം 1: ആപ്പ് എപ്പോൾ നിരസിക്കുന്നു എന്ന് കണ്ടെത്തുക

സമയമാണ് ആദ്യത്തെ വേർതിരിവ്. ലോഗ് ബഫർ ശൂന്യമാക്കി, പരാജയം വീണ്ടും ഉണ്ടാക്കി, ആപ്പ് പരാതിപ്പെടുന്നതിന് മുൻപ് എന്ത് ചെയ്തു എന്ന് നോക്കുക:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

ഏതെങ്കിലും പുറത്തേക്കുള്ള അഭ്യർത്ഥന ശ്രമിക്കുന്നതിന് മുൻപ് ആപ്പ് നിരസിക്കുന്നുവെങ്കിൽ, നിങ്ങൾ ഒരു പ്രാദേശിക തീരുമാനം കാണുകയാണ്. അത് കണക്ട് ചെയ്ത്, എന്തെങ്കിലും അയച്ച്, പിന്നീട് പിശക് കാണിക്കുന്നുവെങ്കിൽ, നിരസിക്കൽ മറുവശത്ത് നിന്നാണ് വന്നത്. ടണൽ ഓഫ് ആയിരിക്കുമ്പോഴും ആപ്പ് അതേപോലെ പരാജയപ്പെടുന്നുവെങ്കിൽ, VPN ഒരിക്കലും വേരിയബിൾ ആയിരുന്നില്ല.

ആ സമയത്തെ തെളിവായി കാണുക, സ്ഥിരീകരണമായി അല്ല. ആപ്പിന് കാഷ് ചെയ്ത പ്രതികരണം വീണ്ടും പ്ലേ ചെയ്യാം, പിന്നണി അഭ്യർത്ഥനകൾ നിങ്ങൾ നോക്കുന്നതിന് മുൻപ് വിജയിച്ചിരിക്കാം അല്ലെങ്കിൽ പരാജയപ്പെട്ടിരിക്കാം. അവസാന വിജയകരമായ അഭ്യർത്ഥനയുടെയും പിശകിന്റെയും സമയ മുദ്രകൾ എഴുതുക, സന്ദേശം പ്രത്യക്ഷപ്പെട്ട നിമിഷം മാത്രമല്ല.

ഘട്ടം 2: ഫോണിന്റെ സ്വന്തം നെറ്റ്‌വർക്ക് കാഴ്ച വായിക്കുക

Android VPN അവസ്ഥയെ ഒരു നെറ്റ്‌വർക്ക് കഴിവായി വെളിപ്പെടുത്തുന്നു, അതിനാൽ ടണൽ സജീവമാണെന്ന് അറിയാൻ ആപ്പിന് വാണിജ്യ ദാതാക്കളുടെ പട്ടിക ആവശ്യമില്ല. നിലവിലെ നെറ്റ്‌വർക്ക് ഏതാണെന്ന് അത് കണക്ടിവിറ്റി സേവനത്തോട് ചോദിക്കുന്നു, ഉത്തരത്തിൽ VPN ഗതാഗത ബിറ്റ് ഉണ്ട്:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

ആ പരിശോധന പ്രാദേശികവും വിലകുറഞ്ഞതുമാണ്, ഒപ്പം ഒരു ദൂര വർഗ്ഗീകരണവുമില്ലാതെ “ഈ ആപ്പ് VPN-ൽ പ്രവർത്തിക്കുന്നില്ല” എന്ന തരത്തിലുള്ള മുഴുവൻ റിപ്പോർട്ടുകളും അത് വിശദീകരിക്കുന്നു. ആപ്പിന് കാണാൻ കഴിയുന്നത് ഇപ്പോഴും അതിന്റെ സ്വന്തം നെറ്റ്‌വർക്ക് സന്ദർഭത്തെ ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ ഓരോ ആപ്പും ഉപകരണത്തിലെ ഓരോ പ്രൊഫൈലും പരിശോധിക്കുന്നു എന്ന് കരുതരുത്.

വർക്ക്‌സ്റ്റേഷനിൽ നിന്ന് ടെസ്റ്റ് ഉപകരണത്തിൽ adb shell dumpsys connectivity ഉപയോഗിച്ചും VPN നെറ്റ്‌വർക്ക് എൻട്രി തിരഞ്ഞും അതേ അവസ്ഥ കാണാം. ടണൽ ഉയർന്നിരിക്കുന്ന ഒരു റൺ ടണൽ താഴ്ന്നിരിക്കുന്ന ഒന്നുമായി താരതമ്യം ചെയ്യുക, രണ്ട് ഔട്ട്പുട്ടുകളും സൂക്ഷിക്കുക.

ഘട്ടം 3: സർവർ യഥാർത്ഥത്തിൽ എന്ത് കാണുന്നു എന്ന് വായിക്കുക

രണ്ടാമത്തെ നിരീക്ഷകൻ സേവനമാണ്. വരുന്ന ഉറവിട വിലാസം അത് കാണുന്നു, വിലാസം, അതിന് പിന്നിലെ ഹോസ്റ്റിംഗ് നെറ്റ്‌വർക്ക്, പ്രദേശം, ഓപ്പറേറ്റർ അല്ലെങ്കിൽ അക്കൗണ്ടുമായും ഉപകരണവുമായും ബന്ധിപ്പിച്ച സിഗ്നലുകൾ എന്നിവയുടെ അടിസ്ഥാനത്തിൽ അത് പ്രവർത്തിക്കാം. ഇവയൊന്നും അദ്വിതീയ ഐഡന്റിറ്റിയല്ല, പങ്കിട്ട വിലാസവൽക്കരണം പാർശ്വവൽക്കരണ തടയലുകൾ സാധാരണമാക്കുന്നു: ഒരു നിയന്ത്രിത വിലാസത്തിന് അതേ വിവർത്തനത്തിന് പിന്നിലുള്ള ബന്ധമില്ലാത്ത ഉപയോക്താക്കളെയും പുറത്താക്കാം.

ആപ്പ് ഉപയോഗിക്കുന്ന അതേ പാതയിലൂടെ വിലാസം നേടുക, ലാപ്‌ടോപ്പിലെ ബ്രൗസറിൽ നിന്നല്ല. ഫോണിൽ, വിലാസ പ്രതിധ്വനി സേവനത്തിലേക്കുള്ള ലളിതമായ അഭ്യർത്ഥന ദൂര വശം എന്ത് സ്വീകരിക്കുന്നു എന്ന് കാണിക്കുന്നു, അതിനെ സെല്ലുലാർ വഴിയുള്ള അഭ്യർത്ഥനയുമായി താരതമ്യം ചെയ്യുമ്പോൾ വിലാസം ഒട്ടും മാറിയോ എന്ന് അറിയാം.

ആപ്പ് സെല്ലുലാറിൽ പ്രവർത്തിക്കുകയും അതേ അക്കൗണ്ടുമായി ടണലിൽ പരാജയപ്പെടുകയും ചെയ്യുന്നുവെങ്കിൽ, നിരസിക്കൽ ദൂര അറ്റത്തോ ആപ്പിന്റെ സ്വന്തം നയത്തിലോ ആണ്. രണ്ടിലും പരാജയപ്പെടുന്നുവെങ്കിൽ, VPN വേർതിരിക്കുന്ന ഘടകമല്ല, എൻഡ്‌പോയിന്റുകൾ പരിശോധിക്കുന്നത് നിർത്തണം.

ഘട്ടം 4: തെളിവുകളെ മൂന്ന് വിധികളിലൊന്നുമായി യോജിപ്പിക്കുക

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

വിധി അത് ഉണ്ടാക്കിയ തെളിവിനൊപ്പം എഴുതുക. ഈ ഘട്ടത്തിന്റെ മൂല്യം, ഹാൻഡ്‌സെറ്റിൽ തന്നെ ഓടുന്ന പരിശോധന ശരിയാക്കാൻ ആരെങ്കിലും നാല് തവണ ഔട്ട്ലെറ്റ് നോഡുകൾ മാറ്റുന്ന ചക്രം അത് നിർത്തുന്നു എന്നതാണ്.

അവകാശവാദങ്ങളെ സത്യസന്ധമായി നിലനിർത്തുകയും ചെയ്യുന്നു. സ്വയം ഹോസ്റ്റ് ചെയ്യുന്നത് എൻഡ്‌പോയിന്റും അതിന്റെ ഇന്റർനെറ്റ് ഔട്ട്ലെറ്റും മാറ്റുന്നു; VPN നെറ്റ്‌വർക്ക് സജീവമാണെന്ന് Android-നെ മറപ്പിക്കുന്നില്ല, വിലാസങ്ങൾ വർഗ്ഗീകരിക്കുന്ന സേവനത്തിന്റെ സ്വീകാര്യത ഉറപ്പും നൽകുന്നില്ല. പ്രാദേശിക ഫിൽട്ടർ നിങ്ങളുടെ സ്വന്തം VPN നെറ്റ്‌വർക്കിലും വാണിജ്യ നെറ്റ്‌വർക്കിലെന്നപോലെ എളുപ്പത്തിൽ സജീവമാകാം.

ഘട്ടം 5: പിന്തുണയുള്ള പാത സ്വീകരിച്ച് അത് പരിശോധിക്കുക

ഉൽപ്പന്നത്തിന്റെ രേഖപ്പെടുത്തിയ നയത്തിൽ നിന്നും അതിന്റെ പിന്തുണ ഉടമയിൽ നിന്നും തുടങ്ങുക. ക്ലയന്റ് പതിപ്പ്, കൃത്യമായ സന്ദേശം, ഇടുങ്ങിയ പരാജയ സമയവിന്യാസം എന്നിവ അയയ്ക്കുക; പിശക് ഉണ്ടെന്ന് തെളിയിക്കാൻ മാത്രം പൂർണ്ണ ട്രാഫിക് ക്യാപ്ചറുകളോ ക്രെഡൻഷ്യലുകളോ അയയ്ക്കരുത്.

സേവനം നേരിട്ടുള്ള പ്രവേശനം അനുവദിക്കുകയും ഉപകരണ നയം അത് അനുവദിക്കുകയും ചെയ്താൽ, ഓരോ ആപ്പിനുമുള്ള ഒഴിവാക്കലാണ് പിന്തുണയുള്ള സംവിധാനം, ടണൽ മറയ്ക്കുന്നതിന് പകരം ആ ആപ്പിനെ അത് ബോധപൂർവ്വം ടണലിൽ നിന്ന് നീക്കുന്നു. അപ്പോൾ ആപ്പിന്റെ ട്രാഫിക് സ്വന്തം പാതയിലൂടെ പുറത്തുപോകുന്നു, അത് ആരെങ്കിലും ഏൽക്കേണ്ട ഒരു നയ തീരുമാനമാണ്. VPN ഇല്ലാതെ തടയുന്ന ക്രമീകരണത്തിൽ ഒഴിവാക്കിയ ആപ്പിന് കണക്ടിവിറ്റി നഷ്ടപ്പെടാം, അതിനാൽ പ്രവർത്തിക്കും എന്ന് വാഗ്ദാനം ചെയ്യുന്നതിന് മുൻപ് ആ സംയോജനം പരിശോധിക്കുക.

ഏതെങ്കിലും മാറ്റത്തിന് ശേഷം ഘട്ടം ഒന്നിന്റെ സമയ പരിശോധന ആവർത്തിക്കുക, ആപ്പ് പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, മറ്റെല്ലാ ആപ്പുകളും ഇപ്പോഴും ടണൽ ഉപയോഗിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. പിന്നീട് മുൻ ക്രമീകരണം പുനഃസ്ഥാപിച്ച് പരാജയം തിരികെ വരുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക, കാരണം നിങ്ങൾക്ക് പുനർനിർമ്മിക്കാൻ കഴിയാത്ത പരിഹാരം വീണ്ടും കാണുന്ന ഒരു യാദൃച്ഛികതയാണ്.

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